Tür ve kapsam önekleri adlandırma kurallarına değer mi?

Son zamanlarda bir yazılım geliştiricisi olarak ilk işime başladım, kodumda herhangi bir adlandırma kuralına uymak zorunda olmadığımı söylemek için biraz atıldım. Diğer daha büyük projeler üzerinde çalışan gruplar tarafından yazılan kod, adlandırma kurallarını izledi, ancak yeni, tek başına bir uygulama yazmaya başladığımdan beri, özellikle önemli olmadığı hissi vardı. Endişelerimin sonuncusuydu, bu yüzden mevcut sözleşmeyi aldım ve onunla koştum.

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

Ama aslında buna değer mi? Bu tür adlandırma kuralını izlemenin hataların anlaşılması ve algılanması üzerindeki net etkisini yargılamakta zorlanıyorum, ancak görsel olarak sadece çirkin görünüyor. Ayrıca, cSomething adlı projedeki her sınıfın ve dosyanın olması oldukça asinine benziyor.

Kullandığınız algoritmalar ve mimariler gibi bariz bir fark yaratan şeylerle karşılaştırıldığında uzaktan büyük bir anlaşma olduğu yanılsaması altında değilim. Ama yazdığım her kod satırını etkileyen herhangi bir sözleşme doğru almaya değer gibi görünüyor.

Kullanılması gerekiyorsa, en zarif ve etkili adlandırma kuralını ne buluyorsunuz? Türü ve / veya kapsamı gösterir mi?

Joel Spolsky, Macarca gösterimin neden var olduğu ve bunun için ne amaçlandığı hakkında bir makale yazdı ve sorunuzun yanıtlanmasına yardımcı olabilir.

Bir veritabanı tablosu için tbl, bir tamsayı için int vb gibi önekler genellikle yararlı değildir - bu durumlarda bağlamdan veya geliştirme araçlarınızdan neler olduğunu anlamak önemsizdir. Emperyal ölçümler için imp gibi ve metrik için karşılanan bir şey çok daha mantıklı çünkü aksi takdirde sadece kayan nokta sayıları olduğunu görebilirsiniz.

area = width * height

mükemmel görünüyor

impArea = metWidth * impHeight

size bir şeyin yanlış olduğunu gösterir.

Şahsen ben sadece tanımlayıcı değişken isimleri kullanıyorum. $ number_of_items açıkçası bir tamsayı sayımıdır. $ input_file_handle, $ is_active ve $ passwordted_password, hem dil veri türü hem de anlamsal tür açısından belirgin türlere sahiptir.

Açıkladığınız şeye Macarca gösterim adı verilir . Bir zamanlar en iyi uygulama olarak kabul edildi, ancak genellikle şu anda kaşlarını çattı.

Wikipedia makalesi, artıları ve eksileri hakkında bir bölüm içerir.

Evet, önekler yararlı olabilir , ancak birkaç önerim var:

Ekibinizin tamamı aynı kuralları kullanıyorsa, çok daha kullanışlı olurlar. Bunları kendi başınıza kullanmak daha az yardımcı olur.

Güçlü ve statik olarak yazılmış dillerde, yalnızca bir değişkenin türünü kopyalamakla kalmaz. Örneğin, "bSubscribed", C # veya Java'da bir boole değişkeni için kötü bir addır, çünkü IDE'niz bunun ne tür olduğunu zaten biliyordur. Öte yandan, bir boole türü bulunmayan C'de, bu yararlı bilgiler olacaktır.

C # ve Java'da, bir nesnenin boş olabileceğini göstermek için bir önek düşünebilirsiniz. Veya bir dize html-kaçtı. Veya normal bir ifadeyi veya bir sql ifadesini temsil ettiğini. Veya bir dizinin sıralandığını. Hayal gücünü kullan.

Temel olarak, kendinize size bir değişken adının ne söylemesini istediğinizi sorma sorusu vardır ve bu, etki alanına ve çalıştığınız dile çok bağlıdır.

Orada adlandırma kuralı birkaç farklı "stil" vardır ve bunların çoğu kod anlaşılır hale getirmek için bir miktar değeri vardır.

FAR'ın daha önemli olanı: değişkenler ve fonksiyonlar için açıklayıcı isimler kullanmak. "Sum", "weight" ve "value" ile örnekte, daha anlamlı adlar vermek isteyebilirsiniz: "totalCost", "lumberWeight", "lumberValuePerOunce" (Burada bazı varsayımlar yapıyorum)

Değişken isimlerini, türün çoğu modern dilde oldukça dikkat dağıtıcı olduğunu belirten bir karakterle bekleyen kuralları buluyorum.

Çoğu .NET geliştiricisi Microsoft'un Java'ya oldukça benzeyen Tasarım Yönergeleri'ne ( http://msdn.microsoft.com/en-us/library/ms229042.aspx ) uyar. deve durumda).

Bunun yanı sıra, eklediğiniz ekstra gürültü nedeniyle kod örneğinizin çok daha az okunabilir olduğunu söyleyebilirim.

Çoğunlukla, Google'ın kodlama stili kılavuzunun oldukça iyi olduğunu düşünüyorum. İstediğiniz stili kullanabileceğiniz söylendiğinden, bence bunu gözden geçirerek ve onu seçerek seçmelisiniz.

Değişken adlarının veri türlerine (özellikle ilkel veri türlerine) ön ek yapılması, görsel paraziti ve aksi takdirde küçük bir değişikliğin büyük patlama yeniden adlandırma olma riskini artırır.

İlk nokta, "intStudentCount" gerçekten örneğin "numberOfStudents" den daha açık mı? "İnvoiceLineItems" en azından "aobjItems" kadar bilgilendirici olmaz. (Veri türü, düşük düzeyli temsil ile değil, sorunlu etki alanındaki verilerin anlamı ile ilgili olmalıdır.)

İkinci noktaya gelince, örneğin int'in erken seçiminin yerini uzun veya iki ile değiştirdiğinde ne olur? Daha da kötüsü, somut bir sınıf birden fazla uygulama sınıfına sahip bir arayüze yeniden düzenlendiğinde ne olur? Gerçekçi bakım senaryolarının yükünü artıran herhangi bir uygulama benim için şüpheli görünüyor.

Ayrıca , yalnızca ön ekini yazdığınızın aksine, neden önek eklediğinize de bağlı olabilir .

Örnek olarak, bir formdaki denetimlerin adları için 1-2 harfli bir önek kullanma eğilimindeyim. Derleyicinin düğme için doğru sınıfı (örnek olarak) kolayca bulacağını bilmiyorum, ancak önce büyük formlar tasarlama, sonra kodun çoğunu daha sonra yazma eğiliminde değilim.

Düğmeler için bt önekine sahip olmak , birçok adı birbirine karıştırmak yerine daha sonra doğru düğmeyi bulmayı kolaylaştırır.

Değişkenleri adlandırmak için önekleri kullanmıyorum, ne tür (genellikle bu kadar kullanışlı değil) ne de anlam, bağlam veya birim (Macarca Gösterimin arkasındaki orijinal fikir) için.

Bana göre, projenin diline ve büyüklüğüne bağlıdır. Asla tüm değişkenlerim üzerinde tip önekleri kullanmak için bu kadar ileri gitmedim, ama bunları net bir şekilde adlandırmak istiyorsunuz.

Statik olarak yazılmış bir dilde, kullandığınız gibi, yazı sistemi ile ne kadar rahat hissedersem, Macarca Gösterimi o kadar az önem kazanır. Java veya C # ve özellikle Haskell'de bu önekleri eklemeyi bile düşünmüyorum, çünkü araçlarınız size verilen herhangi bir ifadenin türünü söyleyebilir ve bir türün yanlış anlaşılmasından kaynaklanan çoğu hatayı yakalar.

Önekler genellikle nesneler için anlamlıdır, örneğin 20 metin kutusunun hepsini çağırabileceği bir formda tbSomething.

Ancak, çoğunlukla değer türleri için özellikle değerli olduğunu düşünmüyorum.

Örneğin, varsayalım:

short shortValue = 0;
//stuff happens

Aylar sonra onu değiştirmeniz gerekiyor - bir kısa yeterince büyük değil. Şimdi:

int shortValue = 0;
//stuff happens

Artık değişkenin adını da değiştirmedikçe (bu durumda türü değiştirmek yerine kodu kırma riski daha fazladır) artık kafa karıştırıcı kodunuz var.

Sahip olduklarını açıklayan bir isme sahip olmanız daha iyi olur:

int loopCounter = 0;
//stuff happens

Daha sonra bunun uzun bir süreye dönüşmesi gerekiyorsa: sorun değil.

Dinamik olarak yazılan dillerde veya IDE'siz dillerde bu kurallar için daha fazla argüman olabilir.

Her zaman değişkenin önündeki tür için 2 ila 4 karakter kısaltması kullanmaya eğilimli oldum. Zaman zaman sıkıcı görünebilir, ancak karmaşık veri türleri veya durumlarıyla çalışırken faydalı olur. Bence alt deve kasa kategorisine giriyor.

Yukarıdaki örneğinize bakıldığında, şu şekilde biraz düzeltilecekti:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Diziler her zaman diziyi belirtmek için türün önünde bir a işaretine sahiptir. Bu, benzer değişkenleri birlikte gruplandırmamı da sağlar. Mesela ...

taStore.Fill(dtStore);

... bu da Mağaza TableAdapter'imin Mağaza DataTable'ını doldurduğunu gösterir.

Ben her zaman ön ekleri ve / veya son ekleri sadece kod daha okunaklı (düz İngilizce olduğu gibi) olduğunda eklenmelidir temel ilkesine uymaya çalıştım.

Ne kadar az şifreli, o kadar iyi ...

Neden böyle bir yöntem var:

public boolean connect( String h, int p );

Ne zaman böyle bir şey olabilir:

public boolean connect( String hostName, int port );

Dahası, IDE'ler bugün gerçekten (özellikle Java) değişkenleri, yöntem adlarını, sınıfları vb. Yeniden düzenleme için güçlü bir araca sahiptir ... En az miktarda karakterle maksimum bilgiyi söyleme fikri sadece eski modadır.