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
Prześlij komentarz