O tym jak nazywać zmienne.
Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?
Zarejestruj się!

O tym jak nazywać zmienne.

AutorWiadomość
Temat założony przez niniejszego użytkownika
O tym jak nazywać zmienne.
» 2015-02-27 14:45:05
Witam!

Napisałem post na swoim blogu o tym, jak nazywać zmienne. Temat fundamentalny, aczkolwiek nie spotkałem go nigdy w żadnej książce ani w Internecie szukając różnych kursów dotyczących programowania, więc stwierdziłem, że warto się podzielić tymi informacjami na tym forum, gdzie trafia sporo początkujących. Link do artykułu: Jak nazywać zmienne?.

Z chęcią się również dowiem, co sądzi na ten temat starszyzna forum :) Zachęcam do komentowania oraz dyskusji.

Pozdrawiam,
Mrowqa
P-127446
» 2015-02-27 15:20:48
Trochę nie jarzę, jeśli miałbym się trzymać zasady pojedynczej odpowiedzialności to czym byłaby klasa o nazwie WikiPage?
P-127450
» 2015-02-27 15:50:52
Nie zgodzę się z Tobą odnośnie unikania notacji węgierskiej, czy jakiejkolwiek innej. Jakoś w projekcie Chromium używa się jakiejś notacji i np. zmienne należące do klasy mają sufiks _. Przykład:
C/C++
RenderViewImpl::RenderViewImpl( const ViewMsg_New_Params & params )
    : RenderWidget( blink::WebPopupTypeNone, params.initial_size.screen_info, params.swapped_out, params.hidden, params.never_visible )
     , webkit_preferences_( params.web_preferences )
     , send_content_state_immediately_( false )
     , enabled_bindings_( 0 )
     , send_preferred_size_changes_( false )
     , navigation_gesture_( NavigationGestureUnknown )
     , opened_by_user_gesture_( true )
     , opener_suppressed_( false )
     , suppress_dialogs_until_swap_out_( false )
     , page_id_( - 1 )
     , next_page_id_( params.next_page_id )
     , history_list_offset_( - 1 )
     , history_list_length_( 0 )
     , frames_in_progress_( 0 )
     , target_url_status_( TARGET_NONE )
     , uses_temporary_zoom_level_( false )
     , #if defined(OS_ANDROID) top_controls_constraints_( TOP_CONTROLS_STATE_BOTH )
     , #endif has_scrolled_focused_editable_node_into_rect_( false )
     , speech_recognition_dispatcher_( NULL )
     , devtools_agent_( NULL )
     , mouse_lock_dispatcher_( NULL )
     , #if defined(OS_ANDROID) expected_content_intent_id_( 0 )
     , #endif #if defined(OS_WIN) focused_plugin_id_( - 1 )
     , #endif #if defined(ENABLE_PLUGINS) plugin_find_handler_( NULL )
     , focused_pepper_plugin_( NULL )
     , pepper_last_mouse_event_target_( NULL )
     , #endif enumeration_completion_id_( 0 )
     , session_storage_namespace_id_( params.session_storage_namespace_id )
     , next_snapshot_id_( 0 )
{
}
Webkit jakoś również używa notacji i zmienne klasy mają z kolei prefiksy m_. Inne duże projekty również mają jakąś notację, więc Twoja sugestia, że IDE w czymś pomaga i tym samym nie należy stosować notacji jest błędna, bo IDE nie zawsze radzi sobie z projektem, a poza tym czytając kod deweloper nie ma ochoty najeżdżać co i rusz na dymek, aby stwierdzić jaka jest to de-facto zmienna (lokalna/argument metody/pole klasy itp). Poza tym jak są mechanizmy do robienia codereview, to nie są one zintegrowane z IDE. Jak robisz diff-a zmian to również nie widzisz czy zmienna należy do klasy czy nie. Jak przeglądasz zmiany w SVN-ie czy w GIT to również nie masz IDE, które podpowiadałoby jakiego typu jest dana zmienna i w jakim zasięgu się znajduje.
P-127452
» 2015-02-27 15:59:52
Ogólnie rzecz biorąc po ogólnych 'oględzinach' przykładowych kodów, porady są słuszne odnośnie tego jak nazywać zmienne. Uwaga natomiast co do notacji jest nie na miejscu.
P-127453
» 2015-02-27 16:11:06

Temat fundamentalny, aczkolwiek nie spotkałem go nigdy w żadnej książce
Kilkanaście stron w Kodzie Doskonałym oraz kolejne kilka o nazwach funkcji ;) również kilka stron w Programming: Principles and Practice Using C++.


Prawdą jest, że wiele IDE wyświetla nam ten komentarz, ale pamiętaj, że kod nie czyta się tylko w IDE!

Dobra nazwa zmiennej sama sugeruje, jakiego jest typu, a w razie niepewności zawsze można to szybko sprawdzić przy pomocy IDE.
Eee? Nie używaj komentarzy bo nie każdy ma IDE, unikaj notacji węgierskiej bo każdy ma IDE :)


Nazwa powinna być opisowa, ale krótka
Też się nie zgodzę. Nazwa powinna być tym krótsza im mniejszy ma zasięg. Czyli nazwy z przestrzeni globalnej lub niemalże globalnej powinny mieć nazwy dłuższe za to dobrze opisane natomiast nazwy o zakresie kilku wierszy mogą być naprawdę prozaicznie nazwane. Pozwoli to też na unikanie konfliktów nazw. Używanie zawsze krótkich nazw prędzej czy później skończy się przesłanianiem nazw w dużych projektach.

A tak w ogóle to generalnie fajny wpis :)
P-127455
» 2015-02-27 16:56:35
C/C++
Blabla()
    : asdasd
     , #if defined(OS_ANDROID) expected_content_intent_id_( 0 )
     , #endif #if defined(OS_WIN) focused_plugin_id_( - 1 )
     , #endif #if defined(ENABLE_PLUGINS) plugin_find_handler_( NULL )
Ładny błąd STC ;)
P-127458
» 2015-02-27 17:27:44
Inne duże projekty również mają jakąś notację
To oczywiste i wynika z definicji notacji, alternatywą jest tu brak identyfikatorów w ogóle, z czym może być problem, bo mowa o C++, a nie o brainfucku lub Whitespace. Post dotyczył konkretnie notacji węgierskiej.

w projekcie Chromium […] zmienne należące do klasy mają sufiks _
Webkit […] zmienne klasy mają z kolei prefiksy m_
W LLVM i w większości boosta z kolei nie ma żadnych takich ozdobników. W przypadku C++ nie ma sensu wysuwać żadnych wniosków na podstawie jednego codebase, bo w przeciwieństwie do praktycznie każdego innego mainstreamowego języka nie ma żadnej pojedynczej konwencji i każdy pisze, jak chce.
P-127462
Temat założony przez niniejszego użytkownika
» 2015-02-27 18:52:06
@maly
Trochę nie jarzę, jeśli miałbym się trzymać zasady pojedynczej odpowiedzialności to czym byłaby klasa o nazwie WikiPage?
WikiPage to przykład wyrażenia rzeczownikowego, a ten wątek na forum nie jest o SRP, więc radzę poszukać informacji w Internecie. Ogólnie mówiąc: odpowiedzialność WikiPage zależy od tego, czym dokładnie zarządza, więc jak chcesz sobie odpowiedzieć na to pytanie, to zaprojektuj sobie dokładnie kod.

@DejaVu
Nie zgodzę się z Tobą odnośnie unikania notacji węgierskiej, czy jakiejkolwiek innej.
Tak jak już to podkreślił @Alueril, post był konkretnie o notacji węgierskiej i innych konwencji nie skreślam. Ba, napisałem nawet, by mieć dokładnie jedną konwencję w całym projekcie i jej się trzymać:
Jedna konwencja nazewnictwa – jeśli pisząc w Pythonie w pewnym miejscu dla nazw klasy zastosujesz PascalCase'a, dla zmiennych lokalnych camelCase'a, a dla metod snake_case'a – zachowaj tę konwencję w całym projekcie.
Inne duże projekty również mają jakąś notację, więc Twoja sugestia, że IDE w czymś pomaga i tym samym nie należy stosować notacji jest błędna, bo IDE nie zawsze radzi sobie z projektem, a poza tym czytając kod deweloper nie ma ochoty najeżdżać co i rusz na dymek, aby stwierdzić jaka jest to de-facto zmienna (lokalna/argument metody/pole klasy itp).
1. Odnośnie konwencji - patrz wyżej.
2. Nigdy nie pracowałem nad ogromnymi projektami, więc to jest cenna uwaga - nie wiem jak sobie IDE wtedy radzą, ale myślę, że raczej są one tak napisane, by takie funkcjonalności jak podpowiadanie nazw czy kolorowanie argumentów funkcji działało.
3. Skoro IDE sobie nie radzi, by np. pokolorować daną zmienną jako argument metody, to skąd ma wziąć informacje do dymka? Wiem, że może wtedy przeszukać projekt, ale sądzę, że raczej środowiska są na tyle inteligentne, by trzymać gdzieś w cache'u sparsowany projekt i ładować do RAM-u te informacje, z których się aktualnie korzysta (np. otwarte pliki z kodem w edytorze).

Poza tym jak są mechanizmy do robienia codereview, to nie są one zintegrowane z IDE. Jak robisz diff-a zmian to również nie widzisz czy zmienna należy do klasy czy nie. Jak przeglądasz zmiany w SVN-ie czy w GIT to również nie masz IDE, które podpowiadałoby jakiego typu jest dana zmienna i w jakim zasięgu się znajduje.
Prawda. IDE ma bowiem wspomagać pisanie kodu. Dobra nazwa powinna sama sugerować jakiego jest typu, a określenia zasięgu też nie powinno być trudne - metody powinny być krótkie, więc czytając kod powinieneś pamiętać które z tych, prawdopodobnie kilku, zmiennych są lokalne. Choć mówiąc o długości metod wykraczamy poza nazewnictwo zmiennych, ale jak widać jest to ze sobą powiązane, więc zależy od preferencji konkretnego programisty.

@akwes
Kilkanaście stron w Kodzie Doskonałym oraz kolejne kilka o nazwach funkcji ;) również kilka stron w Programming: Principles and Practice Using C++.
Jeśli mnie pamięć nie myli, to te książki nie uczą programowania od zera, a są dedykowane osobom, które te wiedzę posiadają.

Eee? Nie używaj komentarzy bo nie każdy ma IDE, unikaj notacji węgierskiej bo każdy ma IDE :)
Mieszasz konteksty. Kod czyta się nie tylko w IDE (więc utwórz bardziej opisową nazwę tak, by można było usunąć komentarz bez utraty informacji), ale pisze się go tylko w IDE, a przynajmniej roztropniejsi tak robią, więc lepiej sobie nie utrudniać pracy z IDE. Poza tym napisałem, że w razie niepewności, bowiem dobra nazwa sama Ci powie, jakie typu jest dana zmienna, a IDE ma w ostateczności przypomnieć Tobie typ (co raczej często zdarzać się nie będzie).

Też się nie zgodzę. Nazwa powinna być tym krótsza im mniejszy ma zasięg.
Przeczytałeś to, co było pod zacytowanym przez Ciebie nagłówkiem? Jest tam napisane, by mając wymyślonych kilka dobrych nazw, wybrać jedną z tych krótszych. Z kolei w zacytowanych słowach Roberta Martina (i później także przeze mnie opisanych) było wyjaśnione, że dobra nazwa, to taka, która zawiera wystarczająco dużo informacji, by jednoznacznie określić wszystko, co można powiedzieć o danej zmiennej, klasie tudzież metodzie.
A tak poza tym - krótki to pojęcie względne ;)



Ogólnie rzecz biorąc po ogólnych 'oględzinach' przykładowych kodów, porady są słuszne odnośnie tego jak nazywać zmienne.
A tak w ogóle to generalnie fajny wpis :)
Miło mi to przeczytać i dziękuję za Wasze uwagi oraz opinie. Jak ktoś ma jeszcze coś do powiedzenia, to czekam :)

Ogólnie rzecz biorąc, jak napisałem na początku postu, nie wszyscy muszą zgodzić się ze wszystkimi radami, które zostały w tym poście zawarte. Posiadam relatywnie mało doświadczenia i cały czas się uczę. Poza tym kwestia nazewnictwa jest zależna w dużym stopniu od programisty, a każdy ma swoje ulubione konwencje, co z resztą @Alueril już zaznaczył podając przykłady :)
P-127468
« 1 » 2
 Strona 1 z 2Następna strona