it-swarm.dev

Hangi şeyler koda bakarken anında alarm zilleri çalar?

Birkaç hafta önce bir yazılım işçiliği etkinliğine katıldım ve yapılan yorumlardan biri "Eminim hepimiz gördüğümüzde kötü kodu tanıdığımız" ve herkes daha fazla tartışma yapmadan başını salladı.

Herkesin ortalamanın üzerinde bir sürücü olduğunu düşündüğü bir gerçekçilik olduğu için bu tür şeyler beni her zaman endişelendiriyor. Kötü kodu tanıyabildiğimi düşünsem de, insanların bloglarında ve sadece bir avuç kitapta nadiren ayrıntılı olarak tartışıldığı için kod kokusu olarak düşündükleri hakkında daha fazla bilgi edinmek isterim. Özellikle bir kod kokusu bir dilde duymak ilginç olurdu düşünüyorum ama bir dilde değil.

Kolay bir tane ile başlayacağım:

Yorumlanan kod oranı yüksek olan kaynak kontrolündeki kod - Neden orada? silinmek mi gerekiyordu? yarı bitmiş bir iş mi? belki de yorum yapılmamalıydı ve sadece birisi bir şeyi test ederken yapıldı? Şahsen ben burada sadece orada tek bir satır olsa bile bu tür şeyler gerçekten can sıkıcı buluyorum, ama kodun geri kalanı ile serpiştirilmiş büyük bloklar gördüğünüzde tamamen kabul edilemez. Ayrıca, kodun geri kalanının da şüpheli kalitede olabileceğinin bir göstergesidir.

98
FinnNk
/* Fuck this error */

Genellikle saçmalık içinde bulunur try..catch blok, dikkatimi çekme eğilimindedir. Hemen yanı sıra /* Not sure what this does, but removing it breaks the build */.

Birkaç şey daha:

  • Birden çok iç içe karmaşık if ifadesi
  • Düzenli olarak bir mantık akışını belirlemek için kullanılan try-catch blokları
  • Genel adlara sahip işlevler process, data, change, rework, modify
  • 100 satırda altı veya yedi farklı destek stili

Bir tane buldum:

/* Stupid database */
$conn = null;
while(!$conn) {
    $conn = mysql_connect("localhost", "root", "[pass removed]");
}
/* Finally! */
echo("Connected successfully.");

Doğru, çünkü MySQL bağlantılarınızı zorlamak zorunda kalmak doğru şeyleri yapmaktır. Veritabanının bağlantı sayısı ile ilgili sorunları olduğu ortaya çıktı, böylece zaman aşımına uğradılar. Bunu hata ayıklamak yerine, işe yarayana kadar tekrar tekrar denediler.

128
Josh K

Benim için büyük kırmızı bayrak yinelenen kod bloklarıdır, çünkü kişinin ya programlama temellerini anlamadığını ya da mevcut bir kod tabanında uygun değişiklikleri yapmaktan çok korktuğunu gösterir.

Ayrıca kırmızı bayrak olarak yorum eksikliğini sayıyordum, ancak son zamanlarda yorum yapmadan çok iyi bir kod üzerinde çalıştım.

104
Ben Hughes

Gerçek bir değer katmamasına rağmen, programlayıcının ne kadar akıllı olduğunu göstermeye çalışan kod:

x ^= y ^= x ^= y;
74
Rei Miyasaka
  • 20.000 (abartı) çizgi fonksiyonu. Birkaç ekrandan daha fazlasını gerektiren herhangi bir işlev yeniden çarpanlarına ayırma gerektirir.

  • Aynı çizgiler boyunca, sonsuza kadar sürecek gibi görünen sınıf dosyaları. Muhtemelen, içsel yöntemler olmadıkça, orijinal sınıfın amacını ve işlevini ve muhtemelen nerede kullanıldığını temizleyecek sınıflara çıkarılabilecek birkaç kavram vardır.

  • tanımlayıcı olmayan, önemsiz olmayan değişkenler veya çok fazla önemsiz tanımlayıcı olmayan değişken. Bunlar gerçekte bir bilmece olan şeyi çıkarır.

62
{ Let it Leak, people have good enough computers to cope these days }

Daha da kötüsü, bu ticari bir kütüphaneden geliyor!

61
Reallyethical

İngilizce derleyici olsaydı, mükemmel bir şekilde derlenip çalışacak, ancak kodun yapmadığı hiçbir şeyi açıklamayacak kadar ayrıntılı yorumlar.

//Copy the value of y to temp.
temp = y;
//Copy the value of x to y.
y = x;
//Copy the value of temp to x.
x = temp;

Ayrıca, kaldırılabilecek kodla ilgili yorumlar, kodun bazı temel yönergelere uymasını sağlamıştır:

//Set the age of the user to 13.
a = 13;
53
Rei Miyasaka

Derlendiğinde uyarı üreten kod.

42
Rei Miyasaka

Açıklayıcı adlar yerine adda sayı bulunan işlevler, gibi:

void doSomething()
{
}

void doSomething2()
{
}

Lütfen, işlev adlarının bir anlam ifade etmesini sağlayın! DoSomething ve doSomething2 benzer şeyler yaparsa, farklılıkları ayıran işlev adlarını kullanın. DoSomething2, doSomething işlevinin bir kopuşuysa, işlevselliği için adlandırın.

36
Wonko the Sane

Sihirli Sayılar veya Sihirli Dizeler.

   if (accountBalance>200) { sendInvoice(...); }

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }
36
JohnFx
  • Belki de en kötüsü değil, uygulayıcıların seviyesini açıkça göstermektedir:

    if(something == true) 
    
  • Bir dilin for döngüsü veya yineleyici yapısı varsa, while döngüsünün kullanılması uygulayıcıların dili anlama düzeyini de gösterir:

    count = 0; 
    while(count < items.size()){
       do stuff
       count ++; 
    }
    
    for(i = 0; i < items.size(); i++){
      do stuff 
    }
    //Sure this is not terrible but use the language the way it was meant to be used.
    
  • Belgede/yorumlarda kötü yazım/dilbilgisi neredeyse benim kadar kod yiyor. Bunun nedeni, kodun insanların okuması ve makinelerin çalışması için kullanılmasıdır. Bu yüzden yüksek seviyeli dilleri kullanıyoruz, eğer belgelerinizin ulaşılması zorsa, kod tabanına bakmadan önleyici olarak olumsuz bir görüş oluşturmamı sağlıyor.

36
Chris

Hemen fark ettiğim, derin iç içe kod blokları (eğer, while, vb) sıklığıdır. Kod sık sık iki veya üç seviyeden daha derine iniyorsa, bu bir tasarım/mantık sorununun işaretidir. Ve eğer 8 yuva derinliğine inerse, kırılmaması için iyi bir neden olabilir.

29
GrandmasterB

Bir öğrencinin programını derecelendirirken bazen "göz kırpma" tarzında bir an söyleyebilirim. İşte anlık ipuçları:

  • Kötü veya tutarsız biçimlendirme
  • Üst üste ikiden fazla boş satır
  • Standart dışı veya tutarsız adlandırma kuralları
  • Tekrarlanan kod, tekrarlar ne kadar çok sözlü olursa uyarı o kadar güçlü
  • Basit bir kod parçası ne olması çok karmaşıktır (örneğin, anaya aktarılan argümanları kıvrımlı bir şekilde kontrol etmek)

Nadiren ilk izlenimlerim yanlış ve bu uyarı çanları zamanın% 95'i doğru. Bir istisna için, dile yeni bir öğrenci farklı bir programlama dilinden bir stil kullanıyordu. Diğer dilin deyimiyle içeri girip stillerini tekrar okumak benim için alarm zillerini kaldırdı ve öğrenci tam olarak kredi aldı. Ancak bu tür istisnalar nadirdir.

Daha gelişmiş kodlar düşünüldüğünde, bunlar benim diğer uyarılarım:

  • çok sayıda Java verilerin tutulması için yalnızca “yapı” olan sınıfların varlığı. alanlar genel veya özeldir ve alıcıları/ayarlayıcıları kullanır, yine de iyi düşünülmüş bir tasarımın parçası değildir.
  • Sadece bir ad alanı olmak ve kodda gerçek bir uyum olmaması gibi zayıf isimlere sahip sınıflar
  • Kodda bile kullanılmayan tasarım modellerine referans
  • Açıklama olmadan boş istisna işleyicileri
  • Eclipse kodunu çektiğimde, çoğunlukla kullanılmayan ithalatlar veya değişkenler nedeniyle yüzlerce sarı "uyarı" kodu kodlar

Stil açısından, genellikle görmek istemiyorum:

  • Javadoc sadece kodu yansıtan yorumlar

Bunlar sadece ipuçları için kötü kod. Bazen kötü kod gibi görünen şey gerçekten değildir, çünkü programcının niyetlerini bilmiyorsunuzdur. Örneğin, bir şeyin aşırı karmaşık görünmesinin iyi bir nedeni olabilir - oyunda başka bir husus olabilir.

28
Macneil

Kişisel favori/evde beslenen hayvan peeve: IDE oluşturulan adları taahhüt. Eğer TextBox1 sisteminizde önemli ve önemli bir değişken ise, kod inceleme geliyor başka bir şey var.

25
Wyatt Barnett

Tamamen kullanılmayan değişkenler, özellikle değişken kullanılan değişken adlarına benzer bir ada sahipse.

25
C. Ross

Bir çok insan bahsetti:

//TODO: [something not implemented]

Bu şeylerin uygulanmasını isterdim, en azından not aldılar. Ne kötü olduğunu düşünüyorum:

//TODO: [something that is already implemented]

Todo onları kaldırmak için rahatsız asla değersiz ve kafa karıştırıcı!

21
Morgan Herlocker

Yöntem adlarındaki bağlaçlar:

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

Açıklama: Alarm zillerinin çalmasının nedeni, yöntemin tek sorumluluk ilkesi ihlal edebileceğini göstermesidir.

20
JohnFx

Hepsini okumak için aşağı kaydırmamı gerektiren bir yöntem.

20
BradB

GPL'd kaynak kodunun ticari, kapalı kaynak programına bağlanması açıktır.

Sadece acil bir hukuki sorun yaratmakla kalmaz, aynı zamanda benim tecrübelerime göre, kodda başka bir yere de yansıyan dikkatsizliği veya ilgisizliği gösterir.

13
Bob Murphy

Dil bilgisi yok:

  • TODO: not implemented
  • int function(...) { return -1; } ("uygulanmadı" ile aynı)
  • İstisnai olmayan bir nedenle istisna atma.
  • İstisnai dönüş değerleri olarak 0, -1 Veya null 'ın yanlış veya tutarsız kullanımı.
  • Neden asla başarısız olmaması gerektiğini söyleyen ikna edici yorum içermeyen iddialar.

Dile özgü (C++):

  • C++ Makroları küçük harflidir.
  • Statik veya Global C++ değişkenleri.
  • Başlatılmamış veya kullanılmayan değişkenler.
  • Görünüşe göre RAII açısından güvenli olmayan tüm array new.
  • Görünüşe göre sınır güvenli olmayan herhangi bir dizi veya işaretçi kullanımı. Buna printf dahildir.
  • Bir dizinin başlatılmamış bölümünün herhangi bir şekilde kullanılması.

Microsoft C++ 'ya özel:

  • Microsoft SDK başlık dosyalarından herhangi biri tarafından önceden tanımlanmış bir makroyla çakışan tanımlayıcı adları.
  • Genel olarak, Win32 API'nın herhangi bir kullanımı alarm zillerinin büyük bir kaynağıdır. Her zaman MSDN'yi açın ve şüpheye düştüğünüzde argüman/dönüş değeri tanımlarına bakın. (Edited)

C++/OOP'ye özgü:

  • Ana sınıfın hem sanal hem de sanal olmayan yöntemlere sahip olduğu ve sanal olmamalı/olmamalı arasında açık ve belirgin bir kavramsal ayrım olmadan uygulama (somut sınıf) kalıtım.
9
rwong

Numaralandırmalar veya genel olarak tanımlanmış değişkenler yerine çok sayıda metin bloğu kullanma.

İyi değil:

if (itemType == "Student") { ... }

Daha iyi:

private enum itemTypeEnum {
  Student,
  Teacher
}
if (itemType == itemTypeEnum.Student.ToString()) { ... }

En iyi:

private itemTypeEnum itemType;
...
if (itemType == itemTypeEnum.Student) { ... }
8
Yaakov Ellis

Tuhaf girinti stili.

Birkaç popüler stil var ve insanlar bu tartışmayı Mezar'a götürecek. Ama bazen birisinin gerçekten nadir, hatta evde yetiştirilen bir girinti stili kullandığını görüyorum. Bu, muhtemelen kendilerinden başka kimseyle kodlamadıklarının bir işaretidir.

8
Ken

Yöntemlerde zayıf yazılan parametreler veya dönüş değerleri.

public DataTable GetEmployees() {...}

public DateTime getHireDate(DataTable EmployeeInfo) {...}

public void FireEmployee(Object EmployeeObjectOrEmployeeID) {...}
8
JohnFx

Kod kokusu: en iyi uygulamaları takip etmemek

Herkesin ortalamanın üzerinde bir sürücü olduğunu düşündüğü bir gerçekçilik olduğu için bu tür şeyler beni her zaman endişelendiriyor.

İşte sizin için bir haber flaşı: Dünya nüfusunun% 50'si ortalama zekanın altında. Tamam, bazı insanlar tam olarak ortalama bir zekaya sahip olacaklardı, ama seçici olmayalım. Ayrıca, aptallığın yan etkilerinden biri de kendi aptallığınızı tanıyamazsınız! Bu ifadeleri birleştirirseniz işler çok iyi görünmüyor.

Hangi şeyler koda bakarken anında alarm zilleri çalar?

Birçok iyi şeyden bahsedildi ve genel olarak en iyi uygulamaları takip etmiyor bir kod kokusu gibi görünüyor.

En iyi uygulamalar genellikle rastgele icat edilmez ve genellikle bir nedenden ötürü vardır. Çoğu zaman öznel olabilir, ancak tecrübelerime göre çoğunlukla haklıdırlar. En iyi uygulamaları takip etmek bir sorun olmamalı ve neden oldukları gibi olduğunu merak ediyorsanız, görmezden gelmek ve/veya şikayet etmek yerine araştırın - belki de haklı, belki de değil.

En iyi uygulamalardan biri, yalnızca bir satır içermesine rağmen, her if bloğuyla kıvrımlar kullanmak olabilir:

if (something) {
    // whatever
}

Bunun gerekli olduğunu düşünmeyebilirsiniz, ama son zamanlarda read bunun büyük bir hata kaynağı olduğunu düşünüyorum. Her zaman köşeli parantez kullanımı da Stack Overflow üzerinde tartışılmıştır ve eğer deyimlerin köşeli parantez olup olmadığını kontrol etmek de bir kural olarak PMD , Java için statik bir kod analizörü.

Unutmayın: "Çünkü bu en iyi yöntemdir", "bunu neden yapıyorsunuz?" Sorusuna asla kabul edilebilir bir cevap değildir. Bir şeyin neden en iyi uygulama olduğunu açıklayamıyorsanız, o zaman en iyi uygulama değil, bir batıl inançtır.

7
Vetle
  • Birden fazla üçlü operatör birbirine yaslandı, bu nedenle if...else Bloğuna benzemek yerine, if...else if...[...]...else Bloğu haline geliyor
  • Alt çizgi veya deve tuşu olmadan uzun değişken adları. Bazı kod örnek ben çekti: $lesseeloginaccountservice
  • Bir dosyada yüzlerce kod satırı, çok az yorum var veya hiç yorum yok ve kod çok açık değil
  • Aşırı karmaşık if ifadeleri. if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL)) için seçtiğim koddan örnek: if ($lessee_obj == null)
7
Tarka

Genel istisnaları yakalamak:

try {

 ...

} catch {
}

veya

try {

 ...

} catch (Exception ex) {
}

Bölge aşırı kullanımı

Tipik olarak, çok fazla bölge kullanmak bana sınıflarınızın çok büyük olduğunu gösterir. Bu kod biraz daha araştırmak gerektiğini işaret bir uyarı bayrağı.

6
Erik van Brakel

Herkes kodun bir dosyaya mutlak yolla meşru olarak başvurması gereken bir örnek düşünebilir mi?

6
Rei Miyasaka

"Bunun nedeni, froz alt sisteminin tasarımının tamamen dolmasıdır."

Bu, tüm paragraf boyunca devam ediyor.

Aşağıdaki refactorun olması gerektiğini açıklarlar.

Ama yapmadı.

Şimdi, zaman veya yeterlilik sorunları nedeniyle patronları tarafından o zaman değiştiremedikleri söylenmiş olabilir, ama belki de bu, insanların küçük olması nedeniyle olabilir.

Bir süpervizör bu j.random'u düşünürse. programcı yeniden düzenleme yapamaz, o zaman süpervizör bunu yapmalıdır.

Her neyse, bu, kodun olası iktidar politikalarıyla bölünmüş bir ekip tarafından yazıldığını biliyorum ve onlar alçakgönüllü alt sistem tasarımlarını yeniden düzenlemediler.

Gerçek hikaye. Senin başına gelebilirdi.

6
Tim Williscroft
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...

Tabii ki herhangi bir belge ve arada sırada iç içe _ #defines

5
Sven

Açık silme ifadeleri ile C++ kodu (akıllı işaretçi uygulamasının içlerine bakmadıkça). 'delete', bellek yönetiminin 'git' seçeneğidir IMHO .

Bununla yakından ilgili, şöyle kodlayın:

// Caller must take ownership
Thing* Foo::Bar()

(Ve yorum varsa kendinizi şanslı sayın!). Akıllı işaretçiler roket bilimi gibi değil. std::auto_ptr bu tür bir şey için yapılır (dokümantasyonda ve açıklamada ifade edilen niyetin uygulanması) ve standart = şimdi çağlar boyunca.

Bu sevgisiz miras kodunu veya zihniyete sahip koruyucular birlikte 90'ların başında bir yere yapıştı.

5
timday

Dilin temel işlevlerini yeniden şekillendiren işlevler. Örneğin, JavaScript'te bir dizenin ".length" özelliğine çağrı yapmak yerine "getStringLength ()" yöntemini görürseniz, başınızın belada olduğunu bilirsiniz.

5
Ant

Oluşturmaya çalıştıkları soyutlamanın iyi anlaşılmadığını gösteren sınıf adlandırma kuralları. Ya da bu hiçbir soyutlamayı tanımlamaz.

Bir VB sınıfında Data başlıklı ve 30.000+ satır uzunluğunda bir kez gördüğüm) aşırı bir örnek akla geliyor - first En az yarım düzine başka dosyaya bölünmüş kısmi bir sınıftır.Yöntemlerin çoğu, FindXByYWithZ() gibi adlara sahip kayıtlı procların etrafındaki sarmalayıcılardı.

Daha az dramatik örneklerle bile, eminim, tamamen jenerik bir başlık verildiğinde ve daha sonra pişman olduktan sonra, zayıf bir şekilde tasavvur edilen bir sınıfa “doping” ettik.

5
Bryan M.
ON ERROR RESUME NEXT

Klasik ASP uygulamalarını korumak zorunda olmak çoğu ASP.NET geliştiricisi için ne yazık ki bir zorunluluktur, ancak ortak bir içerme dosyası açmak ve ilk satırda ruh yok etme olduğunu görmek.

4
richeym

Kodun ne yaptığına veya ne yapması gerektiğine dair herhangi bir yorum veya belge olmadığında (yani, kod belgelerdir).

Sonek olarak bir sayıya sahip yöntemler veya değişkenler (ör. Login2 ()).

4
leson
try
{
//do something
}
catch{}
3
Tom Squires

Yürütme yoluna mantıksal olarak giremeyen kod.

var product = repository.FindProduct(id);

log.Info("Found product " + product.Name);

if (product != null)
{
    // This will always happen
}
else
{
    // **This won't ever happen**
}

veya

if (messages.Count > 0)
{
    // Do stuff with messages
}
else if (messages.Count == 1)
{
    // **I hope this code isn't important...**
}
3
rmac
  • Her yerel değişkeni yöntem bloğunun ilk birkaç satırına koymak. Özellikle uzun yöntemlerle birlikte.
  • Yalnızca break/continue kullanmak yerine döngülerden çıkmak/yineleme atlamak için boole değişkenlerini kullanma
3
Oliver Weiler

Java merkezli bakış açımdan:

  • Standart olmayan kodlama stili.
  • Özel olmayan değişkenler.
  • Alanlarda final eksik.
  • Anlamsız veya aşırı miras.
  • Büyük sınıflar veya kod blokları.
  • Çok fazla yorum var (muhtemelen sadece düşünmek istiyorlar).
  • Yapılandırılmamış günlük kaydı.
  • Harfler ve ayarlayıcılar (arayüzler davranışla ilgili olmalıdır).
  • Yinelenen veriler.
  • Garip bağımlılıklar.
  • İş parçacığı küreselleri dahil statik.
  • Çok iş parçacıklı kod için, aynı sınıfın farklı iş parçacıklarında (özellikle GUI kodu) çalıştırılması beklenen parçalar.
  • Ölü kod.
  • Diğer kodlarla karıştırılmış dize düzenleme.
  • Genel olarak katmanları karıştırmak (bir dizi ilkel veya iplik işleme üzerinde yineleme ile birlikte daha yüksek seviye şeyler).
  • Herhangi bir yansıma kullanımı.
  • catch yararlı kod olmadan engeller (kötü: yorumlar, printf, günlük kaydı veya sadece boş).
3

Düzgün kapsamlandırılmış ve türünde bir değişken tanımlamak yerine bir değeri saklamak için kullanıcı arabiriminde (örneğin, bir metin kutusu) gizli bir nesne kullanma.

2
MartW

Her zaman aşağıdakileri okudum:

//Don't put in negative numbers or it will crash the program.

Veya benzeri. Eğer durum buysa, bir iddiada bulunun! Hata ayıklayıcıya çalışma süresi boyunca bu değerleri istemediğinizi bildirin ve kodun arayan ile sözleşmeyi açıkladığından emin olun.

2
wheaties

Bu kod türü:

        if (pflayerdef.DefinitionExpression == "NM_FIELD = '  '" || One.Two.nmEA == "" || 
            One.Two.nmEA == " " || One.Two.nmEA == null ||
            One.Two.nmEA == "  ")
        {                
            MessageBox.Show("BAD CODE");
            return;
        }

Bu gerçek bir canlı prodüksiyon temelinden!

2
George Silva

Sihirli sayılar gelince: farklı yerlerde kullanılırlarsa kötüdürler ve değiştirmek birkaç yerde senkronize etmenizi gerektirir. Ancak bir yerde bir sayı, hala bir yerde kullanılan bir sayıyı belirtmek için bir sabite sahip olmaktan daha kötü değildir.

Ayrıca, sabitlerin başvurunuzda fazla yeri olmayabilir. Birçok veritabanı uygulamasında, bu şeyler veritabanında uygulamaya veya kullanıcı ayarlarına göre depolanmalıdır. Ve uygulamalarını tamamlamak için, bu ayarı ve kullanıcı arayüzünde bir yeri ve son kullanıcı belgelerinde bir notu içerirler ... hepsi saygın bir mühendislik ve sayı 5 olduğunda herkes mutlu olduğunda kaynak kaybıdır ( ve 5 öyle.)

Sanırım bu numarayı o yerin dışında kullanmaya ihtiyaç duyana kadar sayıları ve karakter dizilerini yerinde bırakabilirsiniz. O zaman işleri daha esnek bir tasarıma yeniden yansıtmanın zamanı geldi.

Dizeleri gelince ... Argümanları biliyorum, ama bu bir yer daha bir-bir-dize-bir-sabit dönüşüm yapmak için hiçbir anlamı yoktur. Özellikle yürürlükte olan dizeler yine de sabit bir uygulamadan geliyorsa (örneğin, bir dış uygulamadan oluşturulan ve tıpkı 'Vadesi geçmiş' gibi kısa ve tanınabilir bir durum dizgisine sahip olan içe aktarmalar.) Zaten yalnızca tek bir yerde kullanıldığında, "Gecikmiş" i STATUS_OVERDUE değerine dönüştürmenin önemli bir noktası.

Aslında esneklik, yeniden kullanım veya hata kontrolü için gerekli faydaları yaratmazsa karmaşıklık eklememekten dolayı çok fazlayım. Esnekliğe ihtiyacınız olduğunda, doğru kodlayın (refactor thingy). Ama gerekmiyorsa ...

2
Inca

Sıkı birleştirilmiş kod. Özellikle kodun ortasında sabit kodlanmış (ağ yazıcılarının adları, IP adresleri vb.) Birçok şey gördüğünüzde. Bunlar bir yapılandırma dosyasında veya hatta sabitlerde olmalıdır, ancak aşağıdakiler sadece sorunlara neden olacaktır:

if (Host_ip == '192.168.1.5'){
   printer = '192.168.1.123';
} else
  printer = 'prntrBob';

Bir gün Bob çıkacak ve yazıcısı yeniden adlandırılacak. Bir gün yazıcı yeni bir IP adresi alacaktır. Bir gün 192.168.1.5, Bob'un yazıcısına yazdırmak isteyecektir.

en sevdiğim mantra: her zaman nerede yaşadığını bilen bir cinayet psikopati gibi kod yaz!

2
davidhaskins

Programcının yıllar önce asla Java 5] 'e uyum sağlamadığını gösteren kod

  • “Her biri için” yerine Yineleyici Kullanımı
  • Koleksiyonlarda jenerik kullanmamak ve alınan nesneleri beklenen türe dökmek
  • Vector ve Hashtable gibi eski sınıfları kullanma

Modern çoklu kullanım yollarını bilmemek.

2
Dave Briccetti

SQL için:

İlk büyük gösterge, zımni birleşimlerin kullanılmasıdır.

Ardından, aşağıdaki gibi bir WHERE yan tümcesi ile birleştirilmiş tableB'de sol birleştirme kullanımı:

WHERE TableB.myField = 'test'

Bu yanlış sonuçlar verecektir bilmiyorsanız o zaman yazdığınız herhangi bir sorgu doğru sonuçlar verecektir güvenemiyorum.

2
HLGEM

Eski VB6 kodumuz, herhangi bir Modül veya form kodu sayfasını açabilir ve Genel veya Global # & @ ile dolu bir ekran bulabilirsiniz! üstte bildirilen değişkenler @ &! ! (*! # programından referans alınmıştır. ARGH !!!!

(Vay canına, onu dışarı çıkarmak zorunda kaldım :-))

2
HardCode

Böyle bir şey

x.y.z.a[b].c

Bu biyolojik tehlike gibi kokuyor. Bu kadar üye referansı asla iyi bir işaret değildir.Ve evet bu birlikte çalıştığım kodda tipik bir ifadedir.

2
Gaurav

böyle bir şey olan herhangi bir şey

// TODO: anything could be here!

Edit: Bunu üretim kodunda kastettiğimi belirtmeliyim. Ancak kaynak kontrolüne bağlı kodlarda bile bu hala iyi değil. Ama bu kişisel bir şey olabilir, çünkü tüm gevşek uçlarımı bağlayarak günü bitirmek istiyorum :)

Edit 2: Ayrıca, bunu yerleşik kodda gördüğümde kastediyorum. Birkaç yıllık bir şey gibi ve bir hatayı düzeltiyorum. Bir TODO görüyorum ve o zaman alarm zilleri çalmaya başladı. YAPILACAKLAR (bana göre), kodun hiçbir nedenle bitmediğini ima ediyor.

2
Antony Scott

Java'da synchronized anahtar kelimesinin kullanımı.

Doğru kullanıldığında synchronized ile ilgili yanlış bir şey olmadığı için değil. Ama birlikte çalıştığım kodda, birisi threadsafe kodu yazmaya çalıştığında yanlış anlıyorlar. Bu anahtar kelimeyi görürsem, kodun geri kalanı konusunda daha dikkatli olmalıyım ...

1
Guillaume

Daha iyi bir yapı ile optimize edilebilen kod üzerinde gözetleme deliği optimizasyonları, ör. Düz C/C++/Java/C # 'da ikili arama uygun (ve daha hızlı) olduğunda satır içi Montajda uygulanan doğrusal aramalar.

Kişi ya bazı temel kavramları eksik ya da hiçbir öncelik duygusu yoktur. İkincisi çok daha endişe verici.

1
Rei Miyasaka

@FinnNk, yorum kodu hakkında size katılıyorum. Bana gerçekten böcek ne gibi şeyler:

for (var i = 0; i < num; i++) {
    //alert(i);
}

veya test veya hata ayıklama için orada olan ve yorum yapıp sonra işlenen herhangi bir şey. Sadece ara sıra ise, büyük bir anlaşma değil, ama her yerde ise, kodu karıştırır ve neler olduğunu görmeyi zorlaştırır.

1
Elias Zamaria
  • $ data - Bu "Fiziksel nesneler, şimdi 5'de gülünç derecede düşük 100!"
  • Koddaki TODO öğeleri - Bir dosya düzeyinde değil, ürün düzeyinde neyin gerekli olduğunu bilmesi için hata/bilet/sorun izleyici kullanın.
  • Çalışma oturum açma kodu - Sürüm kontrolü bunun içindir.
1
l0b0

Önemli ilkeleri ihlal eden her şey. Örneğin, birkaç anti-desen önerilmiştir (sihirli sayı - bkz http://en.wikipedia.org/wiki/Anti-pattern ). Anti-paternler denir çünkü problemlere neden olurlar (daha önce de belirtilmiştir - kırılganlık, bakım kabusları, vb.). Ayrıca, SOLID ilkelerinin ihlaline dikkat edin - bkz http://en.wikipedia.org/wiki/Solid_ (nesne yönelimli_design) Ayrıca, Katmanların ayrılmasını göz önünde bulundurmayın (kullanıcı arayüzü içindeki veri erişim şeyleri vb.) Kodlama standartlarına ve kod incelemelerine sahip olmak bununla mücadelede yardımcı olur.

1
Tim Claason

Bunların çoğu Java deneyim:

  • Dize yazma. Sadece hayır.
  • Typecasting genellikle modern Java'da bir kod kokusuna işaret eder.
  • Pokemon Exception anti-paterni (hepsini yakalamanız gerektiğinde).
  • Cargo-kült uygun olmadığı durumlarda fonksiyonel programlamaya çalışır.
  • Uygun olduğu yerde işlevsel bir yapı (Callable, Function vb.) Kullanmamak.
  • Polimorfizmden yararlanamama.
1
Ben Hardy

Kod dağınık gibi göründüğünde: "todo" ve "self to note" ve topal şakaları olan yorumlar. Belli bir noktada sadece hata ayıklama amacıyla kullanılan ancak daha sonra kaldırılmayan kod. Yazarın daha sonra kimsenin okuyacağını düşünmediğini öneren değişkenler veya işlevler. Genellikle bu isimler çok uzun ve hantal olur.

Ayrıca: Kodda ritim yoksa. Çılgınca ıraksak uzunluktaki fonksiyonlar. Aynı adlandırma şemalarına uymayan işlevler.

Biraz ilgili: Bir programcının sloby el yazısına sahip olması beni her zaman sinirlendirir. Ya da kötü yazarlar ya da kötü iletişimciler ise.

1
KaptajnKold

Bir keresinde yüklenicinin, isimlerden göstergelere kadar belirsiz isimlere kadar her standart veri türünü int'den dizeye yazdığı bir proje üzerinde çalıştım. Onun yaklaşımı kodu anlamayı gerçekten zorlaştırdı. Beni uyaran bir başka stil de erken esneklik; bir zamanlar üzerinde çalıştığım bir ürün, tahmin edilebilir bir sırada yüklenmeyen DLL'lerin tam koduna sahipti. Bütün bunlar gelecekteki evrimi barındırmak için. Birkaç DLL, taşınabilirlik için iş parçacığı sarmalayıcıları kullandı. Kaynak kodu okuyarak programda hata ayıklamak veya akışı tahmin etmek bir kabustu. Tanımlar başlık dosyalarına dağıtılmıştır. Kodun ikinci versiyonun ötesinde hayatta kalması şaşırtıcı değildi.

1
VKs

Bazen bir yöntemin olası tüm girdileri veren kısımlarını görüyorum, yine de ASLA koşmazdı, bu yüzden başta kafa karıştırıcı insanlar olmamalı. Bir örnek ...
Yöntem yalnızca Yönetici süper kullanıcısı bağlamında çağrılabilirse ve istek kullanıcısının Yönetici süper kullanıcısı olup olmadığını kontrol eden bir şey görürsem ...: /

1
chiurox

Kısıtlama eksikliğini gösteren hoşnutsuz yorumlar:

//I CAN'T GET THIS F^#*&^ING PIECE OF S$^* TO COMPILE ON M$VC

Ya kötü huyludurlar ya da aksiliklerin programlamada kaçınılmaz olduğunu öğrenecek kadar deneyimli değildirler.

Böyle insanlarla çalışmak istemiyorum.

1
Rei Miyasaka

Bu, diğerlerinin listelediği şeylere kıyasla biraz küçük bir belirtidir, ancak ben Python programcıyım ve sıklıkla kod tabanımızda görüyorum:

try:
    do_something()
except:
    pass

Bu da bana genellikle programlayıcının neden do_something başarısız olabilir (ya da ne yapar) - sadece kod artık çökmedi kadar "kıpır kıpır" tuttu.


Daha fazla Java esque arka planından gelenler için, bu blok Python

try {
    doSomething();
} catch (Exception e) {
    // Don't do anything. Don't even log the error.
}

Mesele şu ki, Python klavye kesintileri veya bir for döngüsünden çıkmak gibi "istisnai olmayan" kod için istisnalar kullanır.

1
mipadi

her yerde getters beni ucube yapmak.

ve özel bir şey: diğer alıcılara delege olan alıcılar.

bu kötüdür, çünkü nesne yöneliminin temelini anlamayan, yani kapsülleme olan, yani verinin nerede olduğu, bu veriler üzerinde hareket eden yöntemlerin olması gerektiği anlamına gelen kişi anlamına gelir.

temsilci tüm alıcılar için değil tek bir yöntem içindir. prensip "anlat, sorma"; bir nesneye bir şey söyle, bin şey sorma ve sonra kendin yap.

getters beni korkutuyor, çünkü diğer oop ilkelerinin sert çekirdeği ihlal edileceği anlamına geliyor.

0
Belun

Eksik tür bilgisi.

Bu yöntem imzalarına bir göz atın:

  1. public List<Invoice> GetInvoices(Customer c, Date d1, Date d2)

  2. public GetInvoices(c, d1, d2)

(1) 'de netlik vardır. Fonksiyonu hangi parametrelerle çağırmanız gerektiğini tam olarak bilirsiniz ve fonksiyonun ne döndürdüğü açıktır.

(2) 'de sadece belirsizlik vardır. Hangi parametreleri kullanacağınız hakkında hiçbir fikriniz yok ve bir şey olursa işlevin ne döndürdüğünü bilmiyorsunuz. Programlamaya verimsiz bir deneme yanılma yöntemi uygulamak zorundasınız.

0
ThomasX