Jaka była najdziwniejsza reguła standardu kodowania, której musieliście przestrzegać? [Zamknięte]

Kiedy zadałem to pytanie , prawie zawsze otrzymywałem zdecydowane tak, że powinieneś mieć standardy kodowania.

Jaka była najdziwniejsza standardowa zasada kodowania, do której musieliście się stosować?

A mówiąc najdziwniejsze, mam na myśli najzabawniejsze, najgorsze lub po prostu dziwne.

W każdej odpowiedzi podaj, w jakim języku, jaki był rozmiar Twojego zespołu i jakie złe skutki spowodowało to dla Ciebie i Twojego zespołu.

Ja nienawidzę go, gdy korzystanie z wielu zwrotów jest zakazane.

odwrotne wcięcie. Na przykład:

    for(int i = 0; i < 10; i++)
        {
myFunc();
        }

i:

    if(something)
        {
// do A
        }
    else
        {
// do B
    }

Może nie najbardziej dziwaczny, jaki dostaniesz, ale naprawdę nienawidzę, gdy muszę poprzedzać nazwy tabel bazy danych przedrostkiem „tbl”

Prawie każdy rodzaj notacji węgierskiej.

Problem z notacją węgierską polega na tym, że jest ona bardzo często źle rozumiana. Pierwotny pomysł polegał na tym, aby przedrostek zmiennej był jasny. Na przykład:

int appCount = 0; // Number of apples.
int pearCount = 0; // Number of pears.

Ale większość ludzi używa go do określenia typu.

int iAppleCount = 0; // Number of apples.
int iPearCount = 0;  // Number of pears.

Jest to mylące, ponieważ chociaż obie liczby są liczbami całkowitymi, wszyscy wiedzą, nie można porównywać jabłek z gruszkami.

Żaden operator trójskładnikowy nie jest dozwolony tam, gdzie obecnie pracuję:

int value = (a < b) ? a : b;

... ponieważ nie każdy „to rozumie”. Jeśli powiesz mi: „Nie używaj tego, ponieważ musieliśmy je przepisać, gdy struktury stały się zbyt skomplikowane” (zagnieżdżone operatory trójskładnikowe, ktoś?), To zrozumiałbym. Ale kiedy powiesz mi, że niektórzy programiści ich nie rozumieją ... hm ... Jasne.

NIGDY nie usuwać żadnego kodu podczas dokonywania zmian. Powiedziano nam, aby komentować wszystkie zmiany. Pamiętaj, że używamy kontroli źródła. Ta polityka nie trwała długo, ponieważ programiści byli oburzeni z powodu tego i tego, jak sprawi, że kod będzie nieczytelny.

Kiedyś pracowałem pod tyranią Mighty VB King .

VB Król był czysty mistrz MS Excel i VBA, a także baz danych ( stąd jego nazwisko: Grał z Excel, podczas gdy programiści pracowali z kompilatorów i kwestionując go na bazach danych może mieć szkodliwy wpływ na swoją karierę ... ).

Oczywiście jego ogromne umiejętności dały mu unikalną wizję problemów programistycznych i rozwiązań w zakresie zarządzania projektami: chociaż nie były to dokładnie standardy kodowania w ścisłym tego słowa znaczeniu, VB King regularnie miał nowe pomysły na temat „standardów kodowania” i „najlepszych praktyk”, które wypróbował (i często udawało się) narzucić nam. Na przykład:

• Wszystkie tablice C / C ++ powinny rozpoczynać się od indeksu 1 zamiast 0. Rzeczywiście, użycie 0 jako pierwszego indeksu tablicy jest przestarzałe i zostało zastąpione przez wnikliwe zarządzanie indeksami tablic w języku Visual Basic 6.

• Wszystkie funkcje zwracają kod błędu: w VB6 nie ma wyjątków, więc po co w ogóle ich potrzebujemy? ( tj. w C ++ )

• Ponieważ „Wszystkie funkcje powinny zwracać kod błędu” nie jest praktyczne w przypadku funkcji zwracających znaczące typy, wszystkie funkcje powinny mieć kod błędu jako pierwszy parametr [we / wy].

• Cały nasz kod będzie sprawdzał kody błędów ( doprowadziło to do najgorszego przypadku VBScript, jeśli w mojej karierze wystąpiło wcięcie, jeśli kiedykolwiek widziałem ... Oczywiście, ponieważ klauzule „else” nigdy nie były obsługiwane, nie znaleziono żadnego błędu aż do za późno ).

• Ponieważ pracujemy z C ++ / COM, od dziś będziemy kodować wszystkie nasze funkcje narzędziowe DOM w języku Visual Basic.

• Błędy ASP 115 są złe. Z tego powodu użyjemy On Error Resume Next w naszym kodzie VBScript / ASP, aby ich uniknąć.

• XSL-T to język zorientowany obiektowo. Użyj dziedziczenia, aby rozwiązać swoje problemy ( głupia niespodzianka tego dnia prawie złamała mi szczękę ).

• Wyjątki nie są używane, dlatego należy je usunąć. Z tego powodu odznaczymy pole wyboru z prośbą o wywołanie destruktora w przypadku wycofania wyjątku ( ekspertowi zajęło kilka dni, aby znaleźć przyczynę tych wszystkich wycieków pamięci i prawie wpadł w szał, gdy dowiedział się, że dobrowolnie zignorowali (i ukryty) jego notatka techniczna o ponownym sprawdzeniu opcji, wysłana kilka tygodni wcześniej ).

• przechwytuje wszystkie wyjątki w interfejsie COM naszych modułów COM i usuwa je po cichu (w ten sposób, zamiast awarii, moduł wydawałby się tylko szybszy ... Błyszczący! ... Ponieważ używaliśmy opisanej powyżej obsługi błędów über, zajęło nam nawet trochę czasu, zanim zrozumieliśmy, co się naprawdę dzieje ... Nie możesz mieć zarówno szybkości, jak i poprawnych wyników, prawda? ).

• Od dzisiaj nasza baza kodu zostanie podzielona na cztery gałęzie. Będziemy zarządzać ich synchronizacją i ręcznie integrować wszystkie poprawki błędów / ewolucje.

Wszystkie oprócz tablic C / C ++ , funkcji narzędziowych VB DOM i języka XSL-T jako języka OOP zostały zaimplementowane pomimo naszych protestów. Oczywiście z biegiem czasu niektóre zostały odkryte, ahem , zepsute i całkowicie porzucone.

Oczywiście, wiarygodność VB King nigdy nie ucierpiała z tego powodu: wśród wyższej kadry kierowniczej pozostał ekspertem technicznym „top gun” ...

Wytworzyło to kilka zabawnych efektów ubocznych, jak widać, klikając łącze Jaki jest najlepszy komentarz w kodzie źródłowym, jaki kiedykolwiek napotkałeś?

W latach 80-tych i 90-tych pracowałem dla firmy produkującej symulatory samolotów, która używała FORTRAN. Nasz kompilator FORTRAN miał ograniczenie do 8 znaków dla nazw zmiennych. Standardy kodowania firmy zarezerwowały pierwsze trzy z nich dla informacji w stylu węgierskim. Musieliśmy więc spróbować stworzyć znaczące nazwy zmiennych z zaledwie 5 znakami!

Pracowałem w miejscu, w którym nastąpiło połączenie dwóch firm. „Dominujący” miał główny serwer napisany w K&R C (tj. Przed ANSI). Zmusili zespoły Java (z obu biur - prawdopodobnie w sumie 20 programistów) do korzystania z tego formatu, który radośnie zignorował dwa filary „debaty o nawiasach klamrowych” i od razu doprowadził do szaleństwa:

if ( x == y ) 
    {
    System.out.println("this is painful");
    x = 0;
    y++;
    }

Zakazana:

while (true) {

Dozwolony:

for (;;) {

mój przyjaciel - nazwiemy go CodeMonkey - dostał swoją pierwszą pracę po college'u [ wiele lat temu], pracując nad rozwojem wewnętrznym w języku COBOL. Jego pierwszy program został odrzucony jako „niezgodny z naszymi standardami”, ponieważ używał… [bzdura!] Zagnieżdżonych instrukcji IF

standardy kodowania zakazały stosowania zagnieżdżonych instrukcji IF

teraz CodeMonkey nie był nieśmiały i był pewien swoich umiejętności, więc upierał się przy pytaniu wszystkich w górę łańcucha i na końcu przejścia, dlaczego ta zasada istnieje. Większość twierdziła, że ​​nie wie, niektóre zmyślały o „czytelności”, aż w końcu jedna osoba przypomniała sobie pierwotny powód: pierwsza wersja kompilatora COBOL, której używali, miała błąd i nie obsługiwała poprawnie zagnieżdżonych instrukcji IF.

Ten błąd kompilatora został oczywiście naprawiony przez co najmniej dekadę, ale nikt nie kwestionował standardów . [baaa!]

CodeMonkey udało się zmienić standardy - ostatecznie!

Kiedyś pracował nad projektem, w którym znaki podkreślenia były zakazane. I mam na myśli całkowity zakaz. Więc w aplikacji ac # winforms, za każdym razem, gdy dodaliśmy nową procedurę obsługi zdarzeń (np. Dla przycisku), musielibyśmy zmienić nazwę domyślnej metody z buttonName_Click () na coś innego, aby zaspokoić ego gościa, który napisał kod standardy. Do dziś nie wiem, co miał przeciwko skromnemu podkreśleniu

Całkowicie bezużyteczne konwencje nazewnictwa baz danych. Każda nazwa tabeli musi zaczynać się od numeru. Liczby pokazują, jaki rodzaj danych znajduje się w tabeli.

• 0: dane używane wszędzie
• 1: dane używane tylko przez określony moduł
• 2: tabela przeglądowa
• 3: kalendarz, czat i poczta
• 4: logowanie

To sprawia, że ​​trudno jest znaleźć stół, jeśli znasz tylko pierwszą literę jego nazwy. Ponadto - ponieważ jest to baza danych mssql - musimy otaczać nazwy tabel wszędzie nawiasami kwadratowymi.

-- doesn't work
select * from 0examples;

-- does work
select * from [0examples];

Robiliśmy projekt w C ++, a kierownikiem zespołu był Pascal.

Mieliśmy więc plik dołączania standardu kodowania, aby przedefiniować całą tę nieznośną składnię C i C ++:

#define BEGIN {
#define END }

ale czekaj, jest więcej!

#define ENDIF }
#define CASE switch

itd. Trudno to sobie przypomnieć po tak długim czasie.

Wymagało to tego, co byłoby doskonale czytelnym kodem C ++ i sprawiło, że stał się nieczytelny dla nikogo z wyjątkiem kierownika zespołu.

Musieliśmy też użyć odwrotnej notacji węgierskiej, tj

MyClass *class_pt  // pt = pointer to type

UINT32 maxHops_u   // u = uint32

chociaż, co dziwne, polubiłem to.

W poprzedniej pracy:

• Tabele „normalne” zaczynają się od T_
• Tabele „systemowe” (zwykle wyszukiwania) zaczynają się od TS_ (z wyjątkiem sytuacji, gdy tego nie robią, ponieważ ktoś nie miał na to ochoty tego dnia)
• Tabele odsyłaczy zaczynają się od TSX_
• Wszystkie nazwy pól zaczynają się od F_

Tak to prawda. Wszystkie pola w każdej tabeli. Abyśmy mogli stwierdzić, że to pole.

Mój kumpel napotkał tę zasadę podczas pracy w rządzie. Używanie ++ (pre lub post) zostało całkowicie zabronione. Powód: różne kompilatory mogą to interpretować inaczej.

Połowa zespołu opowiadała się za wcięciem w czterech miejscach; druga połowa opowiadała się za wcięciem z dwoma spacjami.

Jak można się domyślić, standard kodowania wymagał trzech, aby „urazić wszystkich jednakowo” (bezpośredni cytat).

Brak możliwości użycia Reflection, ponieważ menedżer twierdził, że wiąże się to ze zbyt dużą „magią”.

Najdziwniejsze, jakie miałem, a którego obalenie zajęło mi sporo czasu, było wtedy, gdy właściciel naszej firmy zażądał, aby nasz nowy produkt był tylko IE. Jeśli mógł działać na FireFox, to było w porządku, ale musiał to być tylko IE.

Może nie zabrzmi to zbyt dziwnie, z wyjątkiem jednej małej wady. Całe oprogramowanie było przeznaczone dla niestandardowego pakietu oprogramowania serwerowego, działającego w systemie Linux, a wszystkie komputery klienckie, które kupował nasz klient, to Linux. Nie próbując dowiedzieć się, jak uruchomić Wine (w tamtych czasach, bardzo zawodne) na wszystkich tych komputerach i sprawdzić, czy moglibyśmy uruchomić IE i przeszkolić administratorów, jak debugować problemy z Wine, po prostu nie było to możliwe aby spełnić prośbę właściciela. Problem polegał na tym, że zajmował się projektowaniem stron internetowych i po prostu nie wiedział, jak dostosować witryny internetowe do FireFox.

Prawdopodobnie nie zszokuje Cię wiadomość, że nasza firma zbankrutowała.

Używanie generycznych numerowanych nazw identyfikatorów

W mojej obecnej pracy kieruję się dwiema zasadami, które są naprawdę wredne:

Zasada 1: Za każdym razem, gdy tworzymy nowe pole w tabeli bazy danych, musimy dodać dodatkowe pola rezerwowe do wykorzystania w przyszłości. Te rezerwowe pola są ponumerowane (ponieważ nikt nie wie, które dane będą przechowywać pewnego dnia) Następnym razem, gdy będziemy potrzebować nowego pola, najpierw szukamy nieużywanego pola rezerwowego.

W rezultacie otrzymujemy customer.reserve_field_14adres e-mail klienta.

Pewnego dnia nasz szef myślał o wprowadzeniu stolików rezerwowych , ale na szczęście udało nam się go przekonać, żeby tego nie robił.

Zasada 2: Jeden z naszych produktów jest napisany w VB6, a VB6 ma limit całkowitej liczby różnych nazw identyfikatorów, a ponieważ kod jest bardzo duży, ciągle napotykamy ten limit. W ramach „rozwiązania” wszystkie lokalne nazwy zmiennych są numerowane:

• Lvarlong1
• Lvarlong2
• Lvarstr1
• ...

Chociaż to skutecznie omija limit identyfikatorów, te dwie reguły razem prowadzą do pięknego kodu, takiego jak ten:

...

If Lvarbool1 Then
  Lvarbool2 = True
End If

If Lvarbool2 Or Lvarstr1 <> Lvarstr5 Then
  db.Execute("DELETE FROM customer WHERE " _ 
      & "reserve_field_12 = '" & Lvarstr1 & "'")
End If

...

Możesz sobie wyobrazić, jak trudno jest naprawić stary lub czyjś kod ...

Ostatnia aktualizacja: Teraz używamy również „procedur rezerwowych” dla prywatnych członków:

Private Sub LSub1(Lvarlong1 As Long, Lvarstr1 As String)
  If Lvarlong1 >= 0 Then 
    Lvarbool1 = LFunc1(Lvarstr1)
  Else
    Lvarbool1 = LFunc6()
  End If
  If Lvarbool1 Then
    LSub4 Lvarstr1
  End If
End Sub

EDYCJA: Wygląda na to, że ten wzorzec kodu staje się coraz bardziej popularny. Zobacz ten post w The Daily WTF, aby dowiedzieć się więcej: Astygmatyzm :)

W moich dniach C ++ nie mogliśmy używać ==,> =, <=, &&, itd., Były do ​​tego makra ...

if (bob EQ 7 AND alice LEQ 10)
{
   // blah
}

chodziło oczywiście o "stare przypadkowe przypisanie w warunkowym błędzie", ale mieliśmy również regułę "wstawianie stałych przed zmienne", więc

if (NULL EQ ptr); //ok
if (ptr EQ NULL); //not ok

Właśnie sobie przypomniałem, najprostszym standardem kodowania, jaki kiedykolwiek słyszałem, było „Pisz kod tak, jakby następny opiekun był okrutnym psychopatą, który wie, gdzie mieszkasz”.

Ogólnie notacja węgierska.

Miałem wiele głupich zasad, ale niewiele, które uważałem za wręcz dziwne.

Najgłupsza była praca w NASA, nad którą pracowałem na początku lat 90-tych. To była ogromna praca, przy której pracowało ponad 100 programistów. Doświadczeni programiści, którzy napisali standardy kodowania, zdecydowali, że każdy plik źródłowy powinien zaczynać się czteroliterowym akronimem, a pierwsza litera miała oznaczać grupę odpowiedzialną za plik. To był prawdopodobnie świetny pomysł dla starych projektów FORTRAN 77, do których byli przyzwyczajeni.

Był to jednak projekt Ada , z ładną hierarchiczną strukturą bibliotek, więc nie miało to żadnego sensu. Każdy katalog był pełen plików zaczynających się od tej samej litery, po których następowały 3 kolejne bezsensowne litery, podkreślenie, a następnie część nazwy pliku, która miała znaczenie. Wszystkie pakiety Ada musiały zaczynać się od tej samej pięcioznakowej brodawki. Klauzule „use” Ada również nie były dozwolone (prawdopodobnie dobra rzecz w normalnych okolicznościach), więc oznaczało to, że każde odwołanie do dowolnego identyfikatora, który nie był lokalny dla tego pliku źródłowego, również musiało zawierać tę bezużyteczną brodawkę. Prawdopodobnie powinno nastąpić powstanie w tej sprawie, ale cały projekt był obsadzony przez młodszych programistów i świeżo zatrudnionych po studiach (ja jestem tym drugim).

Typowa instrukcja przypisania (już szczegółowa w Adzie) wyglądałaby mniej więcej tak:

NABC_The_Package_Name.X := NABC_The_Package_Name.X + 
  CXYZ_Some_Other_Package_Name.Delta_X;

Na szczęście byli przynajmniej wystarczająco oświeceni, aby pozwolić nam na ponad 80 kolumn! Mimo to obiekt kurzajka był na tyle znienawidzony, że stał się szablonowym kodem na początku wszystkich plików źródłowych, aby użyć „przemian” Ady, aby pozbyć się brodawki. Dla każdego zaimportowanego („zwiędłego”) pakietu byłaby jedna zmiana nazwy. Lubię to:

package Package_Name renames NABC_Package_Name;
package Some_Other_Package_Name renames CXYZ_Some_Other_Package_Name;
--// Repeated in this vein for an average of 10 lines or so

To, co bardziej kreatywne z nas zrobiło, to próba użycia brodawki do stworzenia bardzo rozsądnej (lub głupiej) nazwy opakowania. (Wiem, o czym myślisz, ale niedozwolone były eksplikacje i wstydź się! To obrzydliwe). Na przykład, był w C spólnej grupy kodu, i potrzebne do pakietu do interakcji z W grupie orkstation. Po burzy mózgów z gościem ze stacji roboczej zdecydowaliśmy się nazwać nasze pakiety, aby ktoś potrzebujący obu musiał napisać:

with CANT_Interface_Package;
with WONT_Interface_Package;

Kiedy zacząłem pracować w jednym miejscu i zacząłem wprowadzać kod do kontroli źródła, mój szef nagle podszedł do mnie i poprosił mnie, abym przestał tak wiele robić. Powiedział mi, że odradza się wykonywanie więcej niż jednego zatwierdzenia dziennie dla programisty, ponieważ zaśmieca to kontrolę źródła. Po prostu gapiłem się na niego ...

Później zrozumiałem, że powodem, dla którego nawet do mnie w tej sprawie wpadł, jest to, że serwer SVN wysyłał mu (i 10 innych kierowników wyższego szczebla) pocztę za każde zatwierdzenie dokonane przez kogoś. Zaśmiecając kontrolę źródła, domyśliłem się, że zapamiętał swoją skrzynkę pocztową.

Wykonywanie wszystkich zapytań do bazy danych za pośrednictwem procedur składowanych w Sql Server 2000. Od złożonych zapytań wielotabelowych po proste, takie jak:

select id, name from people

Argumentami za procedurami były:

• Występ
• Bezpieczeństwo
• Konserwowalność

Wiem, że temat zabiegu jest dość kontrowersyjny, więc zapraszam do oceny mojej odpowiedzi negatywnie;)

Na 1000 wierszy kodu musi przypadać 165 testów jednostkowych (niekoniecznie zautomatyzowanych). To działa w jednym teście na mniej więcej każde 8 linii.

Nie trzeba dodawać, że niektóre wiersze kodu są dość długie, a funkcje zwracają te wskaźniki, aby umożliwić łączenie w łańcuch.

Musieliśmy posortować wszystkie funkcje w klasach alfabetycznie, aby były „łatwiejsze do znalezienia”. Nieważne, że jaź spadł. To było za dużo kliknięć.

(ten sam kierownik techniczny napisał aplikację, aby usunąć wszystkie komentarze z naszego kodu źródłowego).

Mniej więcej w 1987 roku podjąłem pracę w firmie, która mnie zatrudniła, ponieważ byłem jednym z nielicznych ludzi, którzy wiedzieli, jak korzystać z Revelation. Revelation, jeśli nigdy o nim nie słyszałeś, było w istocie implementacją systemu operacyjnego Pick na PC - który, jeśli nigdy o nim nie słyszałeś, ma swoją nazwę od swojego wynalazcy, bajecznie nazwanego Dick Pick. Wiele można powiedzieć o Pick OS, większość z nich jest dobra. Wielu dostawców supermini (przynajmniej Prime i MIPS) korzystało z Pick lub ich własnych niestandardowych implementacji.

Ta firma była sklepem Prime, a do swoich wewnętrznych systemów korzystała z informacji. (Nie, tak naprawdę miała na imię: to była implementacja Pick'a przez Prime.) Mieli kontrakt ze stanem na zbudowanie systemu opartego na PC i poświęcili około roku na projekt Revelation, zanim facet wykonał całą pracę, który był także ich dyrektorem MIS, zdecydował, że nie może już wykonywać obu prac i zatrudnił mnie.

W każdym razie ustalił szereg standardów kodowania dla ich oprogramowania opartego na Prime, z których wiele wywodzi się z dwóch podstawowych warunków: 1) użycia 80-kolumnowych głupich terminali i 2) faktu, że ponieważ Prime nie nie miał edytora wizualnego, napisał swój własny. Ze względu na magiczną przenośność kodu Pick, przeniósł swój edytor do Revelation i zbudował cały projekt na komputerze, używając go.

Revelation, oczywiście, działając na PC, miał doskonały edytor pełnoekranowy i nie sprzeciwiał się, kiedy przekroczyłeś kolumnę 80. Jednak przez pierwsze kilka miesięcy tam byłem, nalegał, żebym użył jego edytora i jego standardy.

Tak więc pierwszym standardem było to, że każdy wiersz kodu musiał być komentowany. Każda linia. Bez wyjątków. Jego uzasadnieniem było to, że nawet jeśli Twój komentarz mówił dokładnie to, co właśnie napisałeś w kodzie, konieczność komentowania oznaczała, że ​​przynajmniej dwa razy pomyślałeś o tym wierszu. Ponadto, jak radośnie zaznaczył, dodał polecenie do edytora, które sformatowało każdą linię kodu, aby można było umieścić komentarz na końcu linii.

O tak. Kiedy komentowałeś każdy wiersz kodu, był to komentarz na końcu wiersza . Krótko mówiąc, pierwsze 64 znaki w każdym wierszu były przeznaczone na kod, potem był średnik, a następnie było 15 znaków na opisanie tego, co robiły twoje 64 znaki. Krótko mówiąc, używaliśmy konwencji języka asemblera do formatowania naszego kodu Pick / Basic. Doprowadziło to do rzeczy, które wyglądały tak:

EVENT.LIST[DATE.INDEX][-1] = _         ;ADD THE MOST RECENT EVENT
   EVENTS[LEN(EVENTS)]                 ;TO THE END OF EVENT LIST

(Właściwie po 20 latach w końcu zapomniałem składni kontynuacji wiersza R / Basic, więc mogło wyglądać inaczej. Ale masz pomysł.)

Dodatkowo, ilekroć trzeba było wstawić komentarze wielowierszowe, obowiązuje zasada, że ​​używasz skrzynki na kwiaty:

************************************************************************
**  IN CASE YOU NEVER HEARD OF ONE, OR COULDN'T GUESS FROM ITS NAME,  **
**  THIS IS A FLOWER BOX.                                             **
************************************************************************

Tak, te zamykające gwiazdki w każdym wierszu były wymagane. W końcu, jeśli używałeś jego edytora, było to tylko proste polecenie edytora, aby wstawić skrzynkę kwiatową.

Zmuszenie go do złagodzenia się i umożliwienia mi użycia wbudowanego edytora Revelation było sporą bitwą. Na początku nalegał, po prostu dlatego, że takie były zasady. Kiedy sprzeciwiłem się, że a) znałem już edytor Revelation b) był znacznie bardziej funkcjonalny niż jego edytor, c) inni programiści Revelation mieliby tę samą perspektywę, odparł, że gdybym nie trenował na jego edytorze, nie zrobiłbym tego kiedykolwiek będzie w stanie pracować na bazie kodu Prime, co, jak oboje wiedzieliśmy, nie nastąpi, dopóki piekło pozostanie niezamarznięte. W końcu się poddał.

Ale standardy kodowania były ostatnie. Zwłaszcza komentarze do skrzynki z kwiatami były głupią stratą czasu, a on walczył ze mną zębami i paznokciami, mówiąc, że gdybym użył odpowiedniego edytora, utrzymanie ich byłoby całkowicie łatwe. (Całość stała się dość pasywno-agresywna.) W końcu cicho się poddałem i odtąd cały kod, który przyniosłem do recenzji kodu, zawierał jego cenne komentarze do skrzynki na kwiaty.

Pewnego dnia, kilka miesięcy po rozpoczęciu pracy, kiedy udowodniłem, że jestem bardziej niż kompetentny (zwłaszcza w porównaniu z niezwykłą paradą innych programistów, którzy przeszli przez to biuro, gdy tam pracowałem), patrzył mi przez ramię, gdy ja zadziałało, a on zauważył, że nie używam komentarzy do skrzynki na kwiaty. Och, powiedziałem, napisałem program do formatowania kodu źródłowego, który konwertuje moje komentarze na twój styl, kiedy je drukuję. To łatwiejsze niż utrzymywanie ich w edytorze. Otworzył usta, pomyślał przez chwilę, zamknął je, odszedł i nigdy więcej nie rozmawialiśmy o standardach kodowania. Po tym obie nasze prace stały się łatwiejsze.

W mojej pierwszej pracy wszystkie programy w C, bez względu na to, jak proste czy złożone, miały tylko cztery funkcje. Miałeś główną, która wywoływała po kolei pozostałe trzy funkcje. Nie pamiętam ich nazw, ale były one czymś w rodzaju begin (), middle () i end (). begin () otworzyła pliki i połączenia z bazą danych, end () zamknęła je, a middle () zrobił wszystko inne . Nie trzeba dodawać, że middle () to bardzo długa funkcja.

Aby było jeszcze lepiej, wszystkie zmienne musiały być globalne.

Jednym z moich najbardziej dumnych wspomnień z tej pracy jest udział w powszechnym buncie, który doprowadził do zniszczenia tych standardów.

Zewnętrznie napisany standard kodowania w C, który miał regułę „nie polegaj na wbudowanym priorytecie operatorów, zawsze używaj nawiasów”

W porządku, oczywistym zamiarem było zakazanie:

a = 3 + 6 * 2;

na korzyść:

a = 3 + (6 * 2);

Chodziło o to, że zostało to wymuszone przez narzędzie, które działało zgodnie z regułami składni języka C, które to „=”, „==”, „”. a dostęp do tablicy są operatorami. Więc kod taki jak:

a[i].x += b[i].y + d - 7;

musiało być zapisane jako:

((a[i]).x) += (((b[i]).y + d) - 7);