Best Practices: Lepiej źle czy w ogóle?



Mówi się, że lepsze są kiepskie standardy kodowania niż żadne. Ale czy na pewno zawsze?
Podczas prac nad jednym z systemów moje oczy zostały zaatakowane przez poniższy fragment kodu (nazwy procedur i zmiennych są zmienione a ich podobieństwo do prawdziwego kodu jest czysto przypadkowe! Aczkolwiek poniższy przykład wiernie odzwierciedla napotkany problem)



Zeszło mi się dobre parę minut, na wpatrywanie się w ten fragment kodu. Mój mózg szalał próbując znaleźć sensowną odpowiedź na to, co oczy widzą. 

No przecież nie może być dwóch zmiennych o tych samych nazwach?! I jeszcze jedną zmienną przypisywać do drugiej, tej samej, sądząc po nazwie? O co tutaj chodzi!

Dopiero po dłuższej chwili wpatrywania się w monitor z odległości mniejszej niż 5 cm udało się odkryć zagadkę.
Te zmienne, wbrew pozorom - nie mają takiej samej nazwy! 
Zgodnie z obowiązującą w projekcie konwencją nazewniczą parametry wejściowe zaczynały się od literki „i”  - IN a zmienne lokalne – od literki „L” - Local.

Jak do tego dodaliśmy wielkie i małe litery to otrzymaliśmy zmienne
I_param → to parametr wejściowy zaczynający się od wielkiej litery „i”
l_param → to zmienna lokalna zaczynająca się od małej litery „L”

I efekt stosowania  standardów kodowania jak najbardziej spektakularny!

Dlatego jest niezwykle ważne, by podczas przygotowywanie standardów kodowania przemyśleć je po wieloma kątami:
1. po co chcemy stosować standardy
2. jakich błędów chcemy dzięki standardom uniknąć.
3. jakie mogą być problemy z daną konwencją (np. zbyt podobne nazwy zmiennych rożnych typów).


Parę wskazówek, na co zwracać uwagę przy tworzenie standardów kodowania

Komentarze