Modelując świat w programach, skryptach, arkuszach stylów i bazach danych stajemy przed koniecznością nazywania zmiennych logicznych. Mamy tu pełną dowolność, ale czy powinniśmy z niej korzystać w 100%?
Zdecydowanie nie (!), ponieważ może ona doprowadzić do zmniejszenia czytelności kodu. Swoje wybory powinniśmy ograniczać do nazw o wydźwięku pozytywnym. Dlaczego? Żeby uzyskać odpowiedź, przeanalizujmy używanie negacji.
Zmienne
Bywa, że programiści w nazwie zmiennej (lub np. kolumnie bazy danych) wprowadzają zaprzeczenie jawne np.
|
1 2 3 |
dontShow notComplete isNotVisible |
lub mniej jawne, dla przykładu:
|
1 2 |
hidden disabled |
Oczywiście nie ma to wpływu na działanie programu/skryptu, ale może to doprowadzić do dezorientacji podczas analizowania kodu i w czasie wprowadzania zmian, a co za tym idzie, do wydłużenia czasu pracy nad utrzymywaniem oprogramowania. Przeanalizujmy następujący fragment kodu:
|
1 |
if (!isNotVisible && !dontShowItem) { ... } |
Warunek ma sens, ale jest bardzo nieczytelny. O ileż prościej go zrozumieć, gdy zamienimy nazwy zmiennych, tak by nie zawierały zaprzeczeń:
|
1 |
if (isVisible && showItem) { ... } |
Zdecydowanie czytelniej, prawda? Poniżej jeszcze jeden przykład (z portalu programmers.stackexchange.com):
|
1 2 |
// z negacjami w nazwach if (!printout.inhibited && !( !userIsUnautheticated || !page.isUnauthenticated )) { ... } |
|
1 2 |
// bez zaprzeczeń if (printout.enabled && !( userIsAuthenticated || page.isAuthenticated )) { ... } |
Przytoczone wyżej zaprzeczenia zmniejszają przejrzystość, ale potencjalnie można by natrafić na jeszcze gorszy warunek:
|
1 |
!isNotComplete == 0 |
Ale tego nikomu nie życzę.
Natrafiłem kiedyś także na zmienną skipAdd . To co prawda nie negacja, ale problem jest ten sam – po co używać skipAdd = true i skipAdd = false skoro można prościej (odpowiednio): add = false, add = true.
Zmienna disabled . Po co? Lepiej używać enabled i w razie potrzeby negować.
Funkcje / metody
Nazwy funkcji, które coś sprawdzają, analogicznie do zmiennych także powinny brzmieć pozytywnie (np. isAuthenticated()), ale te które zwracają pewne dane już niekoniecznie (np. getNonEmpty() ).
Zmienne konfiguracyjne…
…czyli jak nie pisać konfigów:
|
1 2 |
$_CONFIG['nohotlink_enabled'] = false; $_CONFIG['nooffsitelink_enabled'] = false; |
CSS
Omawiany temat tyczy się również konwencji nazewnictwa w arkuszach stylów. Na stronach internetowych bardzo często trzeba dynamicznie coś pokazywać – coś jest widoczne (visible/active) a coś nie (hidden). Czasem nie warto używać ukrywania, niech elementy są niewidoczne domyślnie, a widoczne kiedy otrzymają odpowiednie „pozytywne” klasy (np. .active )*.
* Nie twierdzę, że Bootstrapowe klasy do ukrywania (np. .hidden-lg , .hidden-xs itd.) są złym pomysłem. Omawiane negacje dotyczą innych zastosowań.
Przedrostki
We wpisie pomijam tworzenie nazw zmiennych z przedrostkami takimi jak np. is czy has, ponieważ nie wpływają na to, czy nazwa zmiennej będzie pozytywna lub negatywna.
Podsumowanie
- Piszmy pozytywnie, żeby kod był łatwiejszy do zrozumienia.
- Negujmy za pomocą operatorów i konstrukcji do tego przeznaczonych.
Źródła: