PHP özel - temiz kod, adlandırılması ve dokümantasyon

9 Cevap php

Temiz kod için en iyi uygulamaların bazılarını PHP için sözleşmeler ve belgeleri adlandırma, nelerdir?

Ben bu Örnek kötü bir uygulama olduğunu söyleyerek, kullanıcıların / insanlar görüyorum:

// Create an array to hold x values
$arr_x = array();

Bu tek başına sözdizimi işlevselliğini açıklayan bir gereksiz açıklama nedeni olduğunu. Bu komut / fonksiyon işlevleri yerine programın değişkenleri / akışını tanımlayan bir başlık yorumun daha fazla olması gerektiğidir. Örnek

/**
 * Create an array
 */
function create_array() {
   return array();
}

$arr_x = create_array();

// This is just to show the comments and the code is not tested veyaused except fveyathis example

Bu doğru sözdizimi, kodlama ve dokümantasyon (başlık adlandırılmasında nedeni) yolunu beni neden olmuştur.

ne değişken, fonksiyon ve komut adlandırma kuralları için kabul edilebilir ya da bu kişisel bir tercihtir?

$varX
function varX()
varX.php

veya

$var_x
function var_x()
var_x.php

Ben uygun olması gereken bir standart olup olmadığını bulmaya çalışıyorum. Teşekkürler

9 Cevap

Hiçbir standart, geliştiriciler sadece görüşler vardır.

Ben çizgi ile ayrılmış değişkenler olmasını tercih:

$my_var

Ama işlevleri için ben deve-durumda tercih:

function myFunction() {}

Yürütüldüğünde yorum gelince, evet bazen // create array tüm gerekli değildir, ama biri gömlekleri kullanarak ertelemeye yok gibi yorumlar, bunlar komut yavaşlatmak değildir. Ben düzgün bir karmaşık komut her adımı açıklamak için bir satır kullanmak ister.

Sürece kodu sizin için okunabilir ve dost geliştiriciler (bir proje üzerinde diğerleri, 3. kısım şirketleri vb) gibi, o zaman iyi olacak.

Zend Framework here bu değişkenleri ve işlevleri nasıl isim gibi şeyleri kapsamalıdır standart bir belge kodlama bir PHP vardır.

Ne zaman ve nasıl yorum için çok daha az platforma özgü. Ben iyi bir genel kural why birşey değil how daha yapılır hakkında yorum yapmak olduğunu düşünüyorum. Kod açıkça yeterli how belirgin yapmak için yazılmalıdır. (Istisnalar tür açıklama gerekebilir özellikle karmaşık algoritmaların kullanımı gibi, tabii ki vardır.)

En önemli şey tutarlı olmaktır. Açıklayıcı değişken, fonksiyon, ve yöntem adları gibi temel ötesinde, gerçekten tüm bu konularda tutarlılık.

Bu konuda çok sert düşünmek istemiyorsanız, PEAR projeden biri veya JacobM Sadece yayınlanmıştır Zend Framework standart gibi popüler kodlama stil kılavuzları birini kullanmak için çekinmeyin.

Senin gibi bir standart ya da mevcut kod temeli için en yakın eşleşme bulmak, o kadar php_codesniffer desteklenir - ve bu aracı yükleyin - en azından o zaman tutarsızlıklar için kodunuzu kontrol etmek için emrinde bir araç var.

Bir önemli şey tutarlılık. Eğer geliştirme ekibi için seçim ne olursa olsun - Yukarıda belirtilen standartların herhangi - geliştirme organizasyon HERKES yapışmasını olduğundan emin olun. Aksi halde, kod okumak çok zor olacak, ve işler kod inceleme zor olacaktır.

Drupal PHP ile yazılmış büyük açık kaynak kod temeli biridir.

Onlar bazı iyi kod kongre olması gerekir.

http://drupal.org/coding-standards

Kodlama standartları php değişiyor. Eğer eski çerçeveler bakarsanız hepsi bence kod hatalara yol açabilir Camel durum kullanmayın. Bu java gibi bir dil için mantıklı, ama php değil.

Daha yeni kodlama standartları ve çerçeve işleri cammel harf kullanmaktan kaçının ve lower_case çizgi için bir tercih değişken adları ayrılmış var. örneğin: yerine fatYak daha fat_yak.

Php ile sorun bildirilmemiş olan yeni bir değişken kabul edeceğini ve Vaka önemli olduğundan, bu iki aynı isimde değişkenler, ancak farklı bir durum var mümkündür. Hep aksi tespit edilmeden devam edebilir basit hataları önlemek için, değişkenler küçük harf kullanmak önemlidir dolayısıyla inmho. Genişletilmiş sınıfları yazmaya ve yöntem isimleri üzerine yazarken aynı sorun karşılaştı olacak gibi aynı prensip, yöntem adları uzatılmalıdır. (Bir harf yanlış yerleştirmek ve yerine istediğiniz gibi özgün işlevini yerine daha, bir ikinci işlevi ile sonuna kadar mümkündür.)

Ben bu camelCase yönüyle şımarık orada bazı çok ince kodlama standartları olduğunu düşünüyorum.

Bu ilke, aynı zamanda dosya adları uzatılmalıdır. teh sorunların çoğu zaman küçük kullanarak önlenebilir imho verilen Unix sunucular, davaya ilişkin pencereler sunucularından farklıdır. olmayan sermaye başlayan harfle az adlandırma sınıfları muhtemelen nessescary kötülüktür.

Sınıf isimlerinde CamelCase kullanarak gayet iyi. Burada bir hata yaparsanız onu hemen alınacaktır. Aslında bir sınıfın başında bir harf kullanarak kendi aklı için zorunludur. (Ben bu Fat_yak değil FatYak gibi onları isim olurdu, ama ben bu birinde azınlık değilim, bu yüzden dosya adlandırma kolaylaştıracak olsa da .. çenemi tutmak olabilir .. örn: yerine FatYak.php daha Fat_yak.php)

yerine bir sekme 4 boşluk kullanarak birçok farklı editörler özellikle kullanılan, çok yararlı bir fikir. (Kodu tüm editörler üzerinde aynı bakacağız)

her şey bir 50-50 önerme .. ve her bir standart iki seçenekten biri .. Bu, açık bir lider ortaya çıkmamıştır içinde, kodlama standartları hayal kırıklığı yönüdür seçim gibi görünüyor.

eg: 
"true" or "TRUE"

eg:
function blah(){

}

or

function blah()
{

}

Bu benim bir antipattern çağırır. Bazı veri türü değişiklik olacak zaman ne yapacaksın? Sadece bütün projeyi değiştirmek ve kodu kullanabilirsiniz belki birçok diğer projeler olacak mı?

Ben oldukça basit kullanmak istiyorum:

$x
function x()
x.php

JacobM sadece iyi bir PHP standartlar dokümanı yayınlanmıştır. Ben düzenleme veya mevcut kod ekleyerek kulüpler Ancak, ben önceki yazar tarafından ortaya konulan stilini takip etmeye çalışıyorum.

etiketler