Czy istnieje wymówka dla krótkich nazw zmiennych?

140

Stało się to wielką frustracją z bazą kodu, nad którą obecnie pracuję; wiele z naszych zmiennych jest krótkich i nieopisowych. Jestem jedynym programistą, który pozostał w projekcie i nie ma dokumentacji dotyczącej tego, co większość z nich robi, więc muszę poświęcić dodatkowy czas na śledzenie tego, co reprezentują.

Na przykład czytałem kod, który aktualizuje definicję powierzchni optycznej. Zmienne ustawione na początku były następujące:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

Może to tylko ja, ale w zasadzie nic nie powiedziałem o tym, co reprezentowali, co utrudniło zrozumienie kodu. Wiedziałem tylko, że gdzieś była to zmienna parsująca określony wiersz z określonej tabeli. Po kilku poszukiwaniach dowiedziałem się, co mieli na myśli:

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

Zmieniłem ich nazwy na to, co tam mam. Wydłuża niektóre linie, ale wydaje mi się, że to sprawiedliwy kompromis. Tego rodzaju schemat nazewnictwa jest jednak używany w wielu częściach kodu. Nie jestem pewien, czy to artefakt od programistów, którzy nauczyli się, pracując ze starszymi systemami, czy może kryje się za tym głębszy powód. Czy istnieje dobry powód, aby nazwać zmienne w ten sposób, czy też mam uzasadnienie, aby zaktualizować je do bardziej opisowych nazw, gdy je napotykam?

KChaloux
źródło
98
Wydaje mi się, że w tym konkretnym przypadku są to nazwy zmiennych skopiowane bezpośrednio z formuły matematycznej.
Dave Nay,
1
jedyną wymówką, którą przyjąłbym, byłoby „Mój rówieśnik powiedział, że po przejrzeniu kodu jest w porządku”
gnat
35
Jeśli nie możesz zrozumieć kodu matematycznego z powodu krótkich nazw zmiennych, pamiętaj, że przyczyną może być to, że nie rozumiesz matematyki, a nie dlatego, że nazwy są zbyt krótkie. Zmiana wyrażeń matematycznych, których nie rozumiesz, nie jest procesem o wysokiej niezawodności. Po zrozumieniu matematyki długość nazw zmiennych nie ma znaczenia. Wyświadcz innym przysługę i zostaw cytat (w komentarzu) do jakiegoś odpowiedniego opisu matematyki, jeśli musisz się tego nauczyć!
Rex Kerr
3
Dowolny identyfikator, który jest nazwany Donkey Kong jest zatwierdzony: dK = conic constant.
Thomas Eding,
8
I odwrotnie, można zapytać, czy nieznajomość dziedziny domeny uzasadnia ignorowanie jej konwencji. Ostatecznie zależy to od kontekstu.
Daniel C. Sobral

Odpowiedzi:

234

Wygląda na to, że te nazwy zmiennych oparte są na skrótach, których można się spodziewać w podręczniku do fizyki pracującym nad różnymi problemami optycznymi. Jest to jedna z sytuacji, w której krótkie nazwy zmiennych są często lepsze niż dłuższe nazwy zmiennych. Jeśli masz fizyków (lub ludzi, którzy są przyzwyczajeni do ręcznego opracowywania równań), którzy są przyzwyczajeni do używania typowych skrótów, takich jak Rin, Rout itp., Kod będzie znacznie wyraźniejszy przy tych skrótach niż przy dłuższych nazwach zmiennych. Ułatwia także porównywanie formuł z artykułów i podręczników z kodem, aby upewnić się, że kod właściwie wykonuje obliczenia poprawnie.

Każdy, kto zna się na optyce, natychmiast rozpozna coś w rodzaju Rin jako promień wewnętrzny (na papierze fizyki, inbędzie renderowany jako indeks dolny), Rout jako promień zewnętrzny itp. Chociaż prawie na pewno byłby w stanie coś mentalnie przetłumaczyć jak innerRadiusw bardziej znanej nomenklaturze, dzięki temu kod byłby mniej czytelny dla tej osoby. Utrudniłoby to dostrzeżenie przypadków, w których znana formuła została niepoprawnie zakodowana, a także trudniej byłoby przetłumaczyć równania w kodzie na i z równań, które znaleźliby w pracy lub podręczniku.

Jeśli jesteś jedyną osobą, która kiedykolwiek ogląda ten kod, nigdy nie musisz tłumaczyć między kodem a standardowym równaniem optyki, i jest mało prawdopodobne, że fizyk kiedykolwiek będzie musiał spojrzeć na kod w przyszłości, być może robi to warto zrefaktoryzować, ponieważ korzyści wynikające ze skrótów nie przewyższają już kosztów. Gdyby to był nowy rozwój, prawie na pewno rozsądne byłoby użycie tych samych skrótów w kodzie, które można znaleźć w literaturze.

Justin Cave
źródło
17
A jeśli nie ma fizyków ani matematyków wśród personelu? Kod został w zasadzie pozostawiony mi. Jest to w dużej mierze nieudokumentowane. Byłoby bardziej trudne do odczytania opisowych nazw?
KChaloux,
127
+1 Nie jest nierozsądne oczekiwać od programisty zrozumienia dziedziny, w której pracuje. Z drugiej strony, w pracach matematycznych zmienne są zwykle definiowane w dogodnym miejscu. W takim kodzie spodziewałbym się wyraźnego komentarza pokazującego długą formę.
Karl Bielefeldt,
15
+1: Mówisz w zasadzie, że programista, który rozumie domenę, w której pracują, zrozumie nazwy zmiennych. Tak samo będzie w wielu projektach, nawet przy dłuższych nazwach zmiennych. na przykład. zmienna nazwana columnw wojskowej grze strategicznej najprawdopodobniej oznacza coś innego niż w oprogramowaniu do tworzenia wykresów.
Steven Evers,
23
W programowaniu medycznym często znajdziesz terminy, które pozostają w sferze programowania. Na przykład w okulistyce zobaczysz OU, OD i OS. Oznaczają one, które oko, na przykład ouSphere, może odnosić się do elementu „kuli” recepty na prawe oko. Będziesz lepszym programistą, jeśli zrozumiesz domenę biznesową, dla której programujesz.
Bill
11
+1 za zauważenie krótkich nazw, które pasują do tych w równaniach i formułach z artykułów i tekstów. Kiedy to robię, dołączam komentarze na temat tego, gdzie znaleźć oryginalny materiał referencyjny.
Jay Elston,
89

Zmienne o krótkim okresie istnienia powinny zostać wkrótce nazwane. Jako przykład nie piszesz for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Zamiast tego używasz for(int i ....

Zasadniczo można powiedzieć, że im krótszy zakres zmiennej, tym krótsza powinna być nazwa. Liczniki pętli są często jedynie pojedyncze litery, powiedzmy i, ji k. Zmienne lokalne są coś baseOr fromi to. Na przykład zmienne globalne są nieco bardziej rozbudowane EntityTablePointer.

Być może taka zasada nie jest przestrzegana w bazie danych, z którą pracujesz. Jest to jednak dobry powód, aby dokonać refaktoryzacji!

zxcdw
źródło
14
i, j i k dla indeksów tablicowych reprezentują tradycję sięgającą przynajmniej Fortranu. Każdy szanujący się programista zapozna się z tą konwencją.
Dominic Cronin,
7
Ja zwykle nie piszę i, j, k, piszę coś takiego personPos, bo wtedy nie zapomnę co mi powtarzanie i co indeks reprezentuje.
Malcolm,
18
-1, używam długich nazw do iteracji indeksu tablicy, ale nadaję im sensowną nazwę zamiast oczywistej i pozbawionej znaczenia arrayCounter . Sprawia, że ​​kod jest łatwiejszy do odczytania, a przynajmniej chroni cię przed tupaniem po zewnętrznym liczniku, gdy kopiujesz / wklejasz kolejną pętlę wewnątrz tego.
Oleg V. Volkov
3
counter jest rzeczownikiem lub przymiotnikiem. Count to rzeczownik lub czasownik. Oczywiście, nadal nie nazwać coś arrayCounter, bym użyć personIndexlub rowczy cokolwiek opisane co patrzę.
Wayne Werner
6
Kiedy robię pojedynczą pętlę, używam i. Ale gdy tylko przejdę do zagnieżdżonej pętli, upuszczam inomenklaturę. Powodem tego jest to, że naprawdę chcę śledzić, która zmienna pętli jest przetwarzana, a ivs jmoże być dość mylące w gęstym kodzie. Uczynienie go bardziej czytelnym i dodanie większej ilości białych znaków jest z natury rzeczy konieczne.
jcolebrand
48

Problemem w kodzie nie są krótkie nazwy, ale raczej brak komentarza, który wyjaśniłby skróty lub wskazał kilka pomocnych materiałów na temat wzorów, z których pochodzą zmienne.

Kod po prostu zakłada znajomość domeny problemowej.

To dobrze, ponieważ znajomość problematyczna jest prawdopodobnie wymagana do zrozumienia i utrzymania kodu, szczególnie w roli osoby, która go „posiada”, więc to Ty musisz przyswoić sobie znajomość, a nie obchodzić przedłużające się nazwy.

Byłoby jednak miło, gdyby kod zawierał pewne wskazówki, które mogłyby służyć jako trampoliny. Nawet ekspert w dziedzinie może zapomnieć, że dKto stała stożkowa. Dodanie małego „ściągawki” w bloku komentarza nie zaszkodzi.

Kaz
źródło
Ostatecznie skończyło się na czymś takim.
KChaloux
5
To jest źle. Nie ma powodu, aby kod był trudny do odczytania, aby zmusić ludzi do poświęcenia więcej czasu na jego „naukę”. Nie uczysz, tylko spowalniasz ludzi. Poza tym praktycznie nigdy nie ma ani jednego właściciela kodu na zawsze. Jesteś krótkowzroczny i samolubny.
xaxxon
7
To twoja interpretacja jest błędna, a nie odpowiedź. Kod implementuje pewną matematykę, która istnieje poza tym kodem i niezależnie od niego, i która pojawiła się przed kodem. Zachowanie tego samego nazewnictwa jest pomocne. Ktoś, kto utrzymuje kod, prawdopodobnie będzie musiał przestudiować tę matematykę bez konieczności mapowania między dwoma schematami nazewnictwa.
Kaz
19

W przypadku niektórych zmiennych, które są dobrze znane w dziedzinie problemowej - tak jak w tym przypadku - krótkie nazwy zmiennych są rozsądne. Jeśli pracuję nad grą, chcę, aby moje elementy gry miały zmienne pozycji, xa ynie horizontalPositioni verticalPosition. Podobnie liczniki pętli, które nie mają żadnych semantykę poza indeksowania, spodziewam się, aby zobaczyć i, j, k.

Russell Borogove
źródło
Twierdziłbym, że cv, din i dout nie są od razu oczywiste (chociaż najwyraźniej są one ustalone w określonych dziedzinach). Nie kłóciłbym się o xiy, ponieważ współrzędne kartezjańskie mają zastosowanie do dowolnej liczby dziedzin i są nauczane dla wszystkich w gimnazjum i liceum.
KChaloux
1
A xi y, podczas gdy powszechne, nie posiadają ukrytych ważnych aspektów, takich jak gdzie pochodzenie w.
Ross Patterson
3
@RossPatterson: istnieje jednak wiele kontekstów, w których to po prostu nie jest ważne. Rozważmy na przykład pętlę, na przykład for (x,y) in list_of_coordinates: print x,y: Pochodzenie nie ma szczególnego znaczenia przy próbie zrozumienia kodu.
Bryan Oakley,
16

Zgodnie z „Clean Code”:

Nazwy zmiennych powinny:

  • Bądź odkrywczy
  • Unikaj dezinformacji
  • Zrób znaczące rozróżnienia
  • Bądź wymowny
  • Możliwość wyszukiwania

Wyjątek stanowią przysłowia i,j,k,m,nużywane w pętlach.

Zmienna nazywa cię, na co słusznie narzekasz, nie rób nic z powyższych. Te imiona to złe imiona.

Ponieważ każda metoda musi być krótka , używanie prefiksów wskazujących, że zakres lub typ nie jest już używany.

Te imiona są lepsze:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

Komentator mówi, że byłoby to zbyt skomplikowane w przypadku długich nazw zmiennych:

wprowadź opis zdjęcia tutaj

Krótkie nazwy zmiennych również nie ułatwiają:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

Odpowiedź to długie nazwy i wyniki pośrednie, dopóki nie otrzymasz tego na końcu:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;
wersje user61852
źródło
26
Zmienne te są prawdopodobnie używane we wzorach matematycznych w kodzie. Wzory matematyczne są znacznie łatwiejsze do odczytania przy użyciu krótkich nazw zmiennych. Używam długich nazw zmiennych w większości mojego kodu, ale matematyka jest lepsza w przypadku krótkich nazw zmiennych. Przypadkowy przykład: zastanów się, jak długo potrwa to z długimi nazwami zmiennych.
MarkJ
@MarkJ Masz rację.
Tulains Córdova
1
Wyniki pośrednie mają tę dodatkową zaletę, że zmniejszają i izolują błędy programowania. Nasz mózg może przetwarzać tylko tyle informacji na raz i ciężko jest dostrzec błąd w czymś takimfnZR = (r^2/fnR(1+Math.sqrt((1+k)) * (r^2/R^2))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;
powiek
1
To nie jest takie trudne, jeśli to twój chleb i masło.
Radu,
1
Nie chodzi o to, aby napisać jeden wiersz. Ale problemem jest to, że jeśli chcesz coś zmienić i wykorzystać inną formułę teraz masz problem gdzie to zajmuje dużo czasu, aby dowiedzieć się, które w podręczniku dotyczy. Używaj pośrednich wyników, ale trzymaj swoje skomplikowane matematyki jak najbliżej problematycznej domeny, abyś mógł ją utrzymać, jeśli chcesz dodać funkcję. long_nameR
slebetman
8

Istnieją dwa powody, dla których nie należy zmieniać nazw zmiennych w starszym kodzie.

(1) chyba że korzystasz z automatycznego narzędzia do refaktoryzacji, możliwość wprowadzenia błędów jest wysoka. Dlatego „jeśli nie jest zepsuty, nie naprawiaj go”

(2) sprawisz, że porównywanie bieżących wersji z poprzednimi wersjami, aby zobaczyć, co się zmieniło, niemożliwe. Utrudni to w przyszłości utrzymanie kodu.

ddyer
źródło
7
Absolutnie słuszne, ale ryzyko braku zrozumienia jest znacznie większe.
Ross Patterson
2
Masz znacznie większe problemy, jeśli twoje narzędzia nie są w stanie poradzić sobie z prostymi problemami, takimi jak te, o których wspomniałeś.
AndSoYouCode
Odpowiedzi (1) Rozsądny zakres automatycznych testów i rozsądne kapsułkowanie, (2) Biegłość w kontroli wersji.
Adamantish
5

Czy istnieje dobry powód, aby nazwać zmienne w ten sposób, czy też mam uzasadnienie, aby aktualizować je do bardziej opisowych nazw, gdy się z nimi spotykam?

Powodem używania mniejszych nazw jest to, że oryginalny programista uważa, że ​​łatwiej z nimi pracować. Przypuszczalnie mają oni prawo do stwierdzenia, że ​​tak jest, i prawo do nie posiadania tych samych osobistych preferencji, co ty. Osobiście znajdę ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... gdybym używał ich w długich, skomplikowanych obliczeniach. Im mniejsze wyrażenie matematyczne, tym częściej łatwiej jest zobaczyć całość na raz. Chociaż gdyby tak było, mogą być lepsze niż dIn i dOut, więc nie było powtarzającego się D, który mógłby prowadzić do łatwej literówki.

Z drugiej strony, jeśli trudniej ci będzie pracować, powal się i zmień nazwę na dłuższą. Zwłaszcza jeśli jesteś odpowiedzialny za ten kod.

Grandmaster B.
źródło
7
Przynajmniej pozbywam się notacji węgierskiej Systemów ...
KChaloux,
4
Wiodącym djest Węgier? Myślałem, że to rachunek różniczkowy jak w dx^2/dx = 2x.
Shannon Severance
7
Gdybym sam to widział dDinnerAperture, przeczytałbym to jako „Przysłona obiadowa” i zastanawiałem się, czy to tylko zabawny sposób powiedzenia „twoje usta”. Nigdy nie był fanem stylu „wielka litera, po której następuje małe litery”. Czasami bardzo mylące.
Darrel Hoffman,
2
+1 to jest odpowiedź. Długie formuły matematyczne są znacznie łatwiejsze do odczytania przy użyciu krótkich nazw zmiennych. Zmienne te są prawdopodobnie używane we wzorach matematycznych w kodzie. Wzory matematyczne są znacznie łatwiejsze do odczytania przy użyciu krótkich nazw zmiennych. Używam długich nazw zmiennych w większości mojego kodu, ale matematyka jest lepsza w przypadku krótkich nazw zmiennych. Przypadkowy przykład: zastanów się, jak długo potrwa to z długimi nazwami zmiennych.
MarkJ
1
@ShannonSeverance Zgadzam się z tobą. Pochodząc z inżynierii, d powinien zdecydowanie być zarezerwowany dla rachunku różniczkowego, gdy używa się nazw zmiennych w sensie matematycznym (jak często tu wspomniano).
CodeMonkey
4

Generalnie uważam, że regułą tego powinno być stosowanie wyjątkowo krótkich nazw zmiennych, gdy wiesz, że ludzie, którzy są „specjalistami w dziedzinie” twojego konkretnego kodu, natychmiast zrozumieją odniesienie do tej nazwy zmiennej. (W każdym razie zawsze masz komentarze z wyjątkiem tego przypadku) i że zlokalizowane użycie zmiennych można łatwo rozpoznać na podstawie kontekstu ich użycia.

Aby to rozwinąć, oznacza to, że nie powinieneś starać się zaciemniać nazw zmiennych, ale możesz używać skrótów w nazwach zmiennych, ponieważ wiesz, że prawdopodobne jest, że tylko ludzie, którzy rozumieją podstawową koncepcję kodu i tak to przeczytać.

Aby użyć przykładu ze świata rzeczywistego, ostatnio stworzyłem klasę Javascript, która zajmowałaby pewną szerokość geograficzną i mówiła o ilości światła słonecznego, jakiej można oczekiwać w danym dniu.

Aby stworzyć tę klasę Sundial , wspomniałem może o pół tuzina zasobów, Almanachu Astronomii i fragmentach z innych języków (PHP, Java, C itp.).

W prawie wszystkich zastosowali podobne identyczne skróty, co na pierwszy rzut oka nic nie znaczy.

K, T, EPS, deltaPsi, eot, LM,RA

Jeśli jednak posiadasz wiedzę z zakresu fizyki, możesz zrozumieć, czym one były. Nie spodziewałbym się, że ktoś dotknie tego kodu, więc po co używać pełnych nazw zmiennych?

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

Ponadto przez większość czasu, gdy nazwy zmiennych są przejściowe, to znaczy, są one używane tylko do tymczasowego przydzielenia pewnej wartości, wtedy często nie ma sensu używać pełnej wersji, szczególnie gdy kontekst zmiennej wyjaśnia, że ​​jest to cel.

Laykes
źródło
1

Jest absolutnie; często wystarczy krótka nazwa zmiennej.

W moim przypadku prowadzę nawigację po punktach orientacyjnych w mojej starszej klasie robotyki i programujemy nasze roboty w KISS-C. Potrzebujemy zmiennych dla aktualnych i docelowych (x, y) współrzędnych, (x, y) odległości, bieżących i docelowych pozycji, a także kątów skrętu.

Szczególnie w przypadku współrzędnych xiy długa nazwa zmiennej jest całkowicie niepotrzebna, a nazwy takie jak xC (bieżący x), yD (docelowy y) i pD (docelowy phi) są wystarczające i są najłatwiejsze do zrozumienia w tym przypadku.

Możesz argumentować, że nie są to „opisowe nazwy zmiennych”, jak nakazałby protokół programisty, ale ponieważ nazwy oparte są na prostym kodzie (d = miejsce docelowe, c = bieżące), bardzo prosty komentarz na początku jest całym opisem oni wymagają.

George Gorski
źródło
0

Czy istnieje dobry powód, aby nazwać zmienne w ten sposób, czy też mam uzasadnienie, aby aktualizować je do bardziej opisowych nazw, gdy się z nimi spotykam?

Zwykle złożone algorytmy są implementowane w matlabie (lub podobnym języku). To, co widziałem, to ludzie po prostu przejmujący nazwę zmiennych. W ten sposób można łatwo porównać implementacje.

Wszystkie pozostałe odpowiedzi są prawie poprawne. Skróty te można znaleźć w matematyce i fizyce, z tym że nie zaczynają się d(jak w twoim przykładzie). Zmienne zaczynające się na d są zwykle nazywane w celu reprezentowania różnicowania .

Wszystkie normalne przewodniki kodowania mówią, aby nie nazywać zmiennych pierwszą literą reprezentującą typ (jak w twoim przypadku), ponieważ tak łatwo jest przeglądać kod we wszystkich nowoczesnych IDE.

BЈовић
źródło
Racja, ten element zanikał bez względu na to, co ludzie powiedzieli. W bazie kodu dzieje się coś w rodzaju pół-węgierskiej, w połowie nie-schizofrenii, którą aktualizuję, gdy ją znajduję.
KChaloux
0

Mogę wymyślić, dlaczego nazwy zmiennych są dość krótkie.

Krótkie nazwy są łatwe do odczytania dzięki krótszemu zasięgowi oczu, stąd krótki okres uwagi.

Na przykład po przyzwyczajeniu się do faktu, że svdb oznacza „zapisz w bazie danych”, szybkość skanowania kodu źródłowego staje się lepsza, ponieważ muszę tylko szybko skanować 4 znaki zamiast czytać SaveToDatabase (14 znaków, sytuacja się pogarsza dla bardziej złożonych nazw operacji). Mówię „skanowanie”, a nie „czytanie”, ponieważ zajmuje to większą część analizy kodu źródłowego.

Podczas skanowania dużej ilości kodu źródłowego może to zapewnić dobry wzrost wydajności.

Pomaga też leniwemu programistowi wpisywać te krótkie nazwy podczas pisania kodu.

Oczywiście, wszystkie te „skróty” powinny być wymienione w jakiejś standardowej lokalizacji w kodzie źródłowym.

Amol
źródło
1
Nie odczytujemy słów jako zestawu znaków, odczytujemy je jako kształty i warunkowo rozwiązujemy szczegóły, gdy zrozumienie na pierwszy rzut oka nie powiedzie się. Długość słowa, którą musi czytać dłużej, jest znacznie większa niż 4 znaki, a my jesteśmy w stanie przetworzyć w myślach camelCase i inne sposoby rozbijania słów nazw zmiennych jako granic wyrazów. Wątpię, by test czytania wykazał, że krótsze nazwy poprawiają szybkość czytania ze zrozumieniem; zamiast tego, poprzez usunięcie rozpoznawalnych słów, prędkość będzie zmniejszana, dopóki nowe słowa nie zostaną zasymilowane (o czym sam wspominasz).
powiek
0

Aby sformułować to, co @zxcdw powiedział nieco inaczej, i rozwinąć je pod względem podejścia:

Funkcje powinny być czyste , zwięzłe i idealnie obejmować niektóre funkcje: logika czarnej skrzynki , niezależnie od tego, czy siedziała nietknięta od 40 lat, nadal będzie wykonywać zadanie, do którego została zaprojektowana, ponieważ jej interfejs ( wejście i wyjście) brzmi dobrze, nawet jeśli nic nie wiadomo o jego wnętrznościach.

Jest to rodzaj kodu, który chcesz napisać: jest to kod, który trwa i jest łatwy do przeniesienia.

W razie potrzeby komponuj funkcje z innych wywołań funkcji (wstawianych) , aby zachować dokładność kodu.

Teraz, dzięki odpowiednio opisowej nazwie funkcji (w razie potrzeby szczegółowej!), Minimalizujemy ryzyko błędnej interpretacji skróconych nazw zmiennych, ponieważ zakres jest tak mały.

Arcane Engineer
źródło
-1

Nazwy zmiennych powinny być jak najbardziej opisowe, aby zwiększyć czytelność programu. Sam tego doświadczyłeś: miałeś dużo problemów z identyfikacją tego, co zrobił program z powodu złego nazewnictwa.

Nie ma dobrego powodu, aby nie używać nazwy opisowej. Pomoże ci i wszystkim innym, którzy pracują / będą pracować nad projektem. Cóż, w rzeczywistości istnieje jedno prawidłowe użycie krótkich nazw: liczniki pętli.

marco-fiset
źródło
6
Zauważ, że int dummy_variable_for_for_loops;jest jak najbardziej opisowy.
Kaz
4
-1, ponieważ ta odpowiedź jest myląca. Najpierw mówi, że nie ma dobrych powodów, a potem kończy, mówiąc, że tak naprawdę jest. Odpowiedź byłaby lepsza, gdyby została przeformułowana tak, aby nie zaprzeczać samej sobie.
Bryan Oakley
Zmieniłbym to na „tak opisowy, jak to konieczne ”. Jeśli krótka nazwa przekazuje cel zmiennej, wówczas można użyć krótkiej nazwy .
Maximus Minimus,
-1

Na pewno po to są // komentarze?

Jeśli zadania mają opisowe komentarze, otrzymujesz to, co najlepsze z obu światów: opis zmiennej i wszelkie równania są łatwo porównywalne z ich odpowiednikiem z podręcznika.

Richie
źródło
-1

W przypadku interfejsów (np. Podpisów metod, podpisów funkcji) staram się to rozwiązywać, opisując deklaracje parametrów. W przypadku C / C ++ dekoruje on plik .h, a także kod implementacji.

Robię to samo dla deklaracji zmiennych, gdzie znajomość użycia zmiennej nie jest oczywista w kontekście i nazewnictwie. (Dotyczy to także języków, które nie mają silnego pisania).

Jest wiele rzeczy, których nie chcemy zatkać nazwy zmiennej. Czy kąt w radianach lub stopniach, czy istnieje pewna tolerancja dla precyzji lub zasięgu itp. Informacje te mogą dostarczyć cennych twierdzeń na temat cech, z którymi należy odpowiednio sobie radzić.

Nie jestem z tego powodu religijny. Interesuje mnie po prostu przejrzystość i upewnienie się, że teraz jestem tym, co następnym razem moje zapomniane ja odwiedzi kod. A każdy, kto patrzy przez ramię, ma to, co musi wiedzieć, aby zobaczyć, gdzie coś jest nie tak, co jest niezbędne (ostatnie ważne dla właściwej konserwacji).

orcmid
źródło
-1

Czy istnieje wymówka dla zbyt krótkich nazw zmiennych?

Po pierwsze: Nazywanie zmiennej dla energii e podczas obliczania wzorów takich jak E = MC2 NIE jest nazbyt krótkim nazewnictwem. Użycie symboli jako argumentu dla krótkich nazw jest nieprawidłowe

To pytanie było dla mnie dość interesujące i mogę wymyślić tylko jedną wymówkę, a mianowicie pieniądze.

Załóżmy na przykład, że instalujesz javascript dla klienta, który wie, że plik ma zostać pobrany wiele razy na sekundę. Byłoby to tańsze i poprawiłoby wrażenia użytkowników, gdyby plik (w liczbie bajtów) był jak najmniejszy.

(Aby zachować przykład „realistyczności”, nie wolno ci używać narzędzia minifikatora, dlaczego? Problemy bezpieczeństwa, żadne zewnętrzne narzędzia nie mogą dotykać podstawy kodu).

AlexanderBrevig
źródło
1
Twój przykład wciąż nie jest zbyt realistyczny.
Radu,
-1

Zauważam, że inne odpowiedzi nie wspominają o użyciu notacji węgierskiej. Jest to ortogonalne dla debaty długościowej, ale ogólnie dotyczy schematów nazewnictwa.

double dR, dCV, dK, dDin, dDout, dRin, dRout

Litera „d” na początku wszystkich tych zmiennych ma oznaczać, że są one podwójne; ale język i tak to wymusza. Pomimo zwięzłości tych nazw, są nawet o 50% zbędne !

Jeśli zamierzamy zastosować konwencję nazewnictwa w celu zmniejszenia liczby błędów, znacznie lepiej kodujemy informacje, które nie są sprawdzane przez język. Na przykład żaden język nie będzie narzekał dK + dRw powyższym kodzie, nawet jeśli dodawanie liczby bezwymiarowej do długości jest bez znaczenia.

Dobrym sposobem zapobiegania takim błędom jest użycie silniejszych typów; jeśli jednak będziemy używać podwójnych, bardziej odpowiednim schematem nazewnictwa może być:

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

Język nadal pozwoli nam pisać K + lR, ale teraz nazwy dają nam podpowiedź, że może to być niepoprawne.

Jest to różnica między systemami węgierskimi (ogólnie źle) a aplikacjami węgierskimi (być może dobrym)

http://en.wikipedia.org/wiki/Hungarian_notation

Warbo
źródło
1
W rzeczywistości C ++ może narzekać, K + lR jeśli prawidłowo zadeklarujesz swoje jednostki. Dzięki jednostkom SI może przeprowadzać kontrole wymiarów i konwersję jednostek. Dodawanie nie 3_feet + 2_meterpowinno stanowić problemu, a 2_meter+1_secondbłąd kompilacji.
MSalters
@MSalters To całkiem fajne; podejście do szablonu / makra nie przyszło mi do głowy. Mimo to w pytaniu „niezależnym od języka” zgrupowałem wszystkie kontrole jednostek czasu kompilacji pod parasolem „silniejszych typów”, niezależnie od tego, czy język nazywa je „typami”, czy nie;)
Warbo,
Szablon koniecznie. Nie można wykonać niezbędnego rachunku typu w makrach.
MSalters
-2

Jedyny przypadek, w którym nieczytelnie krótkie nazwy zmiennych są dopuszczalne w nowoczesnej inżynierii oprogramowania jest, gdy występują one w skrypcie i przepustowość tego skryptu (przez sieć ogólnie) jest bardzo ważne. Nawet wtedy trzymaj skrypt z długimi nazwami pod kontrolą źródła i zminimalizuj skrypt w trakcie produkcji.

Telastyn
źródło
9
Co powiesz na wykonywanie operacji matematycznych, w których terminy są uważane za powszechnie znane w dziedzinie? Przykład: użycie M zamiast „masy” w e = mc ^ 2
Andy Hunt
2
@andyBursh - Będę tam ostrożny. Programiści nie są często ekspertami (ani nawet kompetentnymi) w swojej dziedzinie problemowej. To powiedziawszy, tego rodzaju rzeczy mogą być w porządku, szczególnie jeśli istnieje odpowiedni komentarz do odnośnej formuły; Zapomniałem o tym scenariuszu.
Telastyn,
8
@Telastyn - Jeśli zakładasz, że programista nie jest ekspertem, często prowadzi to do używania skrótów o bardzo dobrze zdefiniowanym znaczeniu i przekształcania ich w dłuższe nazwy, które są co najmniej nieco niejednoznaczne (tj. Ktoś decyduje się nazwać zmienną lokalną radiusgdy przechowuje wewnętrzny promień, nie rozumiejąc, że jest to o wiele bardziej dwuznaczne niż Rin). Następnie programista niebędący ekspertem musi tłumaczyć między swoją unikalną nomenklaturą a nomenklaturą, którą firma rozumie za każdym razem, gdy pojawia się dyskusja z udziałem równań.
Justin Cave
2
Co z „i” dla licznika pętli? Lub „x” i „y” w przypadku współrzędnych? Lub zmienna, której zasięg to tylko dwa wiersze kodu?
Bryan Oakley
4
Nie zgadzam się z tą odpowiedzią. Programista pracujący nad programem zawierającym złożone wyrażenia matematyczne lepiej byłby w stanie odczytać formuły ze specyfikacji, w przeciwnym razie nie byłby kompetentny. To nie jest wiedza problemowa, to podstawowa umiejętność - niektóre podstawowe kompetencje matematyczne przed pracą nad programem matematycznym. Jeśli programista nie ma dostępu do formuł specyfikacji, to kolejny problem - i nie można go rozwiązać za pomocą samych komentarzy.
MarkJ