Şu anki işimde kodlama kılavuzu yok. Herkes istediği gibi kodlar. Hangi şirket küçük olduğu için, iyi.
Bununla birlikte, yeni bir adam yakın zamanda her zaman Macarca Notasyonu kullanmayı önerdi. Şimdiye kadar, bazılarımız bir çeşit Macar Notasyonu kullandık, bazılarımız kullanmamıştı. Biliyorsunuz, bu bir mühendislik şirketi, bu yüzden algoritmaların sağlam olduğu sürece kodlama stilleri gerçekten önemli değil.
Şahsen, bu küçük tip kısaltmaların gereksiz olduğunu hissediyorum. İyi düşünülmüş bir isim genellikle aynı mesajı verir. (Ayrıca, kodumuzun çoğu,
bool veya
float gibi bir kavramın zaten mevcut olmadığı bazı garip DSP'lerde çalışmalıdır.
Peki, Macarca Gösterimi hakkında ne hissediyorsunuz? Onu kullanır mısın? Neden?
Çoğu kişi "Macarca Gösterim" derken aslında " Systems Hungarian " hakkında konuşuyorlar.
Sistem Macarca tamamen işe yaramaz ve kaçınılmalıdır. Adındaki değişkenin türünü kodlamaya gerek yoktur. Ancak, Sistem Macarca aslında orijinal , "gerçek" Macarca: Apps Macarca bir yanlış anlamadır.
Apps Macarca'da, değişken adındaki "türü" kodlamazsınız, değişkenin "türünü" kodlarsınız. Yani
nWidth değil,
pxWidth veya
emWidth (sırasıyla "piksel cinsinden genişlik" veya "ems cinsinden genişlik" için).
strName değil
sName veya
usName (sırasıyla "güvenli ad" veya "güvenli olmayan ad" için - kullanıcılardan girdi kabul edilirken yararlı değil: güvenli olmayan dizeler).
Şahsen ben de genellikle uğraşmıyorum. Açıkça bir değerin "türünü" dönüştüren bir şey yapmadıkça (örneğin, geçmişte "px" ve "em" önekini kullandım çünkü
pxArea = emWidth * emHeight açık).
Ayrıca bkz. Joel'in " Yanlış Kodu Yanlış Görünmesini Sağlamak " makalesi.
pronounYou fiilHerhangi bir fiil yapalımHiçbir sıfat kullanHungarian isimNotasyon, edatIt fiilMarkaları birleştirirHer şey zarfı KarşılaştırmalıBloody sıfatHard infinitive to verbRead.
Birinci olarak:
Biliyorsunuz, bu bir mühendislik şirketi, bu yüzden algoritmaların sağlam olduğu sürece kodlama stilleri gerçekten önemli değil.
Kodlama stilleri şirketten bağımsız olarak önemlidir. Evet algoritmalar have sağlam olmalı, ancak kod must sadece orijinal geliştirici tarafından değil herkes tarafından korunabilir olmalıdır. Stil öğelerini içeren bir kodlama standardına sahip olmak bunu başarmanın bir yoludur. Ben tüm kod tarzı aynı olması gerektiğini söylemiyorum - bu karşı üretken olurdu, ama bir derece tutarlılık olmalıdır.
Şimdi Macar gösterimine:
Kullanımları olmasına rağmen, IntelliSense türü davranışları destekleyen modern bir IDE) ile değişkenin türünü ismine dahil etmek gerekli değildir. gelecekte değişkenin türünü değiştirmek zorunda kalırsanız kodun okunmasını zorlaştırabilir.
Kullanma. Gereksizdir ve kodun okunmasını zorlaştırır.
(Sistem) Macarca Gösterim ile ilgili tartışmaların çoğu çalışma alanına bağlıdır. Eskiden "hiçbir şekilde!" Tarafında çok sıkıydım, ancak gömülü geliştirme için kullanıldığı bir şirkette birkaç yıl çalıştım, bazı uygulamalarda bazı avantajlarını görebiliyorum ve kesinlikle benden büyüdü .
Söyleyebileceğim kadarıyla, Sistem Macarca gömülü alanda çok fazla kullanılma eğilimindedir. PC uygulamalarında derleyici, (ör.) Dizgiler, tamsayılar ve kayan nokta değerleri arasındaki farklarla ilişkili birçok konuyu ele alacaktır. Derinlemesine gömülü bir platformda, 8 bit işaretsiz tam sayılar, 16 bit işaretli tam sayılar vb. Arasındaki farklardan daha fazla endişe duyarsınız. Derleyici (veya MISRA kurallarıyla uygulanan tiftik) her zaman bunları almaz. Bu durumda
u8ReadIndex,
s16ADCValue yardımcı olabilir.
Uygulamalar Macarca, PC/Web uygulamaları söz konusu olduğunda kesin avantajlara sahiptir, örneğin 'güvenli olmayan' dizeler ve 'güvenli' dizeler (yani bir kullanıcı tarafından girilenler ve dahili kaynaklardan kaçan veya okunanlar veya bunlar gibi) ). Derleyicinin bu ayrım hakkında bilgisi yoktur.
(Sistemler veya Uygulamalar) Macarca kullanımı tamamen yanlış kod yanlış görünüyor yapmakla ilgilidir.
Güvenli olmayan bir dizeyi bir miktar kaçmadan doğrudan güvenli bir dizeye kopyalıyorsanız, Apps Macarca kullanıyorsanız yanlış görünecektir.
İşaretli bir tamsayıyı işaretsiz bir tamsayı ile çarpıyorsanız, derleyici (genellikle sessizce) imzalı olanı (muhtemelen çok büyük) imzasız olana yükseltir ve muhtemelen bir hataya neden olur: Systems Hungarian bunu yanlış yapar.
Her iki durumda da (Uygulamalar/Sistemler) Macarca gösterimi, değişken kodunun türüne daha az atıfta bulunduğu için resmi kod incelemelerini daha hızlı yapma eğilimindedir.
Genel olarak, bence en önemli şey bir kodlama standardına sahip olmanızdır. İster Sistem Macarca, ister Uygulama Macarca olsun ya da hiçbiri, girintili tiplerin seçimi vb. Gibi kişisel veya grup tercihi meselesidir. Ancak, aynı tercihte çalışan tüm geliştirme ekibinin kesin avantajları vardır.
Macarca Gösterimin amacı, bilgiyi tür sisteminde kodlanamayan tanımlayıcıya kodlamaktır. Benim düşüncem, eğer bu bilgi kodlanacak kadar önemli ise, o zaman düzgün kontrol edilebileceği tip sisteminde kodlanacak kadar önemlidir. Ve eğer bilgi önemli değilse, neden kaynak kodunuzu onunla karıştırmak istiyorsunuz?
Ya da, daha özlü bir şekilde ifade etmek gerekirse, tür bilgisi tür sistemine aittir. (Not: statik tür sistemi olmak zorunda değildir. Tür hatalarını yakaladığı sürece, ne zaman onları yakalamaz.)
Diğer birkaç cevap, Ölçü Birimlerini Macarca Gösteriminin kabul edilebilir kullanımları olarak belirtmiştir. (Kimsenin henüz NASA Mars İklim Orbiterinden bahsetmediğine şaşırdım, çünkü Macar Gösterimi ile ilgili tartışmalarda her zaman ortaya çıkıyor gibi görünüyor).
F # 'da basit bir örnek:
[<Measure>] type m [<Measure>] type ft let someLength = 48.15<m> let someOtherLength = 16.2342<ft> someLength + someOtherLength // someLength + someOtherLength // -------------^^^^^^^^^^^^^^^ // error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.
Bak anne, Macar yok!
Burada türler yerine Macarca Notasyonu kullanmak için I were olsaydı, bu bana biraz yardımcı olmaz:
let mSomeLength = 48.15 let ftSomeOtherLength = 16.2342 mSomeLength + ftSomeOtherLength // > val it : float = 64.3842
Derleyici düz geçmesine izin verdi. Şimdi aslında bir tür hata ne olduğunu belirlemek için bir insan güveniyorum. Tip denetleyicisi bunun için uygun değil mi?
Daha da iyisi, Frink programlama dili :
someLength = 48.15m someOtherLength = 16.2342ft someLength + someOtherLength // 53.09818416 m (length) // Wanna know the answer in a good old fashioned American unit? someLength + someOtherLength -> yd // 58.06888031496062992 // Are you an astrophysicist? someLength + someOtherLength -> parsec // 1.7207949554318336148e-15 // ... or a fundmentalist Christian who refuses to use units invented // less than 2000 years ago? someLength + someOtherLength -> biblicalcubits // 95.893563822870765006
Özetle: Macarca Yazımı Sevmiyorum. Asla kullanmamalısın.
Olduğu söyleniyor, bence Macarca Notasyonu kullanmak iyi bir fikir. Bir dakika ne?
Evet! Bu özel durum 'da bahsettiniz:
Ayrıca, kodumuzun çoğunun, bool veya float gibi bir kavramın zaten mevcut olmadığı bazı garip DSP'lerde çalışması gerekir.
Ama bu tam olarak tek mantıklı kullanım örneği için Macarca Gösterim!
PS: Yürekten Frink'e bakmanızı tavsiye ederim. El kitabı şimdiye kadarki en harika osuruk şakalarından bazılarını içeriyor. Ayrıca çok güzel bir dil :-)
HECK NO!
Macarca gösterim veya başka bir gösterim kullanmayın. Programcılar olarak değişken isimlerimiz için "gösterim" kullanmamalıyız.
Yapmamız gereken değişkenlerimizi iyi adlandırın:
zolarak adlandırmayın.
phoneBillveya
PhoneBilldeyin.
Çok özel isimler kullanmaktan kaçının. Ek bilgi olmadan bir şey net olduğunda bunu eklemeyin. Bir dizenin karakterleri arasında dolaşmak için yalnızca bir dizgi dizin değişkeni ise ve bunu yalnızca bir kez MyFunc işlevinde kullanırsanız, neden onu
MyFuncTempStringCharacterIndex olarak adlandırırsınız? Bu üzücü bir şaka. İsterseniz
Pos veya hatta
i deyin. Bağlamda, bir sonraki programcı bunun ne anlama geldiğini kolayca anlayacaktır.
Bir adın ne kadar genel veya spesifik olması gerektiğine karar verirken, içinde bulunduğu alanı ve diğer olası anlamların bağlamını düşünün. Aynı şekilde kullanılan, kolayca karışabilen iki benzer tür öğenin olduğu dar durumda, bu farkı göstermek için bir önek veya sonek bulmak iyi olur. Mümkün olduğunca kısa tutun.
Diğer yanıtlayıcıların söylediği gibi,
rwTabPosition penceresine ve
rdTabPosition belgesine göre ölçümler arasında ayrım yapmak, "Apps Hungarian" ı başlatan bu dar durumdur. Ancak belgeye göre her şeyi yapan bir uygulamada, fazladan bir rüzgâr eklemeyin! Aslında, neden Jörg W Mittag'ın fikri gerçek bir tür yapmak için kullanmıyorsunuz? O zaman işleri karıştıramazsınız.
Neredeyse her alanda, minimum anlam yoğunluğuna sahip şeyler eklemek genel anlamlılığı ve kavrama kolaylığını azaltır. İşte Ben Franklin'den bir örnek . Ve başka bir örnek: İngilizce olarak sözlerimizi konuşma bölümleriyle süslemek mümkündür. Daha fazla bilgi, değil mi? İngilizce'ye yeni başlayanların kafaları karışırsa, onlar için gerçekten yararlı olabilir, değil mi? Bunu okuyun ve bunun uzun vadeli kavrayış ve bilginin etkili bir şekilde aktarılması için ne kadar yararlı olduğunu düşündüğünüzü söyleyin:
vrbDo novnot vrbuse nouGenç nounotation cnjor adjany komşu nounotation. prepAs nouprogrammers, prow vrbsho "adsız" nouusing prbe için advnot gerekir.
ekleme bilgi, ben okumak için tam bir acı yaptı.
Gösterimi unutun. Her zaman eklediğiniz özel önekleri unutun. Kanımca, burada tek gerçek kılavuz şöyle olmalıdır:
Değişken adlarını olabildiğince kısa , gerektiği gibi anlamlı tutun ve her zaman açık .
Nesneye yönelik bir dilde mantıklı değil - her şey onu kullanmaya çalışırken görünen bir tür.
Systems Hungarian 'ın feragat edildiği tek yer C gibi zayıf yazılan bir dildir. C ile iki kat önemlidir çünkü açık bir nesne yoktur (yapıları vardır) , ancak tüm işlevler yapı dışındadır). C++, Java ve C # gibi daha güçlü yazılan bir şeyde yardımcı olmaz ve aslında işleri daha da kötüleştirir. Kod değişir ve bir türü değiştirmek, değişken adını kullandığınız tüm yerleri değiştirmekten çok daha kolaydır. Ayrıca görmezden gelinme eğiliminde olan gereksiz meşgul çalışması da vardır.
Ölçü birimleriniz varsa, bunu bir adda kodlamak yardımcı olabilir - ancak sonunda ekstra gürültü de olabilir. Örneğin, kodumuzda üzerinde çalıştığımız farklı şeyler için standart ölçü birimini beyan edeceğiz. Örneğin, degradeler veya dereceler, metre veya feet, çerçeveler veya milisaniye kullanıyor muyuz? Kod için standart belirlendikten sonra, tek bir ölçü biriminde okuduğumuzda, kodu derhal standart ölçü birimine dönüştürürüz.
Tavsiyem: mevcut ağrı noktalarınızla başlayın ve kodun bu kısmı için makul bir standart seçin. Bir kodlama standardının fazla belirtilmesi ters etki yaratır. Temsil ettiklerini açıklayan değişken ve alan adlarına sahip olmanın büyük bir değeri vardır ve çoğu zaman türü konseptten güvenli bir şekilde çıkarabilirsiniz.
Bir tanımlayıcının amacı türünden daha önemlidir. Programlarınızdaki tanımlayıcılar için açıklayıcı adlar kullanıyorsanız, Macarca gösterimleri kullanmanıza gerek yoktur.
isConnected her zaman
boolConnected 'den daha okunabilir ve anlaşılması kolaydır.
Bir C++ programcısıyken Macarca'yı kullandık ve harikaydı. Bildirimi aramadan bir değişkenin türünü (örn. BSTR, CString, LPCTSTR veya char *) görebilirsiniz. O günlerde, beyanı yaparak şunları yapabilirsiniz:
Bu yüzden biraz önemliydi. Ancak 2000 civarında bir yerlerde birkaç şey oldu:
lastName'nin bir
System.String, çünkü yalnızca bir dize sınıfı var.
Macarca'dan en son geçiş yapanlardan biriydim ve şimdi eski kaynak kodunu okuduğumda, aslında beni rahatsız ediyor.
Macarca notasyondan nefret ediyorum, değişken adları sınırlamak için alt çizgi kullanmayı tercih ediyorum.
Bunun üzerine, değişken adınızın başlangıcına türü ilk harf olarak koyduğunuzda: float fvelocity; vect vDirection; string ** ppszWord;
otomatik tamamlama hepsini sıralar ve istediğinizi bulmakta zorlanırsınız ve insanlar daha iyi olduğunu düşündüklerini kullanma eğilimindedir ve artık bir gösterim değildir.
Değişken hakkında çok açıklayıcı olmamız gerektiğinde ThingsLikeThat yazmayı seviyorum, çünkü yerden tasarruf sağlıyor ve kapaklar olduğu gerçeği daha okunabilir hale getiriyor.
Genellikle yaptığım, ilk harf Büyük harf, değişken adlar için küçük harf ve değişken adlar için bir alt çizgi olacak şekilde yöntemlerimi ve sınıflarımı adlandırmaktır (bu sonuncuyu yararlı buluyorum).
Ciddi olarak insanların bu kurallara dikkat etmesini tercih ediyorum: İlgili alanlarla virgül, aritmetik ve parantez kullanın:
void f(int a, char b); int a = b + 4 / (3 + 4);
Satır başına en fazla 80 karakter veya AT MOST 90 karakter, işlevler için çok satırlı bağımsız değişkenler kullanın veya uzun
if:
if ( checkthat(a, b) == checkthis(b, d) && checkthat(d, b) == checkthis(v, d) )
Çoğu ile aynı fikirde, eski bir stil.
Modern IDE'lerle, bir değişkenin üzerinde hızlı bir gezinme türü gösterir.