it-swarm-eu.dev

Které věci okamžitě zazvoní poplachové zvonky, když se podíváme na kód?

Zúčastnil jsem se softwarové řemeslné akce před pár týdny a jedním z vyjádřených komentářů bylo „Jsem si jistý, že všichni poznáme špatný kód, když ho vidíme“, a všichni bez váhání přikývli.

Taková věc mě vždycky trápí, protože je tu truismus, o kterém si každý myslí, že je nadprůměrný řidič. I když si myslím, že dokážu rozpoznat špatný kód, ráda bych se dozvěděla více o tom, co ostatní lidé považují za vůně kódu, protože je to jen zřídka podrobně diskutováno na blogy lidí a pouze v hrstce knih. Zejména si myslím, že by bylo zajímavé slyšet o čemkoli, co kódově voní v jednom jazyce, ale ne v jiném.

Začnu s jednoduchým:

Kód v řízení zdroje, který má vysoký podíl komentovaného kód - proč je tam? mělo to být vymazáno? je to polovina dokončené práce? možná by to nemělo být komentováno a bylo to provedeno pouze tehdy, když někdo něco testoval? Osobně považuji tento druh věcí za nepříjemný, i když je to jen zvláštní řádek sem a tam, ale když uvidíte velké bloky rozptýlené se zbytkem kódu, je to naprosto nepřijatelné. Je to také obvykle známkou toho, že zbytek kódu bude mít pravděpodobně také pochybnou kvalitu.

98
FinnNk
/* Fuck this error */

Obvykle se nachází uvnitř nesmyslu try..catch blok, má tendenci upoutat mou pozornost. Téměř stejně jako /* Not sure what this does, but removing it breaks the build */.

Ještě pár věcí:

  • Více vnořených komplexních příkazů if
  • Bloky try-catch, které se používají k pravidelnému určování logického toku
  • Funkce s obecnými názvy process, data, change, rework, modify
  • Šest nebo sedm různých stylů vyztužení ve 100 řádcích

Jeden jsem právě našel:

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

Správně, protože musíte brutálně vynucovat vaše připojení MySQL, je správný způsob, jak věci dělat. Ukázalo se, že databáze měla problémy s počtem připojení, takže stále vypršel časový limit. Místo toho, aby to odladili, jednoduše se pokusili znovu a znovu, dokud to nefungovalo.

128
Josh K

Hlavním červeným příznakem pro mě jsou duplicitní bloky kódu, protože to ukazuje, že daná osoba buď nerozumí základům programování, nebo byla příliš vyděšená na to, aby provedla správné změny stávající kódové základny.

Dříve jsem také počítal nedostatek komentářů jako červenou vlajku, ale když jsem nedávno pracoval na mnoha velmi dobrých kódech bez komentářů, uvolnil jsem se zpět.

104
Ben Hughes

Kód, který se snaží ukázat, jak chytrý je programátor, přestože nepřináší žádnou skutečnou hodnotu:

x ^= y ^= x ^= y;
74
Rei Miyasaka
  • 20 000 (nadsázkových) funkcí linky. Jakákoli funkce, která zabere více než několik obrazovek, potřebuje znovu faktorovat.

  • Ve stejných řádcích soubory třídy, které se zdají navždy pokračovat. Pravděpodobně existuje několik konceptů, které by mohly být abstrahovány do tříd, které by objasnily účel a funkci původní třídy a pravděpodobně tam, kde se používá, pokud nejsou všechny interní metody.

  • nepopisné, netriviální proměnné nebo příliš mnoho triviálních nepopisných proměnných. Tito dělají odvodit to, co se vlastně děje hádankou.

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

Co je horší, je to z komerční knihovny!

61
Reallyethical

Komentáře, které jsou tak výstižné, že pokud by existoval anglický kompilátor, kompilovaly by se a fungovaly dokonale, ale nepopisují nic, co kód ne.

//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;

Také komentáře k kódu, které by mohly být odstraněny, kdyby tento kód dodržoval některé základní pokyny:

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

Kód, který při kompilaci vytváří varování.

42
Rei Miyasaka

Funkce s čísly v názvu namísto popisných jmen, jako:

void doSomething()
{
}

void doSomething2()
{
}

Prosím, udělejte z názvu funkce něco! Pokud doSomething a doSomething2 dělají podobné věci, použijte názvy funkcí, které odlišují rozdíly. Pokud je doSomething2 vyřazením funkcí z doSomething, pojmenujte jej pro jeho funkčnost.

36
Wonko the Sane

Kouzelná čísla nebo Kouzelné řetězce.

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

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }
36
JohnFx
  • Možná ne nejhorší, ale jasně ukazuje úroveň implementátorů:

    if(something == true) 
    
  • Pokud má jazyk konstrukci for loop nebo iterator, pak použití while while také demonstruje úroveň porozumění implementátorům jazyka:

    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.
    
  • Špatné hláskování/gramatika v dokumentaci/komentářích jí téměř stejně jako samotný kód. Důvodem je to, že kód byl určen k tomu, aby si lidé mohli číst a stroje běžet. To je důvod, proč používáme jazyky na vysoké úrovni, pokud je vaše dokumentace obtížná projít, nutí mě tvořit negativní názor na kódovou základnu, aniž bychom se na ni dívali.

36
Chris

Ten, který si okamžitě všimnu, je frekvence hluboce vnořených bloků kód (pokud je, zatímco je atd.). Pokud je kód často hluboký více než dvě nebo tři úrovně, jedná se o znak problému s designem/logikou. A pokud to vypadá jako 8 hnízd, je lepší mít dobrý důvod, aby se nerozpadl.

29
GrandmasterB

Když hodnotím studentský program, můžu někdy říci „blikající“ stylovou chvíli. Toto jsou okamžité vodítka:

  • Špatné nebo nekonzistentní formátování
  • Více než dva prázdné řádky v řadě
  • Nestandardní nebo nekonzistentní konvence pojmenování
  • Opakovaný kód, čím více opakování opakuje, tím silnější je varování
  • To, co by měl být jednoduchý kus kódu, je příliš komplikované (např. Kontrola argumentů předaných hlavnímu spletitým způsobem)

Zřídka jsou moje první dojmy nesprávné a tyto varovné zvonky mají pravdu o 95% čas. Až na jednu výjimku, nový student jazyka používal styl z jiného programovacího jazyka. Vykopáním a opětovným přečtením jejich stylu v idiomu jiného jazyka pro mě byly odstraněny poplašné zvonky a student pak získal plný kredit. Tyto výjimky jsou však vzácné.

Při zvažování pokročilejšího kódu jsou to moje další varování:

  • Přítomnost mnoha Java tříd, které jsou pouze „strukturami“ pro uchovávání dat. Nezáleží na tom, zda pole jsou veřejná nebo soukromá a používají getery/setters, stále není pravděpodobné, že jsou součástí promyšlené konstrukce.
  • Třídy, které mají špatná jména, jako například být jmenným prostorem a v kódu neexistuje skutečná soudržnost
  • Odkaz na návrhové vzory, které se v kódu nepoužívají
  • Prázdné popisovače výjimek bez vysvětlení
  • Když vytáhnu kód v Eclipse, řádek kódu lemují stovky žlutých „upozornění“, hlavně kvůli nevyužitým importům nebo proměnným

Pokud jde o styl, obvykle se mi nelíbí:

  • Javadoc komentáře, které pouze opakují kód

To jsou pouze vodítka špatný kód. Někdy to, co se může zdát jako špatný kód, ve skutečnosti není, protože neznáte úmysly programátora. Například může existovat dobrý důvod, že se něco zdá být příliš složité - při hře mohlo být další uvažování.

28
Macneil

Osobní oblíbené/mazlíčkové mazlíčky: IDE generovaná jména, která se započítávají) Pokud je TextBox1 hlavní a důležitou proměnnou ve vašem systému, přichází další věc, která přichází s kontrolou kódu.

25
Wyatt Barnett

Zcela nepoužité proměnné, zejména pokud má proměnná název podobný použitým názvům proměnných.

25
C. Ross

Mnoho lidí zmínilo:

//TODO: [something not implemented]

I když si přeji, aby to bylo implementováno, alespoň si udělali poznámku. Horší je, že:

//TODO: [something that is already implemented]

Todo jsou bezcenné a matoucí, pokud se nikdy neobtěžujete je odstranit!

21
Morgan Herlocker

Spojení v názvech metod:

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

Objasnění: Důvodem, proč zvoní poplachové zvonky, je to, že to naznačuje, že metoda pravděpodobně porušuje princip jediné odpovědnosti .

20
JohnFx

Metoda, která vyžaduje, abych si to všechno přečetl.

20
BradB

Propojení zřejmě zdrojového kódu GPL do komerčního programu s uzavřeným zdrojem.

Nejen, že to vytváří okamžitý právní problém, ale podle mé zkušenosti to obvykle znamená buď nedbalost, nebo nezajímavost, což se odráží i jinde v kódu.

13
Bob Murphy

Jazyková agnostika:

  • TODO: not implemented
  • int function(...) { return -1; } (stejné jako „není implementováno“)
  • Házení výjimky z výjimečného důvodu.
  • Zneužití nebo nekonzistentní použití 0, -1 Nebo null jako výjimečných návratových hodnot.
  • Tvrzení bez přesvědčivého komentáře, proč by nikdy neměla selhat.

Jazyk specifický (C++):

  • Makra C++ malými písmeny.
  • Statické nebo globální proměnné C++.
  • Neinicializované nebo nepoužité proměnné.
  • Jakýkoli array new, Který zřejmě není bezpečný pro RAII.
  • Jakékoli použití pole nebo ukazatele, které zjevně není bezpečné. To zahrnuje printf.
  • Jakékoli použití neinicializované části pole.

specifické pro Microsoft C++:

  • Jakýkoli název identifikátoru, který se srazí s makrem již definovaným v kterémkoli ze souborů záhlaví Microsoft SDK.
  • Obecně je jakékoli použití rozhraní API Win32 velkým zdrojem poplachových zvonků. Vždy mějte MSDN otevřený a v případě pochybností vyhledejte definice argumentů/návratových hodnot. (Upraveno)

specifické pro C++/OOP:

  • Implementace (konkrétní třída) dědičnost, kdy nadřazená třída má jak virtuální, tak ne virtuální metody, bez jasného koncepčního rozlišení mezi tím, co by mělo/nemělo být virtuální.
9
rwong

Používá spousty textových bloků spíše než výčty nebo globálně definované proměnné.

Špatný:

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

Lepší:

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

Nejlepší:

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

Bizarní styl odsazení.

Existuje několik velmi populárních stylů a lidé tuto debatu vezmou do hrobu. Ale někdy vidím někoho, kdo používá opravdu vzácný nebo dokonce domácí pěstovací styl. To je známkou toho, že pravděpodobně nekódovali s nikým jiným než s sebou.

8
Ken

Špatně zadané parametry nebo návratové hodnoty metod.

public DataTable GetEmployees() {...}

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

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

Vůně kódu: nedodržování osvědčených postupů

Taková věc mě vždycky trápí, protože je tu truismus, o kterém si každý myslí, že je nadprůměrný řidič.

Teď je pro tebe novinka: 50% světové populace je podprůměrnou inteligencí. Dobře, takže někteří lidé by měli přesně průměrnou inteligenci, ale nechme se vybírat. Jedním z vedlejších účinků hlouposti je, že nedokážete rozpoznat svou vlastní hloupost! Věci nevypadají tak dobře, pokud zkombinujete tato tvrzení.

Které věci okamžitě zazvoní poplachové zvonky, když se podíváme na kód?

Bylo zmíněno mnoho dobrých věcí a obecně se zdá, že nedodržování osvědčených postupů je vůně kódu.

Osvědčené postupy se obvykle nevymýšlejí náhodně a často se vyskytují z nějakého důvodu. Mnohokrát to může být subjektivní, ale podle mých zkušeností jsou většinou oprávněné. Dodržování osvědčených postupů by nemělo být problémem, a pokud vás zajímá, proč jsou takové, jaké jsou, zkuste to spíše než ignorovat a/nebo si na ně stěžovat - možná je to odůvodněné, možná to není.

Příkladem nejlepší praxe může být použití křivek u každého bloku if-if, i když obsahuje pouze jeden řádek:

if (something) {
    // whatever
}

Možná si nemyslíte, že je to nutné, ale nedávno číst , že je to hlavní zdroj chyb. Vždy se používaly závorky také byly diskutovány na Stack Overflow a kontrola, zda-příkazy mají závorky, je také pravidlo v PMD , analyzátor statického kódu pro Javu.

Pamatujte: „Protože je to nejlepší praxe“, není nikdy přijatelná odpověď na otázku „proč to děláte?“ Pokud nemůžete artikulovat, proč je něco nejlepší praxe, pak to není nejlepší praxe, je to pověra.

7
Vetle
  • Několik ternárních operátorů se spojilo dohromady, takže místo podobnosti bloku if...else Se stane blokem if...else if...[...]...else
  • Dlouhé názvy proměnných bez podtržítek nebo velbloudů. Příklad z nějakého kódu, který jsem vytáhl: $lesseeloginaccountservice
  • Stovky řádků kódu v souboru, s malým až žádným komentářem, a kód je velmi zřejmý
  • Příliš komplikované příkazy if. Příklad z kódu: if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL)) který jsem sklouzl dolů na if ($lessee_obj == null)
7
Tarka

Chytání obecných výjimek:

try {

 ...

} catch {
}

nebo

try {

 ...

} catch (Exception ex) {
}

Nadužívání region

Použití příliš mnoha regionů mi obvykle naznačuje, že jsou vaše třídy příliš velké. Je to varovný příznak, který signalizuje, že bych měl více prozkoumat ten kousek kódu.

6
Erik van Brakel

Může někdo vymyslet příklad, kde by se kód měl legitimně odkazovat na soubor absolutní cestou?

6
Rei Miyasaka

Komentáře, které říkají: „je tomu tak proto, že návrh subsystému froz je zcela skrytý.“

To pokračuje přes celý odstavec.

Vysvětlují, že se musí stát následující refaktor.

Ale neudělal to.

Nyní jim mohlo být řečeno, že to jejich tehdejší šéf nemohl změnit kvůli problémům s časem nebo kompetencí, ale možná to bylo kvůli tomu, že lidé jsou malicherní.

Pokud si nadřízený myslí, že j.random. programátor nemůže provést refaktoring, pak by to měl udělat supervizor.

Každopádně se to stane, vím, že kód byl napsán rozděleným týmem, s možnou mocenskou politikou, a nepodpořili návrhy podřízených subsystémů.

Pravdivý příběh. Mohlo by se to stát vám.

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

Samozřejmě bez jakéhokoli druhu dokumentace a příležitostného vnoření #defines

5
Sven

Kód C++ s explicitními příkazy pro odstranění (pokud se nedívám na vnitřní implementaci inteligentního ukazatele). 'delete' je 'goto' správy paměti IMHO .

S tím úzce souvisí kód jako:

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

(A počítejte štěstí, pokud existuje komentář!). Není to jako by inteligentní ukazatele byly raketovou vědou. std::auto_ptr je vytvořen pro tento druh věcí (dokumentování a prosazování záměru vyjádřeného v komentáři) a byl součástí standard = nyní už věky.

Společně tyto křičí nemilovaný dědický kód, nebo udržovatelé s myšlenkou uvízli někde na začátku 90. let.

5
timday

Funkce, které doplňují základní funkčnost jazyka. Pokud například v JavaScriptu uvidíte metodu „getStringLength ()“ místo volání vlastnosti „.length“ řetězce, víte, že máte potíže.

5
Ant

Konvence pojmenování tříd, které ukazují špatné pochopení abstrakce, kterou se pokoušejí vytvořit. Nebo to vůbec nedefinuje abstrakci.

Extrémní příklad přichází na mysl ve třídě VB), kterou jsem viděl, jakmile bylo pojmenováno Data a bylo 30 000+ řádků dlouhé ... v první Jedná se o částečnou třídu rozdělenou do nejméně půl tuctu dalších souborů. Většina metod byla obálky kolem uložených proc se jmény jako FindXByYWithZ().

I s méně dramatickými příklady jsem si jistý, že jsme všichni „vyhodili“ logiku do špatně koncipované třídy, dostali jsme jí zcela obecný název a později jsme toho litovali.

5
Bryan M.
ON ERROR RESUME NEXT

Nutnost udržovat Classic ASP aplikace je bohužel nutností pro většinu vývojářů ASP.NET, ale otevření společného souboru zahrnutí a vidět, že na prvním řádku je ničení duše.

4
richeym

Pokud neexistují žádné komentáře ani dokumentace k tomu, co kód dělá nebo má dělat (tj. „Kód je dokumentace“).

Metody nebo proměnné s číslem jako přípona (např. Login2 ()).

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

Kód, který nikdy nemůže, logicky zadejte cestu spuštění.

var product = repository.FindProduct(id);

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

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

nebo

if (messages.Count > 0)
{
    // Do stuff with messages
}
else if (messages.Count == 1)
{
    // **I hope this code isn't important...**
}
3
rmac
  • Vložení každé místní proměnné do prvních řádků feew v metodickém bloku. Obzvláště ve spojení s dlouhými metodami.
  • Použití booleovských proměnných k přerušení smyček/přeskočení iterací namísto pouhého použití přerušení/pokračování
3
Oliver Weiler

Z mého pohledu na Java:

  • Nestandardní styl kódování.
  • Non-soukromé proměnné.
  • Chybí pole final.
  • Zbytečné nebo nadužívání dědictví.
  • Obrovské třídy nebo bloky kódu.
  • Příliš mnoho komentářů (je to pravděpodobně jen zbožné přání).
  • Nestrukturované protokolování.
  • Getters a setters (rozhraní by měla být o chování).
  • Duplikovaná data.
  • Podivné závislosti.
  • Statiky, včetně globálních vláken.
  • U vícevláknového kódu části stejné třídy, u nichž se očekává spuštění v různých vláknech (zejména kód GUI).
  • Mrtvý kód.
  • Manipulace s řetězci smíchaná s jiným kódem.
  • Obecně směšovací vrstvy (látky vyšší úrovně, kombinované s iterací přes řadu primitivů nebo manipulace s vlákny).
  • Jakékoli použití odrazu.
  • catch bloky bez užitečného kódu (špatné: komentáře, printf, protokolování nebo jen prázdné).
3

Použití skrytého objektu v uživatelském rozhraní (např. Textové pole) k uložení hodnoty, spíše než k definování správně definované a -typické proměnné.

2
MartW

Kdykoli jsem četl následující:

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

Nebo něco podobného. Pokud tomu tak je, pak vložte prosbu! Dejte debuggerovi vědět, že během běhu tyto hodnoty nechcete a ujistěte se, že kód vyhláskuje smlouvu s volajícím.

2
wheaties

Tento typ kódu:

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

Toto je ze skutečné živé produkční kódové základny!

2
George Silva

Pokud jde o magická čísla: jsou špatná, pokud jsou používána na různých místech a jejich změna vyžaduje synchronizaci na několika místech. Jedno číslo na jednom místě však není o nic horší, než mít jednu konstantu pro označení jednoho čísla, které se stále používá na jednom místě.

Konstanty navíc nemusí mít ve vaší aplikaci mnoho místa. V mnoha databázových aplikacích by se tyto věci měly ukládat do databáze podle aplikace nebo podle uživatelských nastavení. A k dokončení jejich implementace zahrnují toto nastavení a místo v UI a poznámku v dokumentaci koncového uživatele ... to vše je druh - nadměrné inženýrství a plýtvání zdroji, pokud jsou všichni naprosto šťastní, když je číslo 5 ( a 5 je.)

Myslím, že můžete nechat čísla a řetězce na místě, dokud není nutné toto číslo použít mimo toto místo. Pak je na čase přizpůsobit věci flexibilnějšímu designu.

Pokud jde o řetězce ... Znám argumenty, ale tohle je další místo, které nemá smysl provádět konverzi z jednoho řetězce na jeden. Obzvláště pokud zavedené řetězce pocházejí z konstantní implementace (například dovozy generované z vnější aplikace a mají stavový řetězec, který je krátký a rozpoznatelný, stejně jako „po splatnosti“). což má velký význam při převodu „zpoždění“ na STATUS_OVERDUE, pokud je použito pouze na jednom místě.

Jsem velmi za to, že nepřidávám složitost, pokud ve skutečnosti nepřináší potřebné výhody z flexibility, opakovaného použití nebo kontroly chyb. Pokud potřebujete flexibilitu, zakódujte ji správně (věc refaktora). Ale pokud to není potřeba ...

2
Inca

Těsně spojený kód. Obzvláště když uvidíte uprostřed kódu spoustu věcí napevno (názvy síťových tiskáren, ip adresy atd.). Měly by být v konfiguračním souboru nebo dokonce v konstantách, ale následující problémy nakonec nakonec způsobí:

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

Jednoho dne Bob skončí a jeho tiskárna bude přejmenována. Někdy dostane tiskárna novou IP adresu. Někdy bude 192.168.1.5 chtít tisknout na Bobovu tiskárnu.

moje oblíbená mantra: vždy pište kód jako vražedný psychopat, který ví, kde žijete, bude ho muset udržovat!

2
davidhaskins

Kód, který ukazuje, že se programátor před lety nikdy nepřizpůsobil Java 5:

  • Použití Iterátorů místo „pro každého“
  • Nepoužívání generik ve sbírkách a přetypování načtených objektů na očekávaný typ
  • Používání starověkých tříd jako Vector a Hashtable

Neznala moderní vícevláknové způsoby.

2
Dave Briccetti

Pro SQL:

Prvním velkým ukazatelem je použití předpokládaných spojení.

Další je použití levého spojení na tableB v kombinaci s klauzulí WHERE jako:

WHERE TableB.myField = 'test'

Pokud nevíte, že to povede k nesprávným výsledkům, nemůžu uvěřit, že jakýkoli dotaz, který píšete, poskytne správné výsledky.

2
HLGEM

Náš starý kód VB6, můžete otevřít jakýkoli modul nebo kódovou stránku formuláře a najít obrazovku plnou veřejných nebo globálních # & @ ! Proměnných deklarovaných nahoře, na které se odkazuje z celého @ &!! (*! # program. ARGH !!!!

(Whew, musel jsem to dostat ven :-))

2
HardCode

Něco takového

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

To voní jako biologické nebezpečí. Tento odkaz na mnoho členů není nikdy dobrým znamením. A ano, jedná se o typický výraz v kódu, se kterým pracuji.

2
Gaurav

něco s něčím takovým

// TODO: anything could be here!

pravit: Měl bych se kvalifikovat, že jsem to myslel v produkčním kódu. Ale i v kódu odhodlaném ovládat zdroje to stále není dobré. Ale to by mohla být osobní věc v tom, že rád zakončím volno, když jsem svázal všechny volné konce :)

Edit 2: Měl bych se dále kvalifikovat, že jsem myslel, když to vidím v zavedeném kódu. Jako něco, co je staré několik let a opravuji to chybu. Vidím TODO a to je, když začnou zvonit budíky. TODO (pro mě) znamená, že kód nebyl z nějakého důvodu nikdy dokončen.

2
Antony Scott

Použití klíčového slova synchronized v Javě.

Ne že by se něco špatně stalo s použitím synchronized, pokud je použit správně. Ale v kódu, se kterým pracuji, se zdá, že pokaždé, když se někdo pokusí napsat podprocesový kód, dostane to špatně. Takže vím, že když uvidím toto klíčové slovo, musím být zvlášť opatrný ohledně zbytku kódu ...

1
Guillaume

Peephole optimalizace kódu, který by mohl být optimalizován s lepší strukturou, např. lineární vyhledávání implementovaná v inline Assembly, když by bylo vhodné (a rychlejší) binární vyhledávání v obyčejných C/C++/Java/C #.

Buď dané osobě chybí některé základní pojmy, nebo nemá smysl pro priority. Ten je mnohem znepokojivější.

1
Rei Miyasaka

@ FinnNk, souhlasím s vámi ohledně komentovaného kódu. Co mi opravdu chybí, jsou věci jako toto:

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

nebo cokoli, co tam bylo k testování nebo ladění, a bylo to komentováno a následně potvrzeno. Pokud je to jen příležitostné, nejedná se o velký problém, ale pokud je to všude, zaplní kód a ztěžuje pochopení, co se děje.

1
Elias Zamaria
  • $ data - Je to jako reklama "Fyzické objekty, nyní na směšně nízkých 100 za 5!"
  • Položky TODO v kódu - Používejte sledovač chyb/lístků/vydání, aby lidé věděli, co je potřeba na úrovni produktu, nikoli na úrovni souborů.
  • Pracovní přihlašovací kód - to je to, pro co je řízení verzí.
1
l0b0

Cokoli, co porušuje zásady, které jsou důležité. Například bylo navrženo několik anti-modelů (magické číslo - viz http://en.wikipedia.org/wiki/Anti-pattern ). Anti-vzory se nazývají proto, že způsobují problémy (také již zmiňované - křehkost, noční můry v údržbě atd.). Také pozor na porušení SOLID principů - viz http://en.wikipedia.org/wiki/Solid_ (objektově orientovaný design) Také, kód, který nevypadá Nezvažujte oddělení úrovní (věci přístupu k datům uvnitř uživatelského rozhraní atd.) Mít standardy kódování a recenze kódů v boji proti tomu bojují.

1
Tim Claason

Většina z nich pochází z Java zážitek:

  • Psaní řetězců. Prostě ne.
  • Typcasting často ukazuje na vůni kódu v moderní Javě.
  • Anti-vzor Pokemon Exception (když je musíte chytit všechny).
  • Cargo-kult pokusy o funkční programování tam, kde to není vhodné.
  • Nepoužívat funkční konstrukci (Callable, Function atd.) Tam, kde by to bylo vhodné.
  • Neschopnost využít polymorfismus.
1
Ben Hardy

Když kód vypadá jako nepořádek: Komentáře s „todo“ a „note to self“ a chromé vtipy. Kód, který byl zjevně používán v určitém okamžiku pouze pro účely ladění, ale poté nebyl odstraněn. Proměnné nebo funkce se jmény, které naznačují, že autor nezvažoval, že by si jej někdo později přečetl. Tato jména jsou často velmi dlouhá a nemotorná.

Také: Pokud kód chybí rytmus. Funkce divoce odlišné délky. Funkce, které nedodržují stejná schémata pojmenování.

Mírně příbuzný: Vždycky mě to zneklidňuje, pokud má programátor špatný rukopis. Nebo pokud jsou špatní spisovatelé nebo špatní komunikátoři.

1
KaptajnKold

Jednou jsem pracoval na projektu, kde dodavatel měl tyepdef'ed každý standardní datový typ od int po řetězec, včetně ukazatelů na skrytá jména. Jeho přístup znesnadnil pochopení kódu. Další styl, který mě varuje, je předčasná flexibilita; produkt, na kterém jsem kdysi pracoval, měl úplný kód v DLL, který byl načten v žádném předvídatelném pořadí. To vše pro budoucí vývoj. Několik knihoven DLL používalo pro přenositelnost obálky vláken. Bylo to noční můrou ladit program nebo předpovídat tok čtením zdrojového kódu. Definice byly rozptýleny mezi soubory záhlaví. Nebylo divu, že kód nepřežil nad druhou verzí.

1
VKs

Někdy vidím části metody, která vzhledem ke všem možným vstupům, stále by NIKDY běžela, takže by to nemělo být na prvním místě matoucí lidi. Příkladem by bylo ...
Pokud lze tuto metodu zavolat pouze v kontextu superuživatele Admin a vidím něco, jak kontroluje, zda uživatel požadavku není superuživatelem admin ...: /

1
chiurox

Nespokojené komentáře prokazující nedostatek zdrženlivosti:

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

Buď jsou zběsilí, nebo nejsou dostatečně zkušení, aby se dozvěděli, že neúspěchy jsou v programování nevyhnutelné.

Nechci s takovými lidmi pracovat.

1
Rei Miyasaka

Toto je poněkud menší příznak ve srovnání s věcmi, které ostatní uvedli, ale jsem programátor Python programátor a často to vidím v naší kódové základně:

try:
    do_something()
except:
    pass

Což mi obvykle signalizuje, že programátor ve skutečnosti nevěděl (nebo se nestaral), proč do_something může selhat (nebo co to dělá) - prostě si jen "hrával", dokud kód už nepadl.


Pro ty, kteří pocházejí z více prostředí Java, je tento blok Python ekvivalent

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

Jde o to, že Python používá výjimky pro „ne výjimečný“ kód, jako jsou přerušení klávesnice nebo vypuštění smyčky for for.

1
mipadi

geters všude mě děsí.

a zvláštní věc: geters delegování na jiné geters.

to je špatné, protože to znamená, že to, kdo napsal, nerozumí základům objektově orientovaného, ​​což je zapouzdření, což znamená, kde jsou data, by měly být metody, které na tato data působí.

delegování je pro jednu metodu ne všichni getters. princip je „řekni, neptej se“; řekni jednu věc k předmětu, nepožádej ji o tisíc věcí a pak to udělej sám.

getters mě vyděsí, protože to znamená, že další zásady oop budou porušeny tvrdé jádro.

0
Belun

Chybí informace o typu.

Podívejte se na tyto podpisy metod:

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

  2. public GetInvoices(c, d1, d2)

V (1) je přehlednost. Přesně víte, s jakými parametry musíte volat funkci, a je jasné, s jakou funkcí se vrací.

V (2) existuje pouze nejistota. Nemáte ponětí, jaké parametry použít, a nevíte, co se funkce vrací, pokud něco vůbec. Jste efektivně nuceni používat neefektivní přístup k programování pomocí pokusů a omylů.

0
ThomasX