Nazwy dla funkcji, klas, pól, itd.

Witam, przy tworzeniu swojego pierwszego większego projektu natrafiłem na mały problem, ponieważ zaczyna mi brakować nazw głównie dla funkcji. Dlatego mam pytanie czy jest jakaś strona/temat na jakimś forum temu poświęcony. Oczywiście w języku angielskim.

Nie wiem, ale możesz wrzucić swój kod tu na forum, to na pewno coś podpowiemy ;)

Daj przykład, podpowiemy.
Ja to nadaje nudne powtarzalne nazwy, jak nazwiesz sensownie klasy to potem wystarczą krótkie nazwy: find, save itp

Często gdy nie wiem jak nazwać metodę albo klasę to okazuje się, że ta robi dwie (lub więcej) różne rzeczy (czyli wyraźnie łamię zasadę SRP - single responsibility principle). Przeorganizowanie kodu sprawia, że łatwiej go precyzyjnie ponazywać, a więc też będzie się go łatwiej czytać ze zrozumieniem. Oczywiście nie zawsze trudność w nazywaniu klas i metod wynika z ich złej architektury. Czasami po prostu trudno dobrać słowa. Jednak intuicyjne nazewnictwo jest dla mnie oznaką dbałości o zrozumiałą architekturę.

Nie sądzę, by były jakieś magiczne reguły dla dobrego nazewnictwa, ale za to są oznaki kiepskiego nazewnictwo. Słabe jest np nadużywanie członów "Manager", "Helper", "Utils", etc O ile nie robimy np biblioteki z szerokim zestawem funkcji ułatwiających pracę z plikami (i niewychodzącej poza tę sferę funkcjonalności), to FileUtils niewiele mówi, oprócz tego, że zawiera funkcje operujące na plikach. Takie klaski zawierają często funkcje, które implementują sporo funkcjonalności niezwiązanych z plikami per se, np loadTemplate(), która ładuje plik, zamienia regexpami jakieś pola, potem wrzuca do XML DOMa i dopiero zwraca.

Brak umiejętności znalezienia nazwy to często syndrom złego designu.

Jak masz publiczne rzeczy (publiczne metody, rutyny używane w wielu miejscach, często używane klasy) to najlepiej myśleć o nazwach najpierw, a potem zabierać się za implementację/refaktoring.

Chciałem napisać posta, ale wyszedł mi długi i zrobiłem z tego cały post na blogu. Dostępny tutaj:
http://13zmiennych.blogspot.com/2019/02/co-jesli-nie-mogeznalezcnazwy.html

Ale co jest złego w klasie o nazwie class GetFromDatabase,Display,PrintAndSentToLogger?

@cerrato moim zdaniem tego typu przegadana nazwa PrintAndSendToLogger, mimo, że brzydka i długa bywa czasem lepsza od krótszej (ale o tym też w sumie w tym poście na blogu teraz napisałem).

Dlatego mam pytanie czy jest jakaś strona/temat na jakimś forum temu poświęcony.

W książce "Czysty kod" był jakiś rozdział bodajże o nazywaniu, jeśli dobrze pamiętam.

Tu mam idealny przykład najgorzej nazwanej chyba funkcji, enuma:

private void SomeFunctionForProgressBar()
        {
            if (ExperienceProgress.Value >= ExperienceProgress.Maximum)
            {
                game.IncreasePlayerLevel();
                TextOnProgressBar.Text = "LEVEL " + game.GetPlayerStatistics(PlayerFields.Level) + " " + ExperienceProgress.Value + "/" + ExperienceProgress.Maximum;
            }
            ExperienceProgress.Minimum = 0;
            ExperienceProgress.Maximum = game.ReturnDictionary()[int.Parse(game.GetPlayerStatistics(PlayerFields.Level))];
            ExperienceProgress.Value = int.Parse(game.GetPlayerStatistics(PlayerFields.Experience));
        }

Musiałbym bym chyba podzielić tą funkcje na mniejsze i sensownie nazwać. Nie wiem też jak nazwać enuma z polami klas np. Player.
C# WPF

Bardzo proceduralny kod. Nie mówię, że to źle, tylko zwracam uwagę, że zdaje się używasz klas, natomiast funkcja, którą wrzuciłeś, zdradza fakt, że całość jest proceduralna. Dlaczego Player nie ma własnej klasy? Tylko obiekt gry trzyma wszystkie dane gracza? I znowu: to nie musi być złe same w sobie. Chociaż myślę, że pisanie w sposób bardziej OOP, gdzie różne rzeczy mają oddzielne klasy (a nie są trzymane i wyciągane z globalnego systemu zarządzania stanem) mogłoby ułatwić zapanowanie nad tym wszystkim. I np. gracz mógłby sam sobą zarządzać.

 if (ExperienceProgress.Value >= ExperienceProgress.Maximum)
            {
                game.IncreasePlayerLevel();

tego kawałka kodu nie rozumiem. Czy ExperienceProgress jest paskiem postępu na ekranie, czy abstrakcyjną ideą "postępu doświadczenia"?
Jeśli to pierwsze (a funkcja ma przecież w nazwie "progress bar"), to nie rozumiem, czemu wartość paska postępu "steruje" graczem (skoro po osiągnięciu maximum na pasku postępu, poziom gracza się powiększa).

Tym sposobem masz za dużą zależność między tym jak coś wygląda, a tym jak działa (co jeśli będziesz chciał wywalić pasek postępu?).

Pasek postępu, jako wizualna kontrolka na ekranie powinna czerpać informacje z jakiegoś innego źródła danych (nazwijmy je X), a logika uaktualniająca level gracza też powinna odpytywać X, a nie patrzeć na pasek postępu.

Musiałbym bym chyba podzielić tą funkcje na mniejsze i sensownie nazwać

Tu nad architekturą trzeba najpierw pomyśleć, nad tym, w jaki sposób funkcja się komunikuje z resztą aplikacji, bo tutaj coś szwankuje. No i wydaje się, że problem może nie być w tej jednej funkcji, tylko w całości.

game.IncreasePlayerLevel();
game.GetPlayerStatistics

Jakbyś miał obiekt klasy player i logikę dotyczącą gracza w tej klasie, to mógłbyś mieć metodę increaseLevel(). Znając życie w klasie gra jest wszystko, tzn. za dużo.

 ExperienceProgress.Minimum = 0;
 ExperienceProgress.Maximum = game.ReturnDictionary()[int.Parse(game.GetPlayerStatistics(PlayerFields.Level))];
ExperienceProgress.Value = int.Parse(game.GetPlayerStatistics(PlayerFields.Experience));

Tutaj to samo, logika do klasy odpowiedzialnej za wszystko związane z doświadczeniem.

Sama nazwa głównej metody np. updateProgress

ExperienceProgress jest kontrolką WPF, a klasa game przechowuje prywatne pole klasy player

LukeJL napisał(a):

Bardzo proceduralny kod. Nie mówię, że to źle, tylko zwracam uwagę, że zdaje się używasz klas, natomiast funkcja, którą wrzuciłeś, zdradza fakt, że całość jest proceduralna. Dlaczego Player nie ma własnej klasy? Tylko obiekt gry trzyma wszystkie dane gracza? I znowu: to nie musi być złe same w sobie. Chociaż myślę, że pisanie w sposób bardziej OOP, gdzie różne rzeczy mają oddzielne klasy (a nie są trzymane i wyciągane z globalnego systemu zarządzania stanem) mogłoby ułatwić zapanowanie nad tym wszystkim. I np. gracz mógłby sam sobą zarządzać.

 if (ExperienceProgress.Value >= ExperienceProgress.Maximum)
            {
                game.IncreasePlayerLevel();

tego kawałka kodu nie rozumiem. Czy ExperienceProgress jest paskiem postępu na ekranie, czy abstrakcyjną ideą "postępu doświadczenia"?
Jeśli to pierwsze (a funkcja ma przecież w nazwie "progress bar"), to nie rozumiem, czemu wartość paska postępu "steruje" graczem (skoro po osiągnięciu maximum na pasku postępu, poziom gracza się powiększa).

Tym sposobem masz za dużą zależność między tym jak coś wygląda, a tym jak działa (co jeśli będziesz chciał wywalić pasek postępu?).

Pasek postępu, jako wizualna kontrolka na ekranie powinna czerpać informacje z jakiegoś innego źródła danych (nazwijmy je X), a logika uaktualniająca level gracza też powinna odpytywać X, a nie patrzeć na pasek postępu.

Musiałbym bym chyba podzielić tą funkcje na mniejsze i sensownie nazwać

Tu nad architekturą trzeba najpierw pomyśleć, nad tym, w jaki sposób funkcja się komunikuje z resztą aplikacji, bo tutaj coś szwankuje. No i wydaje się, że problem może nie być w tej jednej funkcji, tylko w całości.

Faktycznie o tym nie pomyślałem, że tutaj pasek postępu steruje levelem gracza, a nie na odwrót. Podzieliłem sobie projekt na małe kawałki i jeśli coś zrobię, a to działa to idę po prostu dalej.