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

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

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.

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.

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.

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)

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

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

powiedział nuff.

• 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” ”.

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).

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.

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.

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}

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.

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.

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.

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.

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?

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.

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.

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);
}

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

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.

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”.

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.

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!

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.

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.

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!

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ł.

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”.

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