Najgorszy standard kodowania, jaki musiałeś stosować? [Zamknięte]

77

Czy kiedykolwiek musiałeś pracować nad kodowaniem standardów, które:

  • Znacznie obniżyłeś swoją wydajność?
  • Czy pierwotnie zostały uwzględnione z dobrych powodów, ale zostały utrzymane długo po tym, jak pierwotna obawa stała się nieistotna?
  • Czy lista była tak długa, że ​​nie można było ich wszystkich zapamiętać?
  • Czy myślisz, że autor chciał po prostu zostawić swój ślad, a nie zachęcał do dobrej praktyki kodowania?
  • Nie miałeś pojęcia, dlaczego zostały uwzględnione?

Jeśli tak, jaka jest twoja najmniej ulubiona zasada i dlaczego?


Kilka przykładów tutaj

finnw
źródło
4
Nawiasem mówiąc, zadałem podobne pytanie (ale nie dokładnie to samo) na SO: stackoverflow.com/questions/218123/…
Brian R. Bondy
@Brian, dzięki, widziałem twoje pytanie, ale zapomniałem o tym.
finnw
4
Prawdziwym problemem związanym ze standardami kodowania jest marnowanie czasu i wysiłku na spieranie się, czy są one poprawne, czy nie. Nic nie przebije dobrej wojny z kręconymi klamrami, aby stworzyć walkę w internecine ...
MZB

Odpowiedzi:

97

Może to wzburzyć kilka piór, ale standardy, które nakazują umieszczanie szablonów w komentarzach na górze każdej metody, zawsze mnie denerwują.

1) Zawsze są nieaktualne, ponieważ są zbyt dalekie od kodu, który wykonuje rzeczywistą pracę, aby zauważyć, gdy aktualizujesz rzeczy. Złe komentarze są gorsze niż brak komentarzy.

2) Często powtarzają tylko informacje, które są już zawarte w narzędziu kontroli źródła, po prostu mniej dokładne. Na przykład: Ostatnia modyfikacja przez, lista dat / powodów modyfikacji.

JohnFx
źródło
12
Uważam (przynajmniej teraz, wcześniej w szkole, co wydawało się dziwne), że komentowanie jest złą praktyką
Shady M. Najib,
14
Nie tylko to, ale odkryłem, że narzut związany z tworzeniem nowego pliku klasy, kiedy trzeba umieścić ładunek płyty grzewczej na górze, faktycznie zniechęca deweloperów do tworzenia nowych klas i zachęca do ogromnych nieporęcznych klas, a tym samym złego projektu.
Gaz,
13
Nie zgadzać się! Nie dodajemy bezużytecznych informacji o przeróbce rudy, ale faktyczne wyjaśnienie tekstowe tego, co robi funkcja (w pliku .h) i jest bardzo przydatne! Oczywiście jesteśmy zobowiązani do utrzymywania go w synchronizacji z kodem.
Wizard
5
@Shady M Najib źle czy zawsze źle, gdy wolno im przejść niekontrolowany / nieobsługiwany? Ogólnie rzecz biorąc, dobry kod sprawi, że jego cel będzie wystarczająco oczywisty, aby uniknąć potrzeby komentowania - ale nie zawsze tak jest i uważam, że w tych scenariuszach komentowanie jest kluczowe. Nie mogę wymyślić jednego złego powodu, aby dołączyć komentarze XMLDoc.
Nathan Taylor
7
Blok wyjaśniający, co robi, jest dobry. Blok po prostu powtarzający typy i nazwy argumentów oraz zwracaną wartość jest zły. Kiedy musiałem pracować ze standardem nakazującym to drugie, napisałem skrypt emacs, aby automatycznie wygenerować większość z nich.
AShelly,
130

Kiedyś profesor, który zażądał, mamy co najmniej jeden komentarz do każdego wiersza kodu.

//Set x to 3
var x = 3;

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

    //Print x
    Print(x);
}

To było dość śmieszne.

Fishtoaster
źródło
10
Czy to nie tylko dlatego, że profesor wie, że dokładnie wiesz, co się dzieje?
John MacIntyre
80
Myślę, że to jasne, co się dzieje, i to nie jest edukacja.
Dan Ray
18
Powyższy przykład jest jasny, ale co się stanie, jeśli uczeń skopiuje jakieś wywołanie funkcji z innej aplikacji lub książki, czy cokolwiek, i naprawdę tego nie rozumie? Skąd prof się dowie? Ta głupia zasada nie zezwala na szarą strefę (która w jego obronie prawdopodobnie była wcześniej wykorzystywana). Tak to interpretuję. ... uważam, że jeśli zobaczyłem to w środowisku nieakademickim, może mnie to trochę przestraszyć. ;-)
John MacIntyre
4
Tak, ale zawsze możesz pisać komentarze, które po prostu powtarzają kod i nie okazują żadnego zrozumienia. Czy on sprawia, że ​​masz rację „// Ending Brace” przed ortezą końcową?
alternatywny
6
Co jeśli przypadkowo masz przydatny komentarz w kodzie? Czy musisz // commentwcześniej zadzwonić?
konfigurator
103

Nasza firma (C #) standard kodowania wezwał do szerokiego użycia #REGIONÓW (dla tych, którzy nie wiedzą, oznacza bloki kodu źródłowego, które zostaną zwinięte do jednej linii w Visual Studio). W rezultacie zawsze otwierałeś coś, co wyglądało na ładnie ustrukturyzowaną klasę, tylko po to, aby znaleźć stosy i stosy śmieci zmiecione pod głęboko zagnieżdżonymi dywanikami konstrukcji #REGION. Miałbyś nawet regiony wokół pojedynczych linii, np. Musiałbyś rozłożyć region LOG, aby znaleźć jedną deklarację Logger. Oczywiście wiele metod dodanych po utworzeniu jakiegoś regionu zostało również umieszczonych w „złym” zakresie regionu. Horror. Horror.

Regiony są jedną z najgorszych funkcji, jakie kiedykolwiek dodano do Visual Studio; zachęca raczej do strukturyzacji powierzchni niż do faktycznej struktury OO.

Obecnie zabijam #REGIONY na widoku.

rev Cumbayah
źródło
11
Próbowałem głosować kilkanaście razy ...
TGnat
22
Jeśli uważasz, że potrzebujesz #REGION, myślę, że potrzebujesz refaktoryzacji.
Jay Bazuzi,
23
Zasadniczo organizuję kod według regionów w konstruktory, właściwości, zdarzenia, metody i elementy. Sprawia, że ​​zarządzanie i nawigacja po źródle jest bardzo prosta (szczególnie w niektórych statycznych klasach narzędzi, które mogą być dość duże). Jednak nie użyłbym ich więcej.
Evan Plaice,
26
Mamy prosty standard kodowania: nigdy nie zagnieżdżaj regionów. Po prostu użyj ich do grupowania powiązanych metod (inicjalizacja, serializacja, właściwości itp.)
Jason Williams
6
Jedynym dobrym celem #regions jest ukrycie kodu, którego nie trzeba edytować . Może to być kod wygenerowany lub kod z trudnym do uzyskania właściwym algorytmem, którego wolelibyśmy nie dotykać, a może brzydkie bloki kodu debugującego. Ale nie kod, nad którym ludzie będą pracować. Dla tych, którzy utknęli w sklepie #region, mam makro, które zwija się do definicji, ale rozszerza regiony. Zobacz tutaj: stackoverflow.com/questions/523220/awesome-visual-studio-macros/…
Kyralessa
80

W jednym zadaniu byliśmy zmuszeni użyć dziwnej formy węgierskiej notacji w bazie danych.

Nie pamiętam szczegółów, ale z pamięci każda nazwa pola musiała zawierać:

  • Brak samogłosek
  • Wszystkie wielkie litery
  • Odniesienie do tabeli
  • Wskaźnik typu danych
  • Długość danych
  • Wskaźnik zerowy

Na przykład kolumna zawierająca imię osoby może być nazywana: PRSNFRSTNMVC30X(Tabela osób, kolumna Imię, 30 znaków Varchar, nie Null)

Damovisa
źródło
14
Przepraszamy, ale co się dzieje, gdy refaktoryzujesz bazę danych lub zdecydujesz, że długość VARCHAR musi być inna. Nagle musisz przejrzeć cały kod i zmienić ... o Boże. To wygląda okropnie.
Tom Morris,
71
Brak samogłosek ?? Żartujesz, prawda?
Daniel Cassidy
39
Czy ludzie, którzy przestrzegali tego standardu, mieli czoło na czole i często dyskutowali o honorze i walce?
Ryan Roberts,
10
Haha, cóż, byli DBA, więc ...;)
Damovisa
14
Powinieneś przesłać nazwy kolumn za pomocą skracacza adresów URL. PersonFirstNameVarchar30NotNull = bit.ly/cULlQc
Billy Coover
48

Nalegając, aby za wszystkimi nawiasami klamrowymi dodano komentarz dotyczący tego, co kończy się nawias klamrowy:

na przykład:

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
Kris Erickson
źródło
21
Bardziej seniable: jeśli potrzebujesz komentarza, aby powiedzieć, jaki był początek bloku, to blok jest zbyt długi lub jego treść jest zbyt złożona => refaktor.
Richard
5
Chcę głosować w dół, ponieważ długie, głęboko zagnieżdżone bloki mogą być trudne do uporządkowania, a te komentarze mogą pomóc. Chcę zagłosować, ponieważ te komentarze wkrótce staną się niepoprawne (i bardzo mylące), a ponieważ długie, głęboko zagnieżdżone bloki są znakiem, który należy zmienić, a nie dodawać więcej komentarzy.
Jay Bazuzi,
7
to był świetny pomysł na świat bez potężnego IDE.
IAdapter
9
@Jay w dowolnym przyzwoitym środowisku IDE możesz podświetlić jeden nawias klamrowy, a podświetli drugi odpowiadający nawias klamrowy. Osobiście nie cierpię, kiedy ludzie to robią.
Evan Plaice,
3
Chociaż twój przykład jest trochę szalony (ponieważ nie są wystarczająco długie, aby miało to znaczenie i spowolniłoby cię podczas zmiany logiki), nie zawsze jest to zła rzecz. Takie komentarze są bardzo przydatne do zamykania deklaracji przestrzeni nazw / endifów obejmujących cały plik.
jsternberg
38
#define AND  &&
#define OR   ||
#define EQ   ==

powiedział nuff.

Niall C.
źródło
9
Czy #include <iso646.h> nie byłby znacznie lepszym wyborem?
AndrejaKo,
3
@AndrejaKo: to wcześniej <iso646.h>; była to próba nadania C wyglądu FORTRAN.
Niall C.
2
Czy to naprawdę był standard kodowania? tj. czy istniała polityka firmy przeciwko bezpośredniemu pisaniu operatorów?
finnw
21
Czy to też miało #define BEGIN {i #DEFINE END }?
JBRWilkinson
3
Przypomina mi to artykuł Daily WTF, który widziałem, w którym jakiś programista C ++ ma mnóstwo definicji, aby wyglądać jak Visual Basic (a może po prostu Basic, jakiś dialekt). #define void Sub, #define} End, takie rzeczy.
Wayne Molina
37
  • Nazwy zmiennych lokalnych są pisane małymi literami bez podkreślników

Prawdziwe przykłady: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

New York Times waży :

„Przestrzenie na słowa nie powinny być brane za pewnik. Starożytny grecki, pierwszy alfabet z samogłoskami, można odczytać bez spacji słów, jeśli się je wypowie, i obejdzie się bez nich. […] Także łacina przestała rozdzielać słowa do drugiego wieku. Utrata jest zagadkowa, ponieważ oko musi znacznie ciężej pracować, aby odczytać niepodzielony tekst. Ale, jak wyjaśnił paleograf Paul Saenger, starożytny świat nie chciał „ułatwiać i przyspieszyć czytania” ”.
John Siracusa
źródło
3
+1. Drobne niedogodności się sumują. Trudno się też kłócić, ponieważ redaktor standardów kodowania lub premier może powiedzieć: „To nie jest wielkie obciążenie, więc nie warto go zmieniać”.
finnw
1
Dokładnie. (Chociaż w tym przypadku czytanie wielu różnych nazw takich jak to naprawdę adduptoquitea greatburden.)
John Siracusa
57
Baw się, wymyślając nazwy, a następnie analizuj je na dwa sposoby. odsłon, penisup itp.
Jay Bazuzi,
4
@Jay * sexchange
konfigurator
2
@configurator: Gdy zespół debugujący Visual Studio pracował nad funkcją pozwalającą zobaczyć wyjątek aktualnie w locie w oknie podglądu, zamierzali dodać pseudo-zmienną o nazwie „$ ex”. Długo nie zauważyliśmy. Następnie zmieniliśmy nazwę na „$ wyjątek”, ale nadal czytam to jako „s”.
Jay Bazuzi
36

I został poproszony przez lidera oprogramowania firmy do zrobienia „ prosty, re n kod dundant ”. Zabronione było na przykład dodawanie nowego parametru do istniejącej funkcji. Zamiast tego trzeba było powielić funkcję, pozostawiając oryginał nietknięty, aby uniknąć regresji. Oczywiście bez formalnego testowania (strata czasu).

Zabroniono nam również używania oprogramowania do scalania; każdy plik może być modyfikowany tylko przez jednego programistę na raz. Oprogramowanie do kontroli wersji było oczywiście science fiction.

Najszczęśliwszym dniem w moim życiu było zwolnienie go (uważaj, że bardzo, bardzo trudno jest zwolnić kogoś we Włoszech).

Lorenzo
źródło
może nigdy nie usłyszeć słowa „refaktoryzacja”
nanda
3
Nigdy nie słyszał też wielu innych słów ...
Wizard79
Cóż, nie potrzebowałeś formalnych testów, ponieważ nigdy nie zmieniłeś metod ...
konfigurator
36

Wszelkie interakcje z bazą danych muszą odbywać się za pomocą procedur przechowywanych . To może mieć sens, jeśli żyjemy w 1997, a nie w 2010 roku.

Właśnie zdałem sobie sprawę, że to faktycznie obejmuje wszystkie kryteria pierwotnego pytania:

  • Znacznie obniżyłeś swoją wydajność? CZEK. Proszę - po prostu użyj ORM .
  • Czy pierwotnie zostały uwzględnione z dobrych powodów, ale zostały utrzymane długo po tym, jak pierwotna obawa stała się nieistotna? CZEK. Menedżer był programistą serwera bazy danych 1000 lat temu i wprowadził ten standard kodowania.
  • Czy lista była tak długa, że ​​nie można było ich wszystkich zapamiętać? CZEK. Obejmowało to „jak najwięcej logiki powinno być przechowywanych w bazie danych, jak to możliwe”.
  • Czy myślisz, że autor chciał po prostu zostawić swój ślad, a nie zachęcał do dobrej praktyki kodowania? CZEK. Powraca do menedżera, który jest byłym programistą serwerów baz danych.
  • Nie miałeś pojęcia, dlaczego zostały uwzględnione? CZEK.
Jaco Pretorius
źródło
2
Mamy kilka osób w tym obozie w moim miejscu pracy. To zabawne, gdy próbują zagrać na karcie wyników i pokazać, jak nieaktualna jest ich wiedza
Doctor Jones
3
czekaj ... z całą powagą, myślałem, że SP BYŁO lepsze, pod względem wydajności, niż proste wywołania SQL z, powiedzmy, C #?
Sk93
3
Wygląda na to, że wiesz dokładnie, dlaczego zostały uwzględnione. : P
Mason Wheeler,
4
Kiedy dorastałem, w końcu zrozumiałem, dlaczego wszystko powinno przejść przez DB :) Z całą powagą, to upraszcza tak wiele rzeczy, nie próbuj ponownie wymyślać koła.
Jé Queue,
3
Słyszałem piękne uzasadnienie „Nie możemy użyć OR / M, ponieważ wszystkie interakcje muszą używać SP”. Takie marnotrawstwo siły ludzkiej.
konfigurator
33

Niedozwolone korzystanie ze STL lub innych standardowych bibliotek C ++, ponieważ CTO wierzył, że „możemy” zrobić to lepiej i szybciej. Nawet podstawowe konstrukcje, takie jak listy i klasa string.

David B.
źródło
5
Jedyny raz, kiedy słyszałem, że ktoś nie używa STL, ponieważ nie był wystarczająco szybki i miał rację, był w grach. EA wykonało własną implementację STL dla swoich gier. Bardzo wątpię, czy to już ma znaczenie (współczesne gry mają ograniczoną moc GPU) i wątpię, czy z nich korzystają. Ale i tak była to implementacja STL, a nie całkiem nowa biblioteka. Nadal korzystałeś z STL podczas korzystania z EASTL.
Matt Olenik,
1
@Matt: aby dodać do tego, skarga EA była skoncentrowana na zużyciu pamięci i inicjalizacji. Ich własna implementacja zużywała mniej pamięci, zwolniła ją wcześniej i uniknęła inicjalizacji obiektów, które zostałyby zainicjowane później.
Matthieu M.,
Powiedziałbym mu, żeby sam to kodował.
prawej stronie
31

Notacja węgierska

Próbka wyodrębniona z „ Objaśnienia Charlesa Simonyi dotyczącego węgierskiej konwencji nazywania identyfikatora notacji ” na MSDN.

1 # obejmują „sy.h”
2 extern int * rgwDic;
3 extern int bsyMac;
4 struct SY * PsySz (char sz [])
6 {
7 char * pch;
8 int cch;
9 struct SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 bez znaku wHash = 0;
13 pch = sz;
14 while (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 dla (; * pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 char * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 while (* pch == * szSy ++)
24 {
25 if (* pch ++ == 0)
26 return (psy);
27}
28}
29 cwSz = 0;
30 if (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 Zero ((int *) psy, cwSY);
34 bltbyte (sz, psy-> sz, cch + 1);
35 return (psy);
36}
J8D
źródło
5
Aaaaaaaaaaaa!
Doktor Jones
22
Największym problemem z tą próbką są bezsensowne nazwy zmiennych. Usuń prefiksy węgierskie, a niektóre z nich mają 1 lub nawet 0 znaków.
finnw
8
Jest to węgierski system, który jest użyteczny w słabo napisanych językach (ponieważ koduje informacje o typie, które są niezbędne do pracy w tych językach w nazwach) - jest bezużyteczny w językach silnie typowanych. Lepszą alternatywą dla silnie typowanych języków są aplikacje węgierskie, które kodują ważne informacje o użyciu zmiennej (element członkowski, wskaźnik, zmienny, indeksator) - coś, czego sam język nie obsługuje.
Jason Williams
5
Oh proszę. Nigdy nigdy mylić z lokalnego członka, a nie korzystać z tego głupiego węgiersku dla członków / mieszkańców / boiska / cokolwiek. Myślę, że mogą się przydać do rozróżniania różnych rodzajów ciągów, takich jak „bezpieczny” i „niebezpieczny”, jak przykład Joela w „ Making Wrong Code Look Wrong”
konfigurator
3
@configurator: Przykład Joela jest okropny, lepiej byłoby mieć różne typy, wtedy kompilator wymusiłby użycie.
Matthieu M.,
28

Kiedyś pracowałem nad projektem, w którym kierownik projektu nakazał, aby każda zmienna - KAŻDA zmienna - była poprzedzona literą „v”. Zatem vCount, vFirstName, vIsWarranty itp.

Dlaczego? „Ponieważ pracujemy w VBScript i i tak wszystko jest wariantem”.

WTF.

Christopher Hawkins
źródło
93
Kiedyś pracowałem w języku, który wymagał, aby każda zmienna - KAŻDA zmienna - była poprzedzona „$”.
nohat
6
@ nohat: I zdałeś sobie sprawę, że to było niesamowite, prawda?
Josh K
Kiedyś pracowałem w języku, w którym wszystkie moje zmienne zaczynały się od interpunkcji, np. „$”, „%” Lub „@”. Nadal tak robię, od czasu do czasu.
David Thornley,
3
To naprawdę staje się problemem tylko wtedy, gdy wymagane jest wprowadzenie ffunkcji przed, wtedy kod jest naprawdę fUcked (vUp).
Joe D
1
Brzmi jak różne wersje Perla ...
26

Prawie zapomniałem tego:

Cytat od kierownika:

Nie naprawiaj ani nie dokumentuj błędów w swoim kodzie. Klient zapłaci nam za ich identyfikację i naprawę w ciągu najbliższych kilku lat.

To nie było dla oprogramowania konsumenckiego, ale niestandardowe dla jednej dużej organizacji. Nie trzeba dodawać, że klient płacił przez lata później. Może się to wydawać trywialne, ale próba zignorowania błędów jest trudniejsza niż ich znalezienie.

David B.
źródło
2
To okropna polityka. Mam nadzieję, że ten menedżer został zakonserwowany.
Bernard,
@ Bernard-W większości organizacji tworzących długoterminowy strumień przychodów stanowi podstawę do szybkiej promocji. Mam nadzieję, że ktoś inny zobaczył w tym szaleństwo i przypadkowo wpadł na parking.
Jim Rush
24

Wymuszone komentarze XML dotyczące wszystkich nieprywatnych metod, stałych, wyliczeń i właściwości.

Doprowadziło to do trochę zaśmieconego kodu, szczególnie, że wynikiem końcowym było albo naciśnięcie ///, aby utworzyć pusty kod komentarza do wszystkiego, albo zainstalowanie GhostDoc i dodanie automatycznie wygenerowanych komentarzy:

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

[Edytuj] Powodem, dla którego wspominam o tym jako niedorzecznym standardzie, nie jest to, że uważam, że komentarze do metod są głupie, ale dlatego, że jakość tych komentarzy nie była w żaden sposób egzekwowana i spowodowała po prostu mnóstwo bałaganu w plikach kodu . Istnieją lepsze sposoby tworzenia znaczących dokumentów kodowych niż „niewidoczne” wymaganie kompilacji.

Anna Lear
źródło
13
' Validations the handler' - uh-oh
Eric
8
+1 Ugh Nienawidzę tego. Myślę, że jeśli używasz oprogramowania do generowania komentarzy, nie potrzebujesz ich.
bleevo
9
Nie sądzę, że to zła zasada. Czytanie metody, którą muszę zachować po raz pierwszy, bardzo pomaga, jeśli mam specyfikację dla wszystkich argumentów. Zwykle są subtelności (np. Co się stanie, gdy argument jest pusty, co jeśli jest pustą kolekcją, nazwą nieistniejącego pliku itp.) Inną dobrą regułą (IMHO) jest, że nazwy metod powinny być czasownikami, ale w twoim przykładzie jest to rzeczownik.
finnw
3
@finnw Myślę, że to dobra praktyka, ale zły standard. Jeśli programiści są na pokładzie i piszą sensowne komentarze do metod, gdy są uzasadnione (szczegóły wyjątku itp.), To świetnie. Jeśli nie, skończysz z wielkim bałaganem. W pierwszym przypadku nie jest wymagane wymuszanie na poziomie kompilacji.
Adam Lear
7
Klasyczny przypadek nieudokumentowania. Komentarze, które nie mówią nic poza rażąco oczywistym, powinny zostać zabite na widoku.
Cumbayah,
23

Nie jest to tak naprawdę standard kodowania, ale mieliśmy plik pod kontrolą źródła o nazwie „changelog.txt”

Za każdym razem, gdy się zameldowałeś, musiałeś ręcznie dodać wpis do tego pliku. Ten wpis był numerem wersji subversion i Twoim komentarzem do zameldowania.

Kiedy rozpoczął się nowy CTO i ktoś mu to powiedział, natychmiast podjął decyzję wykonawczą i powiedział: „Nie będziemy już tego robić” i usunął plik. Działo się to od lat.

Jim A.
źródło
6
I nikt nie był tego świadomy svn log?
Htbaa
1
Ci, którzy rozpoczęli tę politykę, już dawno odeszli, a ci, którzy poszli za nią, kontynuowali ją. Zacząłem w tym samym tygodniu, co nowy CTO (mój przyjaciel) i oboje spojrzeliśmy na to i powiedzieli WTF?
Jim A
20

Niektóre miejsca, z którymi pracowałem, nalegały na komentowanie nieużywanego lub przestarzałego kodu zamiast go usuwać. Zamiast ufać VCS w zakresie historii itp., Został boleśnie utrzymany w plikach poprzez skomentowany kod.

Dużym problemem, jaki znalazłem przy tym, jest to, że często nie masz pojęcia, dlaczego kod został skomentowany. Czy to dlatego, że jakiś deweloper aktywnie wprowadzał zmiany i chciał zachować go w celach informacyjnych, czy też nie był już potrzebny?

Jeremy Wiebe
źródło
3
Ostatnio skasowałem wiele starych, skomentowanych kodów.
CoderDennis,
2
Zwykle usuwam skomentowany kod, chyba że towarzyszy mu dobre wyjaśnienie, dlaczego został skomentowany i dlaczego należy go zachować.
Jeremy Wiebe
W pełni się zgadzam. Komentowanie kodu tak długo, jak z nim pracujesz, jest w porządku, ale wszystko, co trafia do wersji wydania / głównej gałęzi, powinno być pozbawione komentowanego kodu. Ktoś powiedział mi, że „lubili wiedzieć, jak można to zrobić inaczej”. Uważam to za irytujące z wymienionych powodów: Czy jest to przestarzałe, obejście, inny sposób na zrobienie tego? WTF
Anne Schuessler,
W VS2013 „Peeks” wszystko jest za oknem. Ale dodajemy komentarz „Zmienione równanie - inicjały” lub coś takiego, więc ktoś zastanawiający się, jaki byłby stary kod, wyglądałby w TFS / VCS, gdyby tego potrzebował. Jest to więc jedna linia zamiast 10 linii z komentarzem. Ale VS2013 jest niesamowity, pokazuje historię TFS właśnie dla Ciebie.
Suamere
17

Najgorszym standardem kodowania, w jakim kiedykolwiek uczestniczyłem, są bazy kodu, które w ogóle ich nie miały. Wolałbym przestrzegać standardu kodowania, z którym się całkowicie nie zgadzam, niż pracować w bazach kodu, w których w ogóle ich nie ma. To sprawia, że ​​znacznie trudniej jest nauczyć się nowych części bazy kodu.

JaredPar
źródło
16

Wymuszanie wbudowanych komentarzy do kontroli wersji dotyczyło najbardziej bezcelowego standardu kodowania, który zignorowałem.

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

Oracle DBA, która nalegała na poprawne użycie białych znaków podczas „utrzymywania” bazy danych z wysoce rywalizującą tabelą, która miała ponad 200 pól i 40 wyzwalaczy, jest bliska.

Ryan Roberts
źródło
To dość obrzydliwe
Evan Plaice,
5
Mmmm Dim Sum ...
konfigurator
Zrobiłem to, zanim oczywiście mieliśmy kontrolę źródła. Gdy mieliśmy kontrolę źródła, był to taki nawyk, że praktycznie potrzebowaliśmy interwencji, aby zespół przestał to robić. W końcu zatrzymaliśmy i usunęliśmy wszystkie istniejące, gdy je znaleźliśmy.
Scott Whitlock
Nasz starszy programista wciąż próbuje nas do tego zmusić. Ignoruję polisę, ilekroć wydaje mi się, że mogę jej uniknąć (a czasem, gdy wiem, że nie mogę).
Joshua Smith
W naszym zespole jest facet, który wciąż robi to wszędzie (zawiera także ogromne elementy „dziennika zmian” w naszych skryptach SQL, które są również pod kontrolą wersji). Argument, jak mi wyjaśniono, jest taki, że po kilku zmianach / zatwierdzeniach nie pamiętasz daty, kiedy coś zostało zmienione, więc dziennik zmian dobrze jest od razu zauważyć, kto i co zmienił po otwarciu pliku.
Wayne Molina
14

Zrobiłem recenzje kodu w projekcie prowadzonym przez C ++ po raz pierwszy, który zdecydował, że wszystkie funkcje członków klasy powinny być poprzedzone nazwą klasy i widocznością:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}
użytkownik1006
źródło
1
Zapytałeś ich dlaczego ? Chciałbym tylko poznać ich motywację ...
JBRWilkinson
1
Wow, dlaczego ten facet w ogóle korzysta z zajęć ?
Mateen Ulhaq
9

Konieczne jest wcięcie całego kodu o cztery spacje;)

RedFilter
źródło
2
Jak było źle?
Jay Bazuzi,
1
Ponieważ wtedy każda linia ma 4 niepotrzebne spacje na początku?
nohat
Och, rozumiem teraz.
alternatywny
21
Tak, StackOverflow ma naprawdę zły standard kodowania. :-)
P Shved
Duże wcięcia zmuszają do utrzymania niskiego poziomu zagnieżdżania kodu. Widziałem wcięcia 8 i działało dobrze.
Toon Krijthe,
9

Wiele lat temu miałem pracę, w której cały nasz kod musiał być wyrównany do lewej - bez wcięć. Facet, który wymyślił tę zasadę, nie lubił przewijać się w przód iw tył poziomo podczas oglądania długich linii kodu, zrównując go z grą w ping-ponga oczami.

Jeremy
źródło
To okropny, okropny standard kodowania, którego należy przestrzegać. I to też głupi powód!
gablin
4
Jeśli musisz przewijać w poziomie (na przykład ponad pół strony), prawdopodobnie coś jest nie tak. Wcięcie nie jest dobre, ponieważ powoduje, że kod jest całkowicie nieczytelny. Staram się trzymać z limitem 78 kolumn, ale jeśli jest to wymagane, aby przekroczyć tę kwotę, nie mam nic przeciwko, ale staram się tego unikać.
Htbaa
8

To bardziej przykład tego, jak brak standardów kodowania może zaszkodzić.

Wykonawca pracujący w dużym banku nalegał, aby przestrzeganie standardów było jak najlepsze. Aplikacja została napisana w dBase / Clipper, dla którego był jedynym programistą i oczywiście wymyślił standard.

  • Wszystko jest pisane wielkimi literami. Mam na myśli wszystko, w tym jego rzadkie komentarze.
  • Bez wcięcia.
  • Zmienne nazewnictwo było czymś podobnym do APRGNAME. A = zakres zmiennej, np. P dla public, PRG = pierwsze trzy znaki pliku źródłowego, który utworzył zmienną, NAME = nazwa zmiennej w pozostałych 6 znakach dozwolonych przez dBase / Clipper.
  • Pierwsze 4 i ostatnie 4 wiersze kodu źródłowego miały 80 * długości. Dlaczego? Usłyszał więc, jak drukarka mozaikowa rozpoczyna i kończy drukowanie pliku. Pamięć jest to, że cały program był drukowany przez mainframe co tydzień, 20 000 stron.
  • Jestem pewien, że udało mi się wyrzucić z mózgu o wiele więcej.

Na tym etapie byłem bardzo nowym programistą-samoukiem, ale wiedziałem wystarczająco dużo, aby nie słuchać szalonego naukowca i wynosić się stąd, zanim poprosiłem o przejęcie projektu.

I tak, powiedzieliśmy kierownictwu, jak złe były te praktyki, ale zawsze miały zwyczajowe „płacenie temu kontrahentowi najwyższego dolara, za który musi wiedzieć, o czym mówi”.

Tim Murphy
źródło
7
Proszę nie wyśmiewać starszych dinozaurów. Umożliwiły nam.
P Shved
4
Brzmi jak bezpieczeństwo pracy.
MIA
7
Posiadanie znacznika audio, dzięki któremu wiesz, kiedy drukowany jest każdy plik, jest genialne. Teraz dodam \07na początku każdego pliku.
konfigurator
2
Zastosowanie takiego schematu nazewnictwa (nie wielkimi literami) miało pewien sens, ponieważ nie istniały zmienne „zakresu” zmiennych dBase'a. Wszystko było skutecznie globalne. iStosowane do indeksu tablicy w jednej procedurze może kolidować z iw procedurze wywoływania. Musisz użyć PRIVATE ALL LIKE m*i PRIVATE izapobiec temu „zacienianiu”
Gerry
8

Jeszcze jeden wybuch z mojej przeszłości.

Cytat właściciela firmy:

Nie będzie kodu napisanego w językach interpretacyjnych, ponieważ straciłem 25 milionów na tym {expletive} projekcie napisanym w Javie.

Projekt Java był systemem handlu akcjami zaprojektowanym do obsługi kilkudziesięciu akcji, który był teraz wykorzystywany do przetwarzania tysięcy. Zamiast zająć się wadami projektowymi lub słabym sprzętem, cała firma była zmuszona przekonwertować wszystkie aplikacje spoza C / C ++ na C / C ++, a wszystkie nowe prace rozwojowe musiały być w C / C ++. Języki interpretacyjne oznaczały wszystko, co nie zostało skompilowane, a właściciel rozważał jedynie skompilowanie Assemblera, C i C ++.

Dla 800-osobowej firmy, w której większość kodu była napisana w Javie i Perlu, oznaczało to, że cała firma spędzała większość czasu w ciągu następnych kilku lat, przepisując doskonale doskonały kod w C / C ++.

Zabawne, jakieś dwadzieścia lat przed tym fiaskiem, byłem w innej firmie, w której kierownictwo techniczne zdecydowało, że nasza logika sortowania (była to sortowanie bąbelkowe) powinna zostać przekodowana w asemblerze zamiast zastąpiona przez szybkie sortowanie, ponieważ - Algorytmy robią nie poprawiać wydajności. Jedynym sposobem na poprawę wydajności było przepisanie tej samej logiki w asemblerze.

W obu przypadkach wyszedłem wkrótce po upadku dyktanda.

David B.
źródło
Czy któraś firma nadal działa?
finnw
Ten, który „przeniósł” się z Javy, drugi już dawno minął. Nigdy nie przeżyli przejścia z TRS-80 na PC.
David B
6

Jak wielu programistów (ale niewystarczająco), nienawidzę dekoracji kodu. Denerwuje mnie, gdy muszę używać przedrostka znaku dolara ($) dla nazw zmiennych lub podkreśleń dla zmiennych prywatnych, nawet bez getterów / ustawiaczy. Jeśli musisz udekorować swój kod, aby go zrozumieć, musisz wyjść z tego!

Adam Harte
źródło
Cóż, jak mówi „Will”, „poprzedzam podkreśleniem, aby moje prywatne zmienne były zgrupowane w mojej inteligencji. Jednak robię to tylko dla zmiennych o określonym typie. Zmienne zadeklarowane w ramach metody lub węższego zakresu pozostawiam podkreślenie wyłącza. Ułatwia rozdzielenie ich i utrzymanie razem mniej używanych zmiennych ”. i muszę się z nim zgodzić.
7wp
1
Nie sądzę, aby grupowanie zmiennych w ulubionym, zastrzeżonym IDE było wystarczająco dobrym powodem, aby usunąć cały kod.
Adam Harte,
Jeśli jest to twój kod, uczynienie go użytecznym w twoim IDE wydaje się całkowicie rozsądne. Ponadto uzupełnianie podkreśleń jest powszechne w wielu językach, więc ilekroć ludzie to zobaczą, wiedzą, co to znaczy.
rjmunro
1
+1 Korzystanie dobre IDE (jeden, który może używać regex wyszukiwania ) ma większy sens dla mnie. Scratch IDE, naucz się korzystać z edytora tekstu i terminala, a będziesz znacznie lepszym programistą. Na marginesie, nie lubię sigili perlowych, ale przynajmniej mają zastosowanie, w przeciwieństwie do PHP.
alternatywny
6
Westchnienie ... Kolejny z tych ludzi „IDE są dla cipek”.
Nailer
6

Od jakiegoś czasu pracuję z systemem webowym, w którym wszystkie przekazane parametry musiały mieć nazwy P1, P2, P3 itd. Nie ma szans, do diabła, wiedzieć, po co są, bez obszernej dokumentacji.

Ponadto - choć nie jest to ściśle standard kodowania - w tym samym systemie każdy plik miał mieć nazwę xyz0001.ext, xyz0002.ext, xyz0003.ext itp. - gdzie xyz był kodem samej aplikacji.

CB Du Rietz
źródło
6

To było dawno temu - dokładnie 1976. Mój szef nigdy nie słyszał o Edsgerze Dijkstrze ani nie czytał numeru CACM, ale skądś usłyszał plotki, że „GOTO jest złe”, więc nie wolno nam było używać GOTO w naszych programach COBOL. Stało się to zanim COBOL dodał „koniec jeśli”, więc w tym czasie miał tylko dwie i pół z trzech klasycznych struktur kontrolnych (sekwencja, jeśli / to / inaczej, wykona (tj. Zrobi czas)). Niechętnie zezwolił na GOTO w naszych programach podstawowych i instrukcje rozgałęzień w naszych programach językowych asemblera.

Przepraszam, że jest to rodzaj historii „musiałeś tam być”. O ile mi wiadomo, każdy język wymyślony od 1976 r. Ma odpowiednie struktury kontrolne, abyś nigdy nie musiał używać GOTO. Ale chodzi o to, że szef nigdy nie wiedział, DLACZEGO GOTO uważano za szkodliwe, lub który język był zaburzeniem dziecięcym, a która śmiertelna.

Mark Lutton
źródło
6

Pracowałem w projekcie, w którym główny architekt chciał napisać (a nawet zbyt) wyraźny kod. Jednym z najgorszych przykładów, które znalazłem w kodzie (a on z radością zatwierdził) był następujący.

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

Nawet ReSharper powiedział ci, że to źle!

Jax
źródło
9
Trudno byłoby ci zwrócić coś z funkcji uznanej za nieważną.
Mircea Chirea
7
@MAttB Zastanów się, na jakich warunkach elsezostanie podjęta ostatnia gałąź ( ).
Richard
6
else {return string.Empty; } zostanie wykonane, gdy powyższe 2 wiersze zostaną edytowane przez programistę ds. konserwacji za 5 lat. Jednak zwracany ciąg znaków. Pusty ukryje fakt, że jest to warunek niemożliwy . Zamiast tego powinien wyrzucić InvalidOperationException („Ten kod nie miał obsługiwać logiki trzech wartości”);
MatthewMartin,
1
To jest okropne. Co jest nie tak z return verbose ? someString : someOtherString;?
Callum Rogers,
1
@callum Operator trójskładnikowy może zostać zbanowany :) był tam wcześniej ...
hplbsh 11.01.11
6

W mojej ostatniej pracy „standardy” byłyby bardzo silnym określeniem tego, co dostałem od faceta, który mnie zatrudnił. Programując strony internetowe w ColdFusion i SQL, dostałem wymagania dotyczące kodowania, takie jak:

  • Nie używaj obejmuje. Lubię jedną dużą stronę
  • Zawsze oddzielaj słowa w nazwach zmiennych i kolumn znakiem podkreślenia (z wyjątkiem isactive, firstname itp.)
  • Nigdy nie używaj skrótów - zawsze wypisz imię (często pisał fname i tak dalej)
  • Nie używaj mylących nazw (takich jak kwota_ładowania i kwota_ładowania, które mierzyły różne, ale powiązane rzeczy)
  • Nie używaj DIV i używaj minimalnego CSS - zamiast tego użyj zagnieżdżonych tabel (raz znalazłem jakieś sześć warstw głębokości).
  • Nie buforuj żadnych zapytań. Zawsze.
  • Zamierzasz użyć zmiennej na więcej niż jednej stronie? Zakres zastosowania
  • Każda strona ma własny blok try / catch. Nie potrzebujemy / nie chcemy globalnej procedury obsługi błędów.

Zacząłem je zmieniać, jak tylko rzucił.

Ben Doom
źródło
„Nie używaj mylących nazw” wydaje mi się wystarczająco sprawiedliwe ...
8128
1
To absolutnie uczciwa wskazówka. Chodziło mi o to, że wcale tego nie przestrzegał. Wydaje mi się, że jego pomysł „nie mylić” i mój był inny.
Ben Doom,
4

W moim życiu jako programista C ++ przestrzegano dwóch naprawdę paskudnych „zasad”:

  1. „Nie możemy używać STL, ponieważ VC ++ 4.1 go nie obsługuje (i nie możemy obecnie przejść na VC ++ 6.0)”.
  2. „Czy nie używać QuickSort, ponieważ może być O (n ^ 2) w złych przypadkach; użyć tej implementacji algorytmu sortowanie przez kopcowanie I (nazwa lidera projektu usunięte) pisał jako student”.

źródło
6
Co było nie tak z HeapSort lidera projektu?
7wp
4
W rzeczywistości, jeśli kod zostanie zaakceptowany przez zewnętrzne dane wejściowe użytkownika, QuickSort może być niepoprawny, ponieważ otwiera się na O(n^2)ataki DOS (dostarczanie danych wejściowych w najgorszym przypadku). Również dlaczego nie było możliwe przełączenie - samo w sobie było usprawiedliwieniem nieużywania STL.
Maciej Piechotka,
4

Jestem zmuszony posiadać dokumentację XML dla wszystkich klas i członków klasy. W tym prywatny. Jestem zachęcony do używania domyślnych komentarzy ghostdoc.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}
Carl Bergquist
źródło
Bardzo podobny do tej wcześniejszej odpowiedzi .
finnw
Tak. Wszystkich jestem zobowiązany do komentowania również członków prywatnych. Co ma jeszcze mniej sensu.
Carl Bergquist,
Zachęcony do korzystania z ghostdoc ?! Gah
konfigurator