Luke J. Li

Co jeśli nie możesz znaleźć nazwy dla funkcji? (ew. dla zmiennej, klasy itp.). Zadaj sobie pytania - co funkcja robi? Jakie jest jej przeznaczenie? Jaka jest metafora, która by pasowała (wszystko jest pewną metaforą)? Czasem też sprawdza się taka metoda, żeby najpierw pomyśleć o metaforach/koncepcjach, tzn. najpierw wymyślić nazwę dla funkcji, jej argumenty, sposób wywołania, a dopiero potem zabierać się za implementację. Ja jak mam zrobić "publiczne" API  (przez publiczne mam na myśli wszystko to, z czego się używa w wielu miejscach - np. klasa, która będzie używana przez 20 różnych modułów w projekcie) - to najpierw staram się wymyślić ładne i wygodne API, wtedy myślę o abstrakcjach, nazwach itp. Otwieram sobie oddzielny plik i po prostu "piszę na sucho" przypadki użycia danej funkcji (w momencie kiedy jeszcze implementacja nie jest napisana). A potem staram się dostosować implementację do nazw i do API, które sobie wymyśliłem. (zauważ, że im bardziej ...

Jestem zwolennikiem krótkich nazw. Niech nazwa funkcji czy klasy będzie jednym słowem. Czasem dwoma. Klasy o nazwach typu  ObjectFactoryCreatingFactoryBean łamią moje poczucie stylu. Parametry też funkcja powinna mieć w niewielkiej liczbie. Jeśli można, winno być to zero. Jeśli chcemy, możemy dodać również parametr czy dwa. Jednak dalsza ich liczba to przesada*.   Ciężko zapamiętać wtedy kolejność. Lepszym rozwiązaniem byłoby wtedy przekazanie tablicy albo obiektu. Uzasadnionym wyjątkiem być może mogłaby być funkcja, która działałaby jak `console.log` - to znaczy brałaby  wszystkie końcowe argumenty i robiła z nimi dokładnie to samo. * dodane 3.10.2017: no, może trzy parametry jeszcze ujdą - nie chodzi o to, żeby się kurczowo trzymać liczby parametrów, tylko o to, żeby nie robić bałaganu. Czasem nawet 4 parametry będą ok, np. moglibysmy mieć createRectangle(x, y, width, height) i byłoby to dalej intuicyjne. Jednak nawet wtedy rozważyłbym api createRectangle({x: 0, ...