Takip etmek zorunda kaldığın en kötü kodlama standardı? [kapalı]

Hiç aşağıdaki standartların kodlanması için çalışmak zorunda kaldınız mı:

• Verimliliğinizi büyük oranda düşürdünüz mü?
• Başlangıçta iyi nedenlerle dahil edildi mi, ancak orijinal kaygının alakasız kalmasından uzun süre sonra tutuldu mu?
• Listede o kadar uzun mu kalıyordu ki hepsini hatırlamak mümkün değildi?
• Yazarın iyi kodlama pratiğini teşvik etmek yerine sadece izini bırakmaya çalıştığını mı düşünüyorsunuz?
• Neden dahil oldukları hakkında hiçbir fikrin yok mu?

Eğer öyleyse, en sevdiğiniz kural hangisi ve neden?

Burada bazı örnekler

Bu, birkaç tüyün karışmasına neden olabilir, ancak her yöntemin tepesindeki şablonlu blok yorumları zorunlu kılan standartlar her zaman beni mahvetti.

1) Bir şeyleri güncellerken dikkat etmeniz gereken asıl işi yapan koddan çok uzakta oldukları için her zaman güncel değildirler. Kötü yorumlar, yorum yapmamaktan daha kötü.

2) Genellikle kaynak kontrol aracını içeren bilgiyi tekrar ederler, sadece daha az doğrudurlar. Örneğin: Son Değiştirme Tarihi, değişiklik tarihi / sebepleri listesi.

Bir keresinde, her 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);
}

Çok saçma oldu.

Şirketimiz (C #) kodlama standardı, #REGION'ların kapsamlı kullanımı için çağrıda bulundu (bunu bilmeyenler için Visual Studio'da tek bir satıra katlanacak kaynak kod bloklarını işaretler). Sonuç olarak, her zaman güzel bir şekilde yapılandırılmış bir sınıf olarak görünen şeyi, #REGION yapılarının derinlemesine iç içe geçmiş halılarının altına süpürülmüş çöp yığınlarını ve yığınlarını bulmak için açtınız. Tek satırların etrafındaki bölgelere bile sahip olacaktınız, örneğin Logger'ın tek bir bildirimini bulmak için bir LOG bölgesini katlamak zorunda kalacaksınız. Tabii ki, bir bölge yapıldıktan sonra birçok yöntem eklenmiş, "yanlış" bölge kapsamına da yerleştirilmiş. Korku. Korku.

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

Bugünlerde, bölgedeki # bölgeleri öldürdüm.

Bir işte , veritabanında bazı tuhaf Macar gösterim şekillerini kullanmak zorunda kaldık .

Ayrıntıları hatırlayamıyorum, ancak bellekten her alanın içermesi gerekenler:

• Ünlü yok
• Tüm büyük harfler
• Tabloya bir referans
• Veri tipi göstergesi
• Veri uzunluğu
• NULL olabilecek bir gösterge

Örneğin, bir kişinin adını taşıyan sütuna şu adresten ulaşabilirsiniz: PRSNFRSTNMVC30X(Kişi tablosu, Ad sütunu, Varchar 30 karakter, Boş Değil)

Tüm parantezlerin, ayraçın sona ermesi ile ilgili yorumda bulunulması konusunda ısrar:

Ö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

#define AND  &&
#define OR   ||
#define EQ   ==

'Hayır dedi.

• Yerel değişken isimlerinin tümü alt çizgi içermeyen küçük harflerdir.

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

New York Times ağırlığındadır :

“İzin verilenler için boşluk bırakılmamalıdır. İlk seslendiren ilk alfabe olan Eski Yunanca, ses çıkardıysanız ve konuşmasaydınız kelime boşlukları olmadan deşifre edilebilir. […] Latince de, kelimeleri ikinci yüzyıla ayırmaktan vazgeçti. Kayıp şaşırtıcı, çünkü ayrılmamış metni okumak için gözün daha fazla çalışması gerekiyor. Ancak paleograf Paul Saenger'ın açıkladığı gibi, antik dünya “okumayı kolaylaştırmak ve kaydırmak” istemedi. ”

Ben "yapmak için bir şirketin yazılım lideri tarafından istendi basit, yeniden n dundant kodu ". Örneğin, mevcut bir işleve yeni bir parametre eklemek yasaklandı. Bunun yerine, gerilemeyi önlemek için orijinali el değmeden bırakarak işlevi kopyalamanız gerekir. Elbette resmi bir test yapılmamaktadır (zaman kaybı).

Birleştirme yazılımı kullanmamız da yasaktı; her dosya bir seferde yalnızca bir programcı tarafından değiştirilebilir. Elbette revizyon kontrol yazılımı bilim kurgu idi.

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

Veri tabanı ile tüm etkileşimin saklı prosedürlerle yapılması gerekir . 2010'da değil, 1997'de yaşıyorsak, bu mantıklı olabilir.

Bunun asıl sorunun tüm kriterlerini karşıladığını anladım:

• Verimliliğinizi büyük oranda düşürdünüz mü? KONTROL. Lütfen - sadece bir ORM kullanın .
• Başlangıçta iyi nedenlerle dahil edildi mi, ancak orijinal kaygının alakasız kalmasından uzun süre sonra tutuldu mu? KONTROL. Yönetici, 1000 yıl önce bir veritabanı sunucusu için bir geliştiriciydi ve bu kodlama standardını devreye soktu.
• Listede o kadar uzun mu kalıyordu ki hepsini hatırlamak mümkün değildi? KONTROL. Bu, 'mümkün olduğu kadar çok mantık veri tabanında depolanmalıdır' dahil.
• Yazarın iyi kodlama pratiğini teşvik etmek yerine sadece izini bırakmaya çalıştığını mı düşünüyorsunuz? KONTROL. Eski veritabanı sunucusu geliştiricisi olarak yöneticiye geri dönmeyi sağlar.
• Neden dahil oldukları hakkında hiçbir fikrin yok mu? KONTROL.

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

Macarca notasyonu

MSDN'deki " Charles Simonyi'nin Macar gösterimindeki tanımlayıcı adlandırma kuralını açıklamasından " örnek alınmıştır .

1 # “sy.h” kelimesini içerir
2 harici int * rgwDic;
3 harici 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 çamaşır suyu = 0;
13 pch = sz;
14 iken (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
(; * Pbsy! = 0; pbsy = & psy-> bsyNext) için 18
19 {
20 karakter * szSy;
21 szSy = (psy = (yapı SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 iken (* pch == * szSy ++)
24 {
25 ise (* pch ++ == 0)
26 iade (psy);
27}
28}
29 cwSz = 0;
30 ise (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 bltbayt (sz, psy-> sz, cch + 1);
35 geri dönüş (psy);
36}

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

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

O NE LAN.

Neredeyse bunu unuttum:

Bir yöneticiden alıntı:

Kendi kodunuzda bulduğunuz herhangi bir sorunu düzeltmeyin veya belgelendirmeyin. Müşteri, önümüzdeki birkaç yıl içinde onları tanımlamamız ve düzeltmemiz için bize para ödeyecek.

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

Tüm özel olmayan yöntemler, sabitler, sayılar ve özellikler hakkındaki zorunlu XML yorumları.

Oldukça karışık kodlara yol açtı, özellikle de sonuçta insanlar ya boş bir yorum saplaması oluşturmak için ya da GhostDoc'u yüklemek ve otomatik olarak oluşturulan yorumlar eklemek için sadece /// isabet eden insanlardı:

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

[Düzenle] Bunu saçma bir standart olarak söylememin nedeni, yöntem yorumlarının aptalca olduklarından değil, bu yorumların kalitesinin hiçbir şekilde zorlanmadığından ve sadece kod dosyalarında çok sayıda ve çok sayıda kargaşaya neden olmasından kaynaklandığından kaynaklanıyor. . Anlamlı kod belgeleri oluşturmanın daha iyi bir yolu vardır ki, "bir yorum yapmalı" derleme gereksinimi kördür.

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

Her giriş yaptığınızda, bu dosyaya manuel olarak bir giriş eklemelisiniz. Bu girdi alt sürüm revizyon numarası ve sizin yorum yapan yorumunuz oldu.

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

Çalıştığım yerlerden bazıları, silmek yerine kullanılmayan veya kullanımdan kaldırılan kodun yorumlanmasında ısrar etti. Tarih için VCS'ye güvenmek yerine, vb. Yorumlanan kod aracılığıyla dosyalarda acı içinde tutuldu.

Bununla ilgili bulduğum en büyük sorun, kodun neden yorumlandığına dair hiçbir fikriniz olmadığıdır. Bazı dev aktif olarak değişiklikler yapıyor ve referans için etrafta tutmak istediğinden mi yoksa artık gerekmediğinden mi?

Şimdiye kadar katıldığım en kötü kodlama standardı hiç olmayan kod tabanları. Tamamen aynı fikirde olmayan kodlama standartlarını izlemeyi tercih ederim. Kod tabanının yeni bölümlerini öğrenmeyi daha da zorlaştırıyor.

Sürüm kontrolü için satır içi yorumları zorlamak, göz ardı ettiğim en anlamsız kodlama standardıydı.

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

200'den fazla alana ve 40 tetikleyiciye sahip yüksek oranda tartışmalı bir tabloya sahip bir veritabanını 'korurken' boşlukların doğru kullanılmasında ısrar eden Oracle DBA yaklaşıyor.

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

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

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

Yıllar önce, tüm kodlarımızın sola hizalı olması gereken bir işim vardı - girintisiz. Bu politikayla gelen adam, uzun kod satırlarını görüntülerken yatay olarak ileri geri gitmek zorunda kalmaktan hoşlanmamıştı;

Bu daha fazla kodlama standartlarına sahip olmamanın bir örneğini incitebilir.

Büyük bir bankada çalışan bir müteahhit, standartları takip etmenin en iyisi olduğuna ısrar etti. Uygulama, kendisi için tek geliştirici olan dBase / Clipper'a yazılmış ve tabii ki standartla birlikte ortaya çıkmıştı.

• Her şey büyük harf. Yaptığı nadir yorumlar dahil her şeyi kastediyorum.
• Girinti yok.
• Değişken isimlendirme APRGNAME dizisi boyunca bir şeydi. A = değişkenin kapsamı, örneğin genel için P, PRG = değişkeni oluşturan kaynak dosyanın ilk üç karakteri, NAME = kalan 6 karakterde dBase / Clipper'ın izin verdiği değişken adı.
• Kaynak kodun ilk 4 ve son 4 satırı 80 * uzunluğundaydı. Neden? Böylece nokta vuruşlu yazıcının bir dosyanın basımını başlatıp bitirdiğini duyabiliyordu. Hafıza haftanın her günü 20.000 sayfa anabilgisayar üzerinden basıldı.
• Eminim beynimden atmayı başardığım daha birçok şey vardı.

Bu aşamada çok yeni bir kendi kendine öğretilen programcıydım, ancak projeyi devralmak istemeden önce deli bilim insanlarını dinlememek ve oradan uzaklaşmak için yeterince bilgim yoktu.

Ve evet, yönetime bu uygulamaların ne kadar kötü olduğunu, ancak her zaman olağan olduğunu söylemiştik.

Geçmişimden bir patlama daha.

Şirket sahibinden alıntı:

Yorumlayıcı diller kullanılarak yazılmış hiçbir kod olmayacak çünkü Java'da yazılmış {expletive} projesinde 25 milyon kaybettim.

Java projesi, şimdi binlerce kişiyi işlemek için kullanılan birkaç düzine hisse senedini idare etmek için tasarlanmış bir hisse senedi alım satım sistemi idi. Tasarım kusurlarını veya kötü donanımları ele almak yerine, tüm şirket tüm C / C ++ uygulamalarını C / C ++ 'a dönüştürmek zorunda kaldı ve tüm yeni gelişmeler C / C ++' da olmalıydı. Yorumlayıcı diller, derlenmemiş herhangi bir şey anlamına geliyordu ve sahibi yalnızca Assembler, C ve C ++ derlenmiş olduğunu düşünüyordu.

Kodun çoğunun Java ve Perl'de olduğu 800 kişilik bir şirket için bu, tüm şirketin zamanının çoğunu önümüzdeki birkaç yıl boyunca C / C ++ 'da mükemmel bir şekilde yeniden kod yazarak geçirdiği anlamına geliyordu.

Yeterince komik, bu fiyaskodan yirmi yıl önce, teknoloji liderinin sıralama mantığımızın (bir Kabarcık Sıralamasıydı) montajcıda Hızlı Sıralama yerine yeniden kodlanması gerektiğine karar vermesi gerektiğine karar verdim çünkü - Algoritmalar performansı artırmak değil. Performansı arttırmanın tek yolu assembler içindeki aynı mantığı yeniden yazmaktı.

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

Birçok programcı gibi (ama yeterli değil) kod düzenlemeden nefret ederim. Değişken isimleri için bir dolar işareti ($) öneki, alıcılar / ayarlayıcılar olmasa bile, özel değişkenler için alt çizgiler kullanmak zorunda kaldığımda beni çıldırtıyor. Anlamak için kodunuzu dekore etmeniz gerekiyorsa, cehennemi çıkarmanız gerekir!

Bir süredir bir web sistemiyle çalışıyorum ve tüm parametrelerin P1, P2, P3 vs. olarak adlandırılması gerekiyordu.

Ayrıca - kesinlikle bir kodlama standardı olmasa da - aynı sistemde, her bir dosyaya xyz0001.ext, xyz0002.ext, xyz0003.ext, vb adını verecekti.

Bu çok uzun zaman önceydi - kesin olarak 1976. Patronum Edsger Dijkstra'yı hiç duymamıştı veya CACM'nin bir sayısını okumamıştı, ama "GOTO'nun kötü olduğu" bir yerden bir söylenti duymuştu, bu yüzden GOTO'yu COBOL programlarımızda kullanmamıza izin verilmedi. Bu, COBOL'un "eğer öyleyse" eklemesinden önceydi, o zaman o zaman üç klasik kontrol yapısının sadece iki buçuk katıydı (sıra, eğer / sonra / başkası, gerçekleştirirdi (yani öyleyse)). Temel programlarımızda GOTO'ya ve Assembler dil programlarımızda şube talimatlarına izin verdi.

Üzgünüm bu bir çeşit "orada olmalısın" hikayesi. Bildiğim kadarıyla, 1976'dan beri icat edilen her dilin yeteri kadar kontrol yapısı var ki GOTO'yu asla kullanmanıza gerek kalmadı. Fakat mesele şu ki, patron NEDEN GOTO’nun zararlı olarak değerlendirildiğini veya hangi dilin çocukça hastalığı olduğunu ve hangisinin ölümcül olduğunu bilmiyordu.

Bir projede çalıştım, baş mimarın açık kod yazması talebi vardı. Kodda bulduğum en kötü örneklerden biri (ve mutlu bir şekilde onayladı).

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

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

Son işimde "standartlar" beni işe alan adam tarafından verdiklerim için çok güçlü bir terim olurdu. ColdFusion ve SQL’de web sitelerini programlamak , aşağıdaki 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 (isaktif, ilk isim vb. Hariç).
• Asla kısaltmalar kullanmayın - her zaman ilk adı yazın (sık sık ad yazdı)
• Kafa karıştırıcı isimler kullanmayın (farklı ama ilişkili şeyler ölçülen miktar_charged ve charge_amount gibi)
• DIV'leri kullanmayın ve en az CSS kullanın - bunun yerine iç içe geçmiş tabloları kullanın (bir keresinde derinlemesine altı katman buldum).
• Sorguları önbelleğe almayın. Hiç.
• Bir değişkeni birden fazla sayfada mı kullanacaksınız? Uygulama kapsamı
• Her sayfa kendi deneme / yakalama bloğudur. Global bir hata işleyicisine ihtiyacımız yok / istemiyoruz.

Bunları bıraktıktan sonra değiştirmeye başladım.

C ++ kodlayıcısı olarak hayatımda, iki kötü "kural" uygulandı:

1. "STL kullanamıyoruz, çünkü VC ++ 4.1 desteklemiyor (ve şu anda VC ++ 6.0'a geçemiyoruz)."
2. "Do not ; ben (proje liderinin adı silinmiş) Öğrenci olarak yazdığı Heapsort algoritmasının bu uygulamayı kullanır o Ey olabilir çünkü (n ^ 2) kötü durumlarda, Quicksort kullanıyoruz."

Tüm sınıflar ve sınıf üyeleri için XML belgelerine sahip olmak zorundayım. Özel dahil Varsayılan ghostdoc yorumları kullanmaya teşvik edildim.

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