Strona główna » Blog » Identyfikatory: under_score kontra camelCase

Identyfikatory: under_score kontra camelCase

Identyfikatory to bardzo ważny element kodu. Przeprowadzono rozmaite badania (link prowadzi do papieru z 2013 roku kompletującego namiary na chyba wszystkie najbardziej znane), które raz wspierały jeden styl a raz drugi w takim czy innym aspekcie. Ostatecznie jednak ostatnie lata wprowadziły do badań element eye-trackingu, który wykazał istotną i raczej bezdyskusyjną różnicę między tymi stylami: identyfikatory pisane stylem camelCase są wolniej przetwarzane przez ludzki mózg, ponieważ musi on podjąć dodatkową pracę w rozdzielaniu wyrazów. Jest to wyraźnie widoczne na graficznych reprezentacjach wodzenia wzrokiem i punktów fiksacji. Trudno porównać czasowo pracę z oboma stylami, aczkolwiek pomiary wskazały, że identyfikatory camelCase wymagały średnio 20% więcej czasu, aby je poprawnie odnaleźć wzrokiem i przetworzyć. Im dłuższy “wyrazowo” identyfikator tym większy bonus dla stylu under_score – dla trójwyrazowych identyfikatorów camelCase wymagał aż 36% czasu więcej! Przy bardzo krótkich identyfikatorach typu “rowNum” szala może się przechylić ku camelCase, nie mam jednak żadnych danych o ile.

Jeden obraz za tysiąc słów

Poniżej ilustracja z “Extended Models on The Impact of Identifier Style on Effort and Comprehension” (2012) by Binkley, Davis, Lawrie, Maletic, Morell, Shariff. Linie przedstawiają przybliżone wodzenie wzrokiem a koła oznaczają miejsca fiksacji (zatrzymania wzroku) – im koło większe tym fiksacja dłuższa. Z tego co pamiętam, domniemuje się, że momenty fiksacji są także momentami pracy umysłowej. W tym kontekście obrazek mówi wystarczająco dużo o camelCase.

Przedstawienie graficzne zapisów wodzenia wzrokiem po identyfikatorach under_score i camelCase

Ale może tutaj jest coś za coś?

No dobrze, ale może ktoś zapytać, czy to nie jest jakaś sensowna wymiana, aby spędzić 1/3 albo 1/5 czasu więcej nad identyfikatorami, ale mieć jakieś profity z camelCase. Tak jak wspomaniałem, badania nie są jednoznaczne, ale w ostatnich które widziałem, panowało nastawienie na rekomendowanie camelCase ze względu na większą dokładność w porównywaniu identyfikatorów oraz przyjazność nowicjuszom. To są nieco specyficzne zyski. Dokładność w porównywaniu oznacza tyle, ze jeżeli w kodzie masz dwa podobne identyfikatory, to będziesz mógł lepiej sprawniej rozróżnić np. “countProcessesWaitingTime” od “countProcessorWaitingTime”. Tutaj jednak pojawie się pytanie – jak często takie porównania mają miejsce? Spójrz na stronę 18 wspomnianego “Extended Models…” i sam się zastanów, czy Twój – pisany osobiście przez Ciebie! – kod, wygląda jak ten “makaron”. Albo czy tak wygląda kod pisany przez kolegów z Twojego zespołu. Dodam, że warto wziąć poprawkę na podświetlanie składni, które czyni kod bardziej przejrzystym, co też potwierdzają badania.

Do niezaprzeczalnych zalet camelCase nad under_score należy to, że identyfikatory pisane w camelCase są krótsze, czyli zajmują mniej miejsca na ekranie. Czy może mieć to znaczenie? Tak, jeżeli programujesz w terminalu. Podejrzewam jednak, że tak nie jest.

Rekomendacja

Rekomenduję under_score. 🙂

Dodaj komentarz