Czy prefiksy typu i zakresu są wartościowymi konwencjami nazewnictwa?

Niedawno rozpoczynając swoją pierwszą pracę jako programista, byłem trochę zaskoczony, gdy dowiedziałem się, że nie muszę przestrzegać żadnych konwencji nazewnictwa w kodzie. Kod napisany przez grupy pracujące nad innymi, większymi projektami był zgodny z konwencjami nazewnictwa, ale ponieważ zostałem zaangażowany w pisanie nowej, samodzielnej aplikacji, miałem wrażenie, że nie miało to szczególnego znaczenia. To był ostatni z moich zmartwień, więc po prostu wziąłem istniejącą konwencję i pobiegłem z nią.

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

Ale czy to się opłaca? Trudno mi ocenić efekt netto, jaki wynikający z tego rodzaju nazewnictwa ma na zrozumienie i wykrywanie błędów, ale wizualnie wygląda to trochę brzydko. Dodatkowo, posiadanie każdej klasy i pliku w projekcie o nazwie cSomething wydaje się bardzo dziwne.

Nie mam złudzeń, że jest to zdecydowanie wielka sprawa w porównaniu do rzeczy, które robią oczywistą różnicę, takich jak stosowane algorytmy i architektury. Ale każda konwencja, która ma wpływ na każdą linię kodu, którą piszę, wydaje się warta poprawienia.

Jaka jest najbardziej elegancka i skuteczna konwencja nazewnictwa, jeśli w ogóle trzeba ją zastosować? Czy oznacza typ i / lub zakres?

Joel Spolsky napisał artykuł o tym, dlaczego notacja węgierska istnieje i do czego była przeznaczona, może pomóc odpowiedzieć na twoje pytanie.

Przedrostki, takie jak tbl dla tabeli bazy danych, int dla liczby całkowitej itp., Na ogół nie są przydatne - w takich przypadkach ustalenie, co jest kontekstem lub narzędziami programistycznymi, jest banalne. Coś w rodzaju imp dla pomiarów imperialnych i metryk jest o wiele bardziej sensowne, ponieważ w przeciwnym razie widać tylko, że są to liczby zmiennoprzecinkowe.

area = width * height

wygląda idealnie w porządku

impArea = metWidth * impHeight

od razu pokazuje, że coś jest nie tak.

Ja osobiście używam opisowych nazw zmiennych. $ number_of_items jest oczywiście liczbą całkowitą. $ input_file_handle, $ is_active i $ encrypted_password mają oczywiste typy zarówno pod względem typu danych językowych, jak i typu semantycznego.

To, co opisujesz, nazywa się notacją węgierską . Kiedyś było to uważane za najlepszą praktykę, ale obecnie jest ogólnie odrzucone.

Artykuł w Wikipedii zawiera sekcję dotyczącą jego zalet i wad.

Tak, prefiksy mogą być przydatne, ale mam kilka sugestii:

Jeśli cały zespół stosuje te same konwencje, stają się one znacznie bardziej przydatne. Korzystanie z nich na własną rękę jest mniej pomocne.

W silnie statycznych językach nie kopiuj tylko typu zmiennej. Np. „BSubscribe” to zła nazwa zmiennej boolowskiej w języku C # lub Java, ponieważ IDE już wie, jaki to typ. Z drugiej strony w C, która nie ma typu logicznego, byłaby to przydatna informacja.

W języku C # i Javie można rozważyć przedrostek wskazujący, że obiekt może być pusty. Lub że ciąg znaków został oznaczony kodem HTML. Lub że reprezentuje wyrażenie regularne lub instrukcję SQL. Lub że tablica została posortowana. Użyj swojej wyobraźni.

Zasadniczo chodzi o to, aby zadać sobie pytanie, co chcesz powiedzieć nazwa zmiennej, a to zależy w dużej mierze od domeny i języka, w którym pracujesz.

Istnieje kilka różnych „stylów” konwencji nazewnictwa i większość z nich ma pewną wartość, czyniąc kod zrozumiałym.

Najważniejsze jest, aby FAR: używać opisowych nazw zmiennych i funkcji. W twoim przykładzie z „suma”, „waga” i „wartość”, możesz chcieć nadać bardziej znaczące nazwy: „totalCost”, „lumberWeight”, „lumberValuePerOunce” (tutaj przyjmuję pewne założenia)

Uważam, że konwencje, takie jak wstawianie nazw zmiennych ze znakiem oznaczającym typ, są dość rozpraszające w większości współczesnych języków.

Większość programistów .NET stosuje się do Wytycznych projektowych firmy Microsoft ( http://msdn.microsoft.com/en-us/library/ms229042.aspx ), co jest dość podobne do Javy (główna różnica polega na tym, że Microsoft preferuje Pascal Case dla nazw członków, podczas gdy Java sprzyja skrzynce wielbłąda).

Poza tym powiedziałbym, że twoja próbka kodu jest znacznie mniej czytelna z powodu dodatkowego szumu, który dodałeś.

Uważam, że w większości przewodnik po stylu kodowania Google jest całkiem dobry. Ponieważ powiedziano ci, że możesz używać dowolnego stylu, który ci się podoba, myślę, że powinieneś zacząć od przejrzenia tego i wybrania go.

Prefiksowanie nazw zmiennych typami danych (szczególnie prymitywnymi typami danych) zwiększa szum wizualny, a także ryzyko, że w przeciwnym razie niewielka zmiana zmieni nazwę na „wielki wybuch”.

Jeśli chodzi o pierwszy punkt, czy „intStudentCount” jest naprawdę bardziej zrozumiałe niż np. „NumberOfStudents”? Czy „invoiceLineItems” nie byłby co najmniej tak pouczające jak „aobjItems”. (Typ danych powinien dotyczyć znaczenia danych w dziedzinie problemów, a nie reprezentacji niskiego poziomu).

Co do drugiego punktu, co się stanie, gdy np. Przedwczesny wybór int zostanie zastąpiony długim lub podwójnym? Co gorsza, co się stanie, gdy konkretna klasa zostanie przekształcona w interfejs z wieloma klasami implementującymi? Wszelkie praktyki, które zwiększają ciężar realistycznych scenariuszy utrzymania, wydają mi się wątpliwe.

Może to również zależeć od tego , dlaczego prefiksujesz nazwę, a nie tylko od tego, co ją poprzedza.

Na przykład używam 1-2 literowego prefiksu dla nazw formantów w formularzu. Nie dlatego, że nie wiem, czy kompilator z łatwością znajdzie odpowiednią klasę dla przycisku (na przykład), ale najpierw projektuję duże formularze, a następnie piszę większość kodu.

Posiadanie przedrostka bt dla przycisków ułatwia później znalezienie odpowiedniego przycisku, zamiast mieszania wielu nazwisk.

Nie używam jednak prefiksów do nazywania zmiennych, ani dla typu (co na ogół i tak nie jest tak przydatne), ani dla znaczenia, kontekstu lub jednostki (co jest oryginalnym założeniem notacji węgierskiej).

Moim zdaniem zależy to od języka i wielkości projektu. W rzeczywistości nigdy nie posunąłem się tak daleko, aby używać prefiksów typów we wszystkich moich zmiennych, ale chcesz nazwać je w jasny sposób.

W języku pisanym statycznie, takim jak ten, którego używasz, im wygodniej czuję się z systemem czcionek, tym mniej ważna staje się notacja węgierska. Tak więc w Javie lub C #, a zwłaszcza w Haskell, nawet nie pomyślałbym o dodaniu tych prefiksów, ponieważ twoje narzędzia mogą powiedzieć ci typ dowolnego wyrażenia i wychwycą większość błędów wynikających z niezrozumienia typu.

Przedrostki często mają sens dla obiektów, na przykład w formie, w której możesz mieć 20 pól tekstowych, które wywołują je wszystkie tbSomethingmają sens.

Jednak w większości nie uważam, że warto, szczególnie w przypadku rodzajów wartości.

Załóżmy na przykład, że:

short shortValue = 0;
//stuff happens

Kilka miesięcy później musisz to zmienić - krótki nie jest wystarczająco duży. Teraz masz:

int shortValue = 0;
//stuff happens

O ile nie zmienisz teraz również nazwy zmiennej (większe ryzyko złamania kodu niż zmiany typu w tym przypadku), masz teraz mylący kod.

Lepiej mieć nazwę, która opisuje, co zawiera:

int loopCounter = 0;
//stuff happens

Jeśli później trzeba zmienić na długi: nie ma problemu.

Być może jest więcej argumentów za tymi konwencjami w dynamicznie pisanych językach lub tych bez IDE.

Zawsze miałem skłonność do używania skrótu od 2 do 4 znaków dla typu przed samą zmienną. Czasami wydaje się to uciążliwe, ale gdy pracujesz ze złożonymi typami danych lub sytuacjami, staje się to korzystne. Myślę, że należy do dolnej kategorii wielbłądów.

Patrząc na powyższy przykład, można by go nieco zmienić:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Tablice zawsze mają przed znakiem typ oznaczający tablicę. Pozwala mi to również grupować podobne wystąpienia zmiennych. Na przykład mogę użyć ...

taStore.Fill(dtStore);

... co oznacza, że ​​mój Store TableAdapter wypełnia tabelę Data Store.

Zawsze starałem się przestrzegać podstawowej zasady, że prefiksy i / lub sufiksy powinny być wstawiane tylko wtedy, gdy kod jest bardziej czytelny (jak zwykły angielski).

Im mniej tajemniczy, tym lepiej ...

Po co stosować taką metodę:

public boolean connect( String h, int p );

Kiedy możesz mieć coś takiego:

public boolean connect( String hostName, int port );

Co więcej, dzisiejsze IDE mają naprawdę potężne narzędzie do refaktoryzacji zmiennych (szczególnie Java), nazw metod, klas itp. Pomysł, aby powiedzieć, że maksymalna informacja z najmniejszą ilością znaków jest po prostu staromodny.