it-swarm.dev

İzlemeniz gereken en kötü kodlama standardı?

Hiç kodlama standartlarında çalışmak zorunda kaldınız mı:

  • Verimliliğinizi büyük ölçüde azalttınız mı?
  • Başlangıçta iyi nedenlerle dahil edildi, ancak orijinal kaygı ilgisiz hale geldikten çok sonra tutuldu mu?
  • Listede o kadar uzun süre kaldık ki hepsini hatırlamak imkansız mıydı?
  • Yazarın iyi kodlama uygulamasını teşvik etmek yerine izlerini bırakmaya çalıştığını mı düşündünüz?
  • Neden dahil edildiğine dair hiçbir fikrin yoktu?

Eğer öyleyse, en az favori kuralınız nedir ve neden?


Bazı örnekler burada

76
finnw

Bu birkaç tüyleri fırlatabilir, ancak her yöntemin üstündeki şablonlu blok yorumları zorunlu kılan standartlar her zaman boktan beni rahatsız eder.

1) Bir şeyleri güncellerken dikkat edilmesi gereken gerçek işi yapan koddan çok uzakta oldukları için her zaman güncel değildirler. Kötü yorumlar hiçbir yorumdan daha kötüdür.

2) Genellikle kaynak kontrol aracında bulunan bilgileri tekrarlarlar, sadece daha az doğrudurlar. Örneğin: Son Değiştirme Tarihi, değişiklik tarihi/nedenleri listesi.

97
JohnFx

Bir keresinde, her bir kod satırı için en az bir yorumumuz olmasını isteyen bir profesör vardı.

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

Oldukça saçma.

129
Fishtoaster

Şirketimiz (C #) kodlama standardı #REGION'ların kapsamlı kullanımını gerektirdi (bilmeyenler için Visual Studio'da tek bir satıra gizlenecek kaynak kodu bloklarını işaretler). Sonuç olarak, her zaman güzel yapılandırılmış bir sınıf gibi görünen şeyleri açtınız, sadece #REGION yapılarının derin iç içe halılarının altına süpürülmüş çöp yığınlarını ve yığınlarını bulmak için. Tek satırların etrafında bölgeleriniz bile olabilir, ör. Logger'ın tek bir bildirimini bulmak için bir LOG bölgesini katlamak zorunda. Tabii ki, bazı bölgeler yapıldıktan sonra ilave edilen birçok yöntem de "yanlış" bölge kapsamına alındı. Korku. Korku.

Bölgeler, Visual Studio'ya eklenen en kötü özelliklerden biridir; gerçek OO yapısı yerine yüzeyin yapılandırılmasını teşvik eder.

Bugünlerde #REGIONs'ı görüyorum.

103
Cumbayah

Bir işte, veritabanında tuhaf bir şekilde Macarca gösterim kullanmak zorunda kaldık.

Ayrıntıları hatırlayamıyorum, ancak bellekten her alan adı şunları içermelidir:

  • Sesli harf yok
  • Tüm büyük harfler
  • Tabloya başvuru
  • Bir veri tipi göstergesi
  • Veri uzunluğu
  • Sıfırlanabilir bir gösterge

Örneğin, bir kişinin adını taşıyan sütun şu şekilde adlandırılabilir: PRSNFRSTNMVC30X (Kişi tablosu, Ad sütunu, Varchar 30 karakter, Boş Değil)

80
Damovisa

Tüm kaşlı ayraçların, desteğin bittiği için yorum yapılması gerektiğinde ısrar etmek:

örneğin:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For
48
Kris Erickson
#define AND  &&
#define OR   ||
#define EQ   ==

dedi nuff.

37
Niall C.
  • Yerel değişken adlarının tümü küçük harftir ve alt çizgi içermez

Gerçek örnekler: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts, potentialmsceventref

New York Times ağırlığında :

“Kelime boşlukları verilmemelidir. Sesli harfleri içeren ilk alfabe olan Eski Yunanca, eğer ses çıkardı ve onlarsız yaptıysanız Word boşlukları olmadan deşifre edilebilir. […] Latince de ikinci yüzyılda kelimeleri ayırmayı bıraktı. Kayıp şaşırtıcıdır, çünkü göz ayrılmamış metni okumak için çok daha fazla çalışmak zorundadır. Ancak paleograf Paul Saenger'in açıkladığı gibi, antik dünya “okumayı kolaylaştırmak ve daha hızlı yapmak” istemiyordu. ”
37
John Siracusa

Bir şirketin yazılım lideri tarafından benden " basit, yenidenndundant code ". Örneğin, varolan bir işleve yeni bir parametre eklemek yasaklandı. Bunun yerine, işlevi kopyalamak zorunda kaldınız ve gerilemeleri önlemek için orijinali el değmeden bırakmalısınız. tabii ki test (zaman kaybı).

Birleştirme yazılımı kullanmamız da yasaklanmıştı; her dosya aynı anda yalnızca bir programcı tarafından değiştirilebilir. Revizyon kontrol yazılımı elbette bilimkurgu idi.

Hayatımın en mutlu günü kovulduğu zamandı (İtalya'da birini kovmanın çok ama çok zor olduğunu düşünün).

36
Wizard79

Veritabanı ile tüm etkileşim saklı yordamlar aracılığıyla yapılmalıdır. 2010 yılında değil, 1997'de yaşıyor olmamız mantıklı olabilir.

Bunun asıl sorunun tüm kriterlerini kapsadığını fark ettim:

  • Verimliliğinizi büyük ölçüde azalttınız mı? KONTROL. Lütfen - sadece bir ORM kullanın.
  • Başlangıçta iyi nedenlerle dahil edildi, ancak orijinal kaygı ilgisiz hale geldikten çok sonra tutuldu mu? KONTROL. Yönetici 1000 yıl önce bir veritabanı sunucusu için bir geliştiriciydi ve bu kodlama standardını koydu.
  • Listede o kadar uzun süre kaldık ki hepsini hatırlamak imkansız mıydı? KONTROL. Bu 'mümkün olduğu kadar çok mantık veritabanında saklanmalıdır' içeriyordu.
  • Yazarın iyi kodlama uygulamasını teşvik etmek yerine izlerini bırakmaya çalıştığını mı düşündünüz? KONTROL. Eski bir veritabanı sunucusu geliştiricisi olan yöneticiye geri gelmesini sağlar.
  • Neden dahil edildiğine dair hiçbir fikrin yoktu? KONTROL.
36
Jaco Pretorius

CTO'nun daha iyi ve daha hızlı yapabileceğine inandığı için STL veya diğer standart C++ kütüphanelerini kullanmasına izin verilmiyor. Listeler ve string sınıfı gibi temel yapılar bile.

33
David B

Macarca gösterim

Örnek, " Charles Simonyi'nin Macar gösterim tanıtıcısı adlandırma kuralına ilişkin açıklaması " MSDN'de alınmıştır.

1 # “sy.h” 
 2 extern int * rgwDic; 
 3 extern int bsyMac; 
 4 yapı SY * PsySz (char sz []) [.____] 6 {
 7 karakter * pch; 
 8 int cch; 
 9 yapı SY * psy, * PsyCreate (); 
 10 int * pbsy; [.____ 11 int cwSz; 
 12 imzasız wHash = 0; 
 13 pch = sz; 
 14 iken (* pch! = 0 
 15 wHash = (wHash11 + * pch ++; 
 16 cch = pch-sz; 
 17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash]; [.____] 18 için (; * pbsy! = 0; pbsy = & psy -> bsyNext) 
 19 {
 20 karakter * szSy; 
 21 szSy = (psy = (yapı SY *) & rgwDic [* pbsy]) -> sz; 
 22 pch = sz; 
 23 ise (* pch == * szSy ++) 
 24 {
 25 ise (* pch ++ == 0) [.____. 26 26 dönüş (psy); 
 27} 
 28} 
 29 cwSz = 0; 
 30 (cch> = 2) [.____. 31 cwSz = ( cch-2/sizeof (int) +1; 
 32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) -rgwDic; 
 33 Sıfır ((int *) psy, cwSY); 
 34 bltbyte (sz, psy-> sz, cch + 1); [.____. 35 dönüş (psy) ; 
 36}
31
JD Frias

Bir keresinde proje liderinin her değişkenin (HER değişken) "v" ile ön ekini zorunlu kıldığı bir proje üzerinde çalıştım. Yani, vCount, vFirstName, vIsWarranty, vb.

Neden? "Çünkü VBScript'te çalışıyoruz ve her şey zaten bir Varyant".

O NE LAN.

28

Bunu neredeyse unuttum:

Bir yöneticiden alıntı:

Kendi kodunuzda bulduğunuz sorun hatalarını düzeltmeyin veya belgelemeyin. Müşteri önümüzdeki birkaç yıl içinde bunları tanımlamak ve düzeltmek için bize ödeme yapacak.

Bu tüketici yazılımı için değil, tek bir büyük organizasyon için özeldi. Söylemeye gerek yok, müşteri yıllar sonra ödeme yaptı. Önemsiz görünebilir, ancak hataları görmezden gelmeye çalışmak onları bulmaktan daha zordur.

26
David B

Özel olmayan tüm yöntemler, sabitler, numaralar ve özellikler hakkında zorlanmış XML yorumları.

Özellikle son sonuç insanların ya ///, her şey için boş bir yorum saplaması oluşturmak veya GhostDoc'u yüklemek ve otomatik olarak oluşturulan yorumlar eklemesini sağlamak için vurduğu için oldukça karmaşık bir koda yol açtı:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

Bu saçma bir standart olarak bahsetmemin nedeni, yöntem yorumlarının aptal olduğunu düşündüğümden değil, bu yorumların kalitesinin herhangi bir şekilde uygulanmadığı ve sadece kod dosyalarında çok fazla karmaşa yaratmasıyla sonuçlandığı için . Kör "bir yorum olmalı" derleme gereksiniminden anlamlı kod belgeleri oluşturmanın daha iyi yolları vardır.

24
Adam Lear

Gerçekten bir kodlama standardı değil, ancak kaynak kontrolünde 'changelog.txt' adlı bir dosyamız vardı

Her giriş yaptığınızda, bu dosyaya manuel olarak bir giriş eklemeniz gerekiyordu. Bu giriş, Subversion revizyon numarası ve check-in yorumunuzdu.

Yeni CTO başladığında ve birisi ona bunu söylediğinde derhal bir icra kararı verdi ve "Artık yapmayacağız" dedi ve dosyayı sildi. Bu yıllardır devam ediyordu.

23
Jim A

Çalıştığım yerlerden bazıları, kullanılmayan veya kullanımdan kaldırılmış kodları silmek yerine yorum yapmakta ısrar etti. Tarih vb. İçin VCS'ye güvenmek yerine, yorumlanmış kod aracılığıyla dosyalarda ağrılı bir şekilde tutuldu.

Bununla bulduğum en büyük sorun, kodun neden yorumlandığı hakkında hiçbir fikriniz olmadığıdır. Bunun nedeni, bazı geliştiricilerin etkin bir şekilde değişiklik yapması ve referans olarak saklamak istemesi miydi yoksa artık gerekmiyor muydu?

20
Jeremy Wiebe

Şimdiye kadar katıldığım en kötü kodlama standardı, hiçbiri olmayan kod tabanlarıdır. Tamamen katılmıyorum bir kodlama standardı yerine ben hiç yoktur kod üslerinde çalışmak yerine. Kod tabanının yeni bölümlerini öğrenmeyi çok daha zorlaştırıyor.

17
JaredPar

Sürüm kontrolü için satır içi yorumları zorlamak, görmezden geldiğim en anlamsız kodlama standardı hakkındaydı.

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

Beyaz alanın doğru kullanımı konusunda ısrar eden Oracle DBA, 200'den fazla alanı ve 40 tetikleyicisi olan son derece tartışmalı bir tabloya sahip bir veritabanını 'koruyor'.

16
Ryan Roberts

Tüm sınıf üyesi işlevlerinin sınıf adı ve görünürlük ile öneki olması gerektiğine karar veren bir C++ ilk zamanlayıcı tarafından yönetilen bir projede kod değerlendirmeleri yaptım:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}
14
user1006

Yıllar önce tüm kodumuzun sola hizalanması gereken bir işim vardı - girinti yok. Bu politika ile ortaya çıkan adam, uzun kod satırlarını görüntülerken yatay olarak ileri geri kaydırmaktan hoşlanmıyordu ve gözleriyle ping-pong oynatıyordu.

9
Jeremy

Tüm kodu dört boşlukla girintilemek;)

9
RedFilter

Geçmişimden bir patlama daha.

Şirket sahibinden alıntı:

Yorumlayıcı diller kullanılarak yazılan bir kod olmayacaktır çünkü Java ile yazılmış {expletive} projesinde 25 milyonu kaybettim.

Java projesi, birkaç bin düzine hisse senedini işlemek için tasarlanmış bir hisse senedi ticaret sistemiydi, bu da şimdi binlerce işlemek için kullanılıyordu. Tasarım kusurlarını veya zayıf donanımı ele almak yerine, tüm şirket C/C++ dışındaki tüm uygulamaları C/C++ 'a dönüştürün ve tüm yeni geliştirmelerin C/C++' da olması gerekiyordu. Yorumlayıcı diller derlenmemiş bir şey anlamına geliyordu ve sahibi sadece Assembler, C ve C++ derlendi.

Kodun çoğunun Java ve Perl) olduğu 800 kişilik bir şirket için bu, tüm şirketin önümüzdeki birkaç yıl içinde zamanlarının çoğunu C/C++.

Yeterince komik, bu fiyaskodan yaklaşık yirmi yıl önce, teknoloji liderinin sıralama mantığımızın (bir Kabarcık Sıralamasıydı) Quick Sort ile değiştirilmek yerine montajcıda kaydedilmesi gerektiğine karar verdiği başka bir şirketteydim - - Algoritmalar performansı iyileştirmez. Performansı artırmanın tek yolu, aynı mantığı derleyicide yeniden yazmaktı.

Her iki durumda da, diktatlar düştükten kısa bir süre sonra ayrıldım.

8
David B

Bu daha çok kodlama standartlarına sahip olmanın nasıl zarar verebileceğine bir örnek.

Büyük bir bankada çalışan bir müteahhit, standartları takip etmenin şimdiye kadarki en iyisi olduğu konusunda ısrar etti. Uygulama tek geliştirici dBase/Clipper yazılmıştır ve tabii ki standart ile geldi.

  • Her şey büyük harflidir. Onun yaptığı nadir yorumlar da dahil olmak üzere her şeyi kastediyorum.
  • Girinti yok.
  • Değişken adlandırma APRGNAME satırında bir şeydi. A = değişken kapsamı, örneğin genel için P, PRG = değişkeni oluşturan kaynak dosyanın ilk üç karakteri, NAME = dBase/Clipper'ın izin verdiği diğer 6 karakterde değişken adı.
  • Kaynak kodun ilk 4 ve son 4 satırı 80 * uzunluğundaydı. Neden? Böylece dot matrix yazıcının bir dosyanın yazdırılmasını başlattığını ve bitirdiğini duyabiliyordu. Hafıza tüm program haftalık, 20.000 sayfa ana çerçeve üzerinden basıldı olduğunu.
  • Eminim beynimden atmayı başardığım çok daha fazlası vardı.

O aşamada kendi kendini yetiştirmiş bir programcıydım, ancak projeyi devralmak istemeden önce çılgın bilim insanını dinlemeyip cehennemden çıkamayacağımı biliyordum.

Ve evet biz yönetimi bu uygulamaların ne kadar kötü olduğunu söyledi ama her zamanki gibi "ne dediğini bilmek gerekir bu müteahhit üst dolar ödüyorlardı.".

8
Tim Murphy

Birçok programcı gibi (ama yeterli değil), kod dekorasyonundan nefret ediyorum. Değişken adları için bir dolar işareti ($) öneki veya alıcılar/ayarlayıcılar olmasa bile özel değişkenler için alt çizgi kullanmam gerektiğinde beni çileden çıkarıyor. Anlamak için kodunuzu dekore etmeniz gerekiyorsa, o zaman cehennemi dışarı çıkarmanız gerekir!

6
Adam Harte

Bu tam olarak 1976 - UZUN bir zaman önceydi. Patronum hiç Edsger Dijkstra'yı duymamış ya da CACM meselesini okumamıştı, ama bir yerden "GOTO kötüdür" diye bir söylenti duymuştu, bu yüzden COBOL programlarımızda GOTO kullanmamıza izin verilmedi. Bu, COBOL'un "end if" i eklemesinden önceydi, bu yüzden üç klasik kontrol yapısının sadece iki buçukuna sahipti (dizi, eğer/sonra/else, gerçekleştirin (yani süre)). Temel programlarımızda GOTO'ya ve Assembler dil programlarımızda şube talimatlarına gönülsüzce izin verdi.

Maalesef bu bir tür "orada olmalısın" hikayesi. Bildiğim kadarıyla, 1976'dan beri icat edilen her dilin yeterli kontrol yapıları vardır, böylece asla GOTO'yu kullanmanız gerekmez. Ancak mesele şu ki, patron neden NEDEN GOTO'nun zararlı olarak kabul edildiğini veya hangi dilin infantil bozukluk olduğunu ve hangisinin ölümcül hastalık olduğunu bilmiyordu.

6
Mark Lutton

Ben bir projede baş mimarı açık kod (çok da) yazma talebi vardı. Kodda bulduğum en kötü örneklerden biri (ve mutlu bir şekilde onayladı) aşağıdakilerdi.

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

Hatta ReSharper bunun yanlış olduğunu söyledi!

6
Jax

Bir süredir tüm parametrelerin geçtiği P1, P2, P3 vb. İsimlendirilmeleri gereken bir web sistemi ile çalışıyorum.

Ayrıca - kesinlikle bir kodlama standardı olmamasına rağmen - aynı sistemde, her bir dosya xyz0001.ext, xyz0002.ext, xyz0003.ext, vs olarak adlandırıldı - burada xyz kendi başına uygulamanın koduydu.

6
CB Du Rietz

Son işimde "standartlar", beni işe alan adamın bana verdiği şey için çok güçlü bir terim olurdu. Web sitelerini ColdFusion ve SQL'de programlama gibi kodlama gereksinimleri verildi:

  • İçerir kullanmayın. Büyük bir sayfayı severim
  • Değişken ve sütun adlarındaki kelimeleri her zaman alt çizgi ile ayırın (etkin değil, ad vb. Hariç)
  • Asla kısaltmalar kullanmayın - her zaman ad yazın (sık sık fname yazdı vb.)
  • Kafa karıştırıcı isimler kullanmayın (farklı ancak ilgili şeyleri ölçen miktar_kağıtlı ve ücret_tutar gibi)
  • DIV kullanmayın ve çok az kullanın CSS - bunun yerine iç içe geçmiş tablolar kullanın (Bir keresinde altı kat derin buldum) .
  • Sorguları önbelleğe almayın. Hiç.
  • Birden fazla sayfada bir değişken mi kullanacaksınız? Uygulama kapsamı.
  • Her sayfanın kendi try/catch bloğu vardır. Global bir hata gidericiye ihtiyacımız yok/istemiyoruz.

Çıkar çıkmaz bunları değiştirmeye başladım.

6
Ben Doom

Neredeyse değişken türünü, değişebilirliği, kapsam/depolama sınıfını ve/veya referanslarını tekrarlayan her türlü değişken adlandırma kuralı. Temel olarak, dile özgü herhangi bir yapı. Modern IDE'lerle 21. yüzyılda bu artık gerekli değildir (ve bence sadece başlangıçta kötü kod düzenini/uygulamalarını çözdü). Buna Macarca gösterimi ve varyantları dahildir:

  • bigBlobStr - Bir dize.
  • bigBlobStrCurLocPtr - Adı geçen dizede "geçerli konum" a bir işaretçi.
  • someIntArray - Tamsayı dizisi

veya benzeri şeyler:

  • e_globalHeading - Harici değişken
  • sg_prefPoolSz - Statik global değişken

ve tabii ki OOP'ta göze çarpan en uzak nokta, tüm üyeler için m_. Hangi değişkenlerin yerel, üyeler, globaller, statik veya final/const olduğundan emin değilseniz/takip edemiyorsanız net yazmıyor olabilirsiniz , kötü faktörlü, spagetti kodu.

Bu, min, maks, ort, boyut, sayım, dizin ve et cetera gibi şeyler için bir önek/sonek kuralı belirtmekten tamamen farklıdır.

4
charstar

Tüm sınıflar ve sınıf üyeleri için XML belgelerine sahip olmak zorundayım. Özel dahil. Varsayılan ghostdoc yorumlarını kullanacağım.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}
4
Carl Bergquist

Karşılaştığım en kötü standart:

StyleCop C # için

Her anlamsız standardı alın ve tasarım zamanı IDE yerine derleme zamanında çalışan bir araca koyun).

//this is not a legal comment.
//  nor is this

// tek bir boşluk izlemelidir, hata ayıklama yapıyorsanız, kodu yorumlamak için //// kullanın. Mülkler ayrıca 'üçlü eğik çizgi' yorumlarına sahip olmalı ve sonunda bir nokta ile tamamlanmış ve uygun şekilde büyük harfle yazılmış "Gets or Sets xxxxx" ifadesini okumalıdır.

Ugh. Belki yaygın olarak yayınlanan API'larla bir nokta var ama benim ana sığır eti kesinlikle bir eklenti olarak la R # inşa etmiş olabilirler.

4
MIA

Japonya'da kısa bir süre çalıştım. Karmaşık matematiksel kodlama yapıyordum. Şirket kodlama standardı kesinlikle hiçbir yorum yoktu. Karmaşık hesaplamaları açıklamak ve birkaç hafta sonra kendimi unutmamak için bazı yorumlar eklemek isterdim. Kodun ne yaptığını anlamak için benden sonra gelen bir sonraki adama yazık.

Kod yorumlarının yasaklandığını ilk kez gördüm.

4
softveda

Önceki bir işte, C # standardı, bildirimlerde tür adı ve değişken adı arasında en az iki boşluk olacaktı, yöntem adı erişim değiştiricilerinden ve dönüş türünden sonraki satırda başlamalı, herhangi bir açık noktalamadan önce bir boşluk oluşmalıdır (parantez veya parantez), yöntemin başlangıcındaki tüm değişken bildirimler, atamadan ayrı bildirimler ve girinti 3 boşluktur. Misal:

private static int
ThisIsTheMethod (int  code, string  message)
{
   int  i;
   int  j;
   int  k;

   for (i = 0; i < message.Length; i++)
   {
      if (message [i] == '!') return -1;
   }

   j = SomeMethod (code);
   k = OtherMethod (j);

   return k;
}

Çirkin olsa da, Visual Studio'nun işleri gerçekten bu şekilde istemediği istisnası vardı ve bu şekilde yeniden biçimlendirmek için "normal" kodlandıktan sonra daha fazla bir adımdı.

3
Jesse C. Slicer

memnuniyetle 3 ay önce bıraktığım önceki işimde:

veri tabanı:

  • Tablo adları büyük harf olmalıdır.
  • Tablo adlarının başına TBL_ konulması gerekiyordu
  • Alanların önüne eklenmesi gerekiyordu: DS_ (anlamlı olmayan varchar için) CD_ sayıları için NU_ ("bit alanları" için) DT_ tarihler için
  • veritabanı alanlarının da büyük harf olması gerekiyordu [CD_ENABLED]
  • sp adları [SP_INFINITY_USER_GROUPS_QRY] ve veritabanı adları [INFINITY] ile aynı
  • sp isimlerinin aslında böyle olduğunu söylemiş miydim? SP_ öneki, sonra veritabanı adı SP_INFINITY_ sonra tablo adı, SP_INFINITY_USER_GROUPS sonra sp'nin gerçekte yapması beklenen şey (QRY, UPD, DEL, INS) İsa, beni sadece CRUD sorguları olmayan sorgularda başlatmıyorum.
  • tüm metin alanları açık bir şekilde varchar (MAX) olmalıdır.
  • başka bir tür kullanmış olsanız bile sayılar int veya double'dı.
  • "boolean" alanları (bit) int idi, sebep yok.
  • saklı yordamların önüne sp_productname_ gerekiyordu

asp.net/c #/javascript

  • HER tek işlev {} catch {} 'i tamamlamalıydı, bu yüzden uygulamalar çalışmaz ve neden bir ipucu içermiyorsa bile uygulamalar "patlamaz" (en azından resmi sebep budur).
  • parametrelerin önüne p eklenmelidir, örn. pCount, pPage
  • kapsam değişkenlerine w öneki gelmek zorundaydı ("çalışma" da olduğu gibi, bu ne anlama geliyor?)
  • g vb. ile statikler.
  • 1.1 çerçevesinden sonraki her şey, zaten linq ve jenerikler için herhangi bir gerçek kullanımınız olduğu gibi, haksızlıktı. (Jquery kullanmama izin vermelerini sağladım, en azından bunu başardım).
3
bevacqua

Zorunlu dahil etme, SCC PVCS'nin eski sürümü olduğunda $ Log $ bilgilerinin genişletilmesi. $ Log $ bilgilerinin dosyadaki gerçek koddan çok daha uzun olduğu bazı dosyalarımız vardı.

3
Ian C.

PHP komut dosyasındaki tüm çıktılar satır satır tekrarlanmalıdır.

<?php
echo "<div id=\"foo\">";
echo "<h1>" . $title . "</h1>";
echo paragraphs($body); // just an example
echo "</div>";
?>

(Feragatname: Takip etmek zorunda değildim, ama birlikte çalıştığım bir ekip bunu yaptı.)

3
sholsinger

en kötü, sınıfların modül kısaltmalarıyla ön ek oluşturulduğu bir projeydi (C++).

Örneğin, MessagePassing modülünde ve Yanıt mekanizmasının bir parçasıysa, buna MESPAS_RESSomeobject Denebilir.

Bu kod üzerinde çalışmak beni gözlerimin dışına atmak istedi.


En kötü değil, ama şu anki işim sınıflar için c_ Önekini ve numaralandırmalar için e_ Öneklerini gerektiriyor. Yapılar için hiçbir şey. ancak typedefs'te _t düzeltme. O da oldukça çirkin.

Oh, ve elbette neredeyse hiç eşleşmeyen İKİ .h ve .cpp (bildirim ve tanım) işlev başlığı yorumları.

3
µBio

En sevdiğim, "sihirli numara yok" kuralı clueless uygulanır. Örneğin, bir keresinde bir kod incelemesinde "Sihirli numara yok" kuralının bu kod satırı tarafından ihlal edildiğini belirten bir yorum gördüm:

if (fscanf(file, "%s %hd",name, nbrObject ) != 2 )

Gözden geçiren #define İKİ 2 gibi 2 yerine sabit istedi sanırım

3
Chalie Wax

Yöntem adlarımız 'Get/Set/Add/Delete' + hedef nesnenin adı + tüm parametrelerin adları biçiminde olmalıdır.

GetUserById(userId);
InsertUser(user);
DeleteUser(user);

Yeterince adil - ama kural çok katı. Karmaşık nesne türlerinin kısaltılmasına izin verilmedi ve ne kadar gülünç olursa olsun, işlemlerin her istek parametresini her zaman listelemesi gerekiyordu:

GetCustomerOrderDeliveryDetailsByCustomerIdAndDeliveryDateAndOrderStatus(...

Tam değişken isimlerini ekledikten sonra (kısaltılmasına izin verilmedi), bazı basit yöntem çağrılarının ne kadar sürdüğünü hayal edebilirsiniz. Word kaydırmalı olarak uzun.

3
Kirk Broadhurst

Şimdi veritabanı ile ilgili bir şey için değişken adlandırma işlemi çalışıyorum:

  • ifadeler için $ sql
  • sorgu sonuçları için $ sonuç

Bu mantıklıdır, ancak konvansiyonun çok genel olduğu ve bunun değişken örtüşmeyle sonuçlanacağı noktaya geldiğimde yanıt "sonuç_alt veya sql_alt kullan" idi. Yorum yapma konusundaki hislerim, amacı belirten değişken isimler kullandıysanız, yorumlara veya çoğuna ihtiyaç duymazsınız.

2
chrisw

Takip etmem gereken en kötü kodlama standardı "Tüm nesne değişkeni isimlerinin önüne" obj "yazılması gerekiyordu". Bu büyük bir Java projesindeydi, bu yüzden neredeyse her şey bir nesneydi. En kötü yanı, neredeyse herkes değişkenleri isimlendirme politikasını "obj" ile başlatarak benimsedi Kod boyunca Person objPerson1 gibi şeylerle yaralandık. Bir kez itiraz ettim ve diğer geliştiricilerden biri konvansiyonu sevdiğini söyletti "çünkü o zaman benim değişken isimleri ".

2
TMN

Belki Huawei Yazılım Şirketi'nin kodlama standardı. Tüm üyeleri herkese açık ilan etmenizi istiyorlar :))

2
LostMohican

Sütun 1'de boşluk olmayan bir karakter olduğunda Fortran ( WATFOR , FORTRAN 77 ) bir yorumdu ve 72. sütunun ötesine geçerseniz derleyici sizi uyarmadı, sessizce yoksaydı.

En azından bunu yapmak için sadece yedi yıl geçirdim.

2
Mark Thalman

C başlık dosyalarının miktarına sahip bir Java projesinde).

Arayüzler bazı iyi nedenlerle mevcuttur, ancak bu standart bir arayüz gerektirdi (foo.Java) her bir sınıf için (fooImpl.Java) herhangi bir anlam ifade edip etmediği. Senkronize tutmak için birçok şey, Eclipse tıklama yönteminin tamamen bozulması, anlamsız meşgul çalışma.

İnşa sistemi onu zorladı, ama asıl amacın ne olduğunu hayal bile edemiyorum. Neyse ki, yeni bir sürüm kontrolü ve derleme sistemine geçiş yaptığımızda yeni kod için hendek ettik, ancak hala çok şey var.

Aynı zamanda, zorunlu olan aptal versiyon-kontrol-dosya-bilgi-yorum alışkanlığından da vazgeçtik.

2
user763

Şu anda SQL sorguları "İstek Sınıfı" adlı bir şey aracılığıyla yapıldığı bir şirkette çalışıyorum. Ne kadar saçma:

"İnclude/request.class.php" içinde

class RequestClass
{
    // ... some code.

    public function getUser($where)
    {
        global $initrequest

        $sql = $initrequest['users']
        $sql.= $where;

        return execute($sql);
    }
}

İnitrequest.php dosyasında:

$initrequest['users'] = 'SELECT * FROM users WHERE ';

Ve uygulamadan bu şekilde çağrıldı:

$request = new request();
$tmpquery = "username = $username AND password = $password";
$request->getUsers($tmpquery);

Ve benzer bir şablon sistemine "bloklar" da dayanıyorlar, ama burada ne gösterdiğimi anladıktan sonra, tüm yazılımımızı çöpe atmaya ve Symfony'de yeniden yazmaya başladım.

2
Arie Deckelmann

Main () içinde birden fazla kod satırına izin verilmez

Üniversitemde, genç C # öğrencilerinin konsol uygulamalarının giriş noktalarına birden fazla kod satırı koymasına izin verilmemesi konusunda yeterince şanslı olmadığım bir profesör.

Bu, profesyonel bir uygulama geliştirirken makul bir anlam ifade eder, ancak programın tek amacı birkaç temel girdi almak ve tek bir çıktı (yani MultiplyTwoNumbers.exe) üretmek olduğunda, böyle bir gereksinim iyiden daha acıdır.

Profesör, "ana kod satırı" nın üstünde, her kod satırının açıklayıcı bir yorumu olduğu ve her sınıf üyesinin ayrıntılı açıklayıcı bir adı olduğu konusunda ısrar etti. Profesör bu şartların "yeterince" karşılandığını hissetmezse puan kaybedildi.

Bu kurallara bağlı kalmaya zorlanan öğrenciler (neredeyse) programlamaya yeni başlayanlardı ve bu nedenle zorlayıcı davranışların değerini iyi adlandırmak ve endişelerin ayrılması gibi görebiliyorum. Buna rağmen, üniversitemdeki .NET Eğitmeni olarak, öğrencilerine kodlarını aldıktan sonra bu sıradan ve iğrenç gereksinimleri karşılamaları için sürekli yardım ediyordum çalışma.

Benim düşünceme göre, bir programlama diline yeni giren birini eğitirken ilk endişe, kodun nasıl oluşturulacağı değil, nasıl kodun oluşturulması gerektiğidir standartlara dayalı kod olmalıdır.

1
Nathan Taylor

Msgstr "C kodu için C++ yorum stili kullanmayın".

Programınızı eski bir derleyiciye taşıma ihtiyacı varsa, bu hala küçük bir değere sahip olsa da, çoğunlukla sadece bir güçlüktür. En büyük itirazım, /* geliştirme veya birim testi sırasında büyük bir bölgeyi yorumlamak için. */

1
AShelly

Uni'deki ADA öğretim görevlisi, her yöntemin önkoşulları, sonkoşulları ve büyük O'yu özetleyen bir yorumu olduğu konusunda ısrar etti. Bu yorumu yapıştırarak yüzlerce kez yapıştırabilirsiniz.

-- Method_Name
-- PRECONDITIONS: none
-- POSTCONDITIONS: none
-- O(n) = n
1
Christopher

(C++)

Tüm dönüş değerleri HRESULTS (standart değerler - kullanıcı tanımlı hresults değil) olmalıdır

Bu sadece birkaç yıl önceydi. Yaşlılar hala COM ile bu kadar delicesine kapılmıştı ve diğer en iyi uygulamaları hiç okumadılar ya da öğrenmediler. İnanılmaz derecede kapalı bir ortamdı.

Aynı yer STL kullanımına da izin vermedi.

Bu çöplüğü öğrendikten kısa bir süre sonra ayrıldım.

1
Tim

Visual Basic 6. içinde, her yönteme hata işleme blokları eklemek zorunda kaldık. İstisna yok. Biz de öyle yaptık.

Sonra uygulamanın bazı bölümlerinin neden yavaş olduğunu açıklamak zorunda kaldık.

1
Chris Brandsma

Değişken/nesne adları için sınırlı alan muhtemelen en büyük tahrişimdir. Sadece 10 karaktere izin veren nispeten modern, tescilli bir dilde çalıştım. Bu, orijinal versiyonlarından bir engel.

Net sonuç, izin verilen 10'unuzun her karakterinin neyi temsil edeceğini tanımlayan komik adlandırma kurallarına son vermenizdir. Gibi bir şey:

  • 1-3: uygulama öneki
  • 4-6: modül öneki
  • 7-9: kullanıcı tanımlı bölüm
  • 10: sadece iki ... veya 9 aynı adı taşıyan bir sayı.
1
Brad Gardner

En sevdiğim şu anda uymaya çalıştığımız veritabanı adlandırma yönergeleri olmalı. Çok sayıda ilişki için kullanılan tüm tablolar, bağlantılı tabloların isimleri kullanılarak adlandırılmalı ve "Bağlantı" ile sonlandırılmalıdır. Ve elbette, tablo adlarının çoğullanması yok.

  • OrderLines? Hayır! Buna OrderProductLink adı verilmelidir
  • Arkadaşlar? Hayır! PersonPersonLink olmalı
1
CodingInsomnia

Her dosyaya bir dosya açıklaması eklemek zorunda kalmak (bu bir C # projesidir).

// --------------------------------------------------------------------------------------------------------------------
// <copyright file="User.cs" company="Company">
//   Copyright (C) 2009 Company. All rights reserved.
// </copyright>
// <summary>
//   The user.
// </summary>
// --------------------------------------------------------------------------------------------------------------------
0
Carl Bergquist

Bir şirkette, bir işlevi nasıl yazacağımızı açıklayan teknik belgeler yazmak zorunda kaldık. UML'de programlama yaparken her şeyi düşünmeyeceğiniz için hızlı bir şekilde eskimiş.

0
IAdapter