Jaki jest powód używania małych liter dla pierwszego słowa w zmiennej lokalnej (np. WorkerCount, firstName)


20

Dużo krytykuję ze strony innych programistów ze względu na to, że wykorzystuję pełną odpowiednią obudowę dla wszystkich moich zmiennych. Na przykład typowy programista użyje employeeCountnazwy zmiennej, ale ja jej używam EmployeeCount. Używam pełnej właściwej obudowy do wszystkiego , czy to metoda void, metoda return, zmienna, właściwość lub stała. Nawet przestrzegam tej konwencji w Javascript. Ten ostatni naprawdę szelestuje żarty ludzi.

Typowym powodem, dla którego nie powinienem stosować się do tej „niestandardowej” konwencji dotyczącej obudów, jest to, że pełny właściwy przypadek powinien być zarezerwowany dla właściwości i metod void. Zmienna lokalna i metody zwracające wartość powinny mieć pierwsze słowo pisane małymi literami int employeeCount = getEmployeeCount().

Nie rozumiem jednak dlaczego.

Kiedy zadaję to pytanie, wydaje się, że po prostu otrzymuję arbitralną odpowiedź na to pytanie . Jakakolwiek jest odpowiedź, zwykle zawsze sprowadza się do Tak po prostu jest i nie kwestionuję tego. Po prostu podążam za tym. . Arbitralne odpowiedzi nigdy nie są dla mnie wystarczająco dobre.

Od samego początku programowania makr Excel 97 za pomocą Office IDE, nigdy nie potrzebowałem konwencji casing, aby powiedzieć mi, czy coś jest lokalną zmienną lub właściwością. Jest tak, ponieważ zawsze stosowałem bardzo intuicyjną konwencję nazewnictwa. Na przykład GetNuggetCount()wyraźnie sugeruje metodę, która gdzieś idzie i pobiera liczbę wszystkich samorodków. SetNuggetCount(x)sugeruje, że przypisujesz nową wartość do liczby bryłek. NuggetCountwszystko samo w sobie sugeruje właściwość lub zmienną lokalną, która po prostu przechowuje wartość. Do tego ostatniego można pokusić się o powiedzenie: „Ach ha! To jest pytanie. Własność lub zmienna? CO TO JEST?” Na to odpowiedziałbym: „Czy to naprawdę ma znaczenie?”

Oto tl; dr ;: Jakie są obiektywne, logiczne, nieobowiązkowe powody, aby używać małych liter dla pierwszego słowa w zmiennej lub w metodzie zwracanej?

Edycja: dla MainMa

Zamień ten kod na pierwszy przykładowy kod w odpowiedzi i sprawdź, jak dobrze utrzymuje się Twój argument:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

7
Gdyby byli wielkimi literami, ktoś inny
zapytałby,

11
czy nie byłoby miło, gdyby nasze wszechmocne IDE mogły mieć wtyczkę, która odwzorowała nasze osobiste preferencje dotyczące problemów stylistycznych takich jak ta i pozwoliła nam na ich użycie poza sceną, do zastosowania „prawdziwej wersji” pliku źródłowego semantyka stylu „projektu”. Jest to kwestia całkowicie wizualna, dopóki nie trzeba kontrolować oficjalnej wersji pliku. tylko marzę ...
Sassafras_wot

59
Na nieszczęście dla ciebie faktycznym i ważnym powodem jest „ponieważ jest to standard”. Ludzie w tym samym zespole opłaca się stosować ten sam standard stylu kodu. Jeśli nie rozumiesz dlaczego, to może powinieneś zadać kolejne pytanie: „dlaczego standardy są przydatne?”
Andres F.,

3
Zawsze zakładałem, że programiści zdecydowali się na camelCase, ponieważ wyglądało to na kewl. Nad pascalCase nie ma „obiektywnego” powodu dla samego camelCase . Osobiście uważam, że PascalCase (podobnie jak twój przykład) jest o wiele łatwiejszy do odczytania i używam go w większości miejsc innych niż JavaScript, gdzie trzymam się camelCase, więc nie przegapię zaproszeń na przyjęcie.
GrandmasterB

7
Badanie zalet posiadania standardowego stylu kodowania Tak naprawdę nie ma znaczenia, jaki jest standard, tylko przestrzeganie go.
Mr.Mindor,

Odpowiedzi:


88

Ta konwencja nazewnictwa jest często stosowana, gdy ludzie chcą mieć możliwość nadania zmiennej tej samej nazwy co jej typ. Na przykład:

Employee employee;

Niektóre języki wymuszają nawet stosowanie wielkich liter. Zapobiega to konieczności korzystania irytujących nazwy zmiennych takich jak MyEmployee, CurrentEmployee, EmployeeVar, itd. Zawsze można powiedzieć, czy coś jest rodzajem lub zmienna, tylko z liter. Zapobiega to pomyłkom w sytuacjach takich jak:

employee.function(); // instance method
Employee.function(); // static method

Ponadto w języku angielskim rzeczowniki zazwyczaj nie są pisane dużymi literami, więc nie można tak naprawdę twierdzić, że wielkość liter jest „odpowiednia”.

Co to ma wspólnego z twoją sytuacją? Oczywiście nie masz problemów z odczytaniem własnego kodu, ale utrzymując spójność w możliwie największym stopniu, zmniejszasz obciążenie umysłowe wszystkich osób, które muszą czytać Twój kod. W kodowaniu jak w piśmie dostosowujesz swój styl do czytelników.


1
Zauważ, że problem nadal występuje w języku używanym przez OP, ponieważ właściwości są pisane wielkimi literami (oczywiście właściwości mogą być poprzedzone znakiem this., co pozwala uniknąć zamieszania; zmienne lokalne nie mogą mieć takiego prefiksu).
Arseni Mourzenko

1
@oscilatingcretin nazywa się PascalCase.
Mr.Mindor,

21
Employee Employeedziała, ale będę argumentować, że jest to bardziej mylące dla ludzkiego czytelnika niż Employee employee. Ta ostatnia wygląda jak dwie różne rzeczy. Pierwszy wygląda jak niepotrzebne powtórzenie.
Jamie F,

14
@oscilatingcretin Dokładnie: „zakłada, że ​​czytelnik rozumie podstawową strukturę ...” Lubię czytać JavaScript, Java, C #, C ++ i inne i tłumaczyć kod w mojej głowie. Nie lubię ciągle myśleć: „Och, kompilator tego języka poradzi sobie z x ”. podczas gdy ja tylko próbuję zrozumieć znaczenie kodu.
Jamie F,

1
Zauważ, że employee.function()może to być również metoda statyczna, jeśli język pozwala na wywoływanie metod statycznych z obiektu (podobnie jak Java). Kompilator daje ostrzeżenie, ale można to zrobić.
Uooo

34

Nie ma żadnych To właśnie robi większość ludzi, więc stało się standardem, ponieważ wszyscy tak robią. Wiele literatury jest zgodne z tą konwencją, więc ludzie nabrali nawyku.

Konwencja nie jest tak ważna jak spójność w całym kodzie. Tak długo, jak wszystko jest nazwane w spójny sposób, dzięki czemu mogę stwierdzić, na co patrzymy, nie ma znaczenia, czy pierwsza litera jest pisana wielką literą, czy nie.

Uważam, że nieprzyjemnie jest napotkać kod napisany na twój sposób i powiedziałbym, że mi się nie podoba. Ale to kwestia stylu.

Teraz, jeśli robisz to w miejscu pracy, lepiej byłoby kodować w stylu zespołu, aby kod był spójny wszędzie. Zamiast mieć inny kod niż każdy inny.

http://thecodelesscode.com/case/94


3
Chciałbym, żeby większość programistów była taka jak ty. Wielu jest wątpliwych i / lub dogmatycznych w przestrzeganiu wspomnianego standardu dotyczącego obudów.
oscilatingcretin

1
@ Schieis ma znaczenie, jeśli jesteś kolejnym programistą, który będzie pracował nad projektem.
N4TKD,

3
@oscilatingcretin Możesz skończyć z pasją i / lub dogmatyką, gdy będziesz pracował nad kodem pełnym var m_someVariableID = GetVariableValueId(). Zwłaszcza jeśli musisz to zrobić bez obsługi autouzupełniania.
Tacroy,

7
Jeśli jesteś w drużynie, przestrzeganie tego standardu drużyn jest ważne. Należy jednak pamiętać, że wiele języków programowania ma de facto standardy, których należy przestrzegać, tworząc nowy projekt, w którym zespół nie ma standardów (lub w którym zespół odroczył się, aby je ustanowić). Jeśli nie masz pewności, jakiej konwencji kodowania użyć, postępuj zgodnie z konwencją stosowaną przez dostawcę języka pierwotnego lub dołączoną platformę zamiast własnego standardu, chyba że możesz uzasadnić swój standard.
Brian

2
@Schleis dobra aktualizacja, nie zgadzam się, że to tylko kwestia stylu, ale konwencja i konwencja stają się konwencją z dobrych powodów i należy ich przestrzegać. To nie jest religia i od jakiegoś czasu musisz bardzo z konwencji, ale powinieneś mieć dobry powód.
N4TKD

25

1. Dlaczego standard istnieje?

Czyż nie byłoby lepiej pozwolić wszystkim pisać kod zgodnie z osobistymi preferencjami i przestać mówić o tym, który standard jest lepszy?

Faktem jest, że kiedy jesteś przyzwyczajony do jednego stylu, trudniej jest odczytać kod, który używa innego stylu. Twój mózg spędza więcej czasu próbując zrozumieć konwencję (jeśli istnieje), zamiast zrozumieć, co robi kod.

Co jest bardziej czytelne między tymi dwoma fragmentami kodu?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

lub:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Oba fragmenty kodu działają podobnie. Jedyną różnicą jest to, że w pierwszym przypadku każdy programista, który pracował nad projektem, używał własnego stylu. To spowodowało, że kod był niespójny, nieczytelny i niebezpieczny. Fakt, że członkowie zespołu nie byli w stanie zgodzić się co do wielkości wcięcia, w połączeniu z faktem, że jeden z nich odmawiał użycia nawiasów klamrowych po każdym, ifsprawił, że kod był wyjątkowo podatny na błędy: patrząc na to, możemy sądzić, że drugi ifjest wykonywane tylko wtedy, gdy pierwsza ifjest prawdziwa, co nie jest prawdą.

W drugim przypadku wszyscy programiści przestrzegali tego samego standardu. Niektóre z nich były być może nieszczęśliwe, ponieważ wolały wcięcia dwóch spacji lub ponieważ były przyzwyczajone do metod rozpoczynających się małą literą. Faktem jest, że kod jest w ten sposób o wiele bardziej czytelny i nadal byłby taki, gdyby używali innego standardu.

Dzięki ścisłym, jednolitym standardom kod jest łatwiejszy do odczytania.

2. Dlaczego ich standard jest lepszy niż ten, który właśnie wymyśliłem?

Jeśli standard jest używany przez setki tysięcy programistów na całym świecie, po prostu trzymaj się go. Nie wymyślaj własnych: nawet jeśli jest to lepsze, łatwiej jest migrować do globalnego standardu niż do setek tysięcy programistów, aby zacząć korzystać z twojego.

Przykład: w mojej firmie mam określoną konwencję nazywania podstawowych i obcych kluczy i indeksów w bazie danych. Te nazwy wyglądają następująco:

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] lub
  • [PK for RoleOfPassword: RoleId, PasswordId].

Osobiście uważam tę konwencję za doskonałą i niezwykle jasną. Dla mnie. Ale to całkowicie do bani. Jest do bani, ponieważ jest moja i ponieważ żaden z tysięcy administratorów baz danych nigdy jej nie używał. To znaczy że:

  • Kiedy zatrudnię DBA, będzie on zmuszony nauczyć się nowej konwencji, zamiast rozpocząć teraz pracę,

  • Nie mogę udostępniać fragmentów kodu w Internecie w takim stanie: te dziwnie wyglądające nazwiska będą przeszkadzać ludziom, którzy czytają mój kod,

  • Jeśli wezmę kod z zewnątrz, aby użyć go we własnym zakresie, będę zmuszony zmodyfikować nazwy, aby były jednolite,

  • Jeśli pewnego dnia zdecyduję się użyć jakiegoś znanego standardu, będę zmuszony przejść i zmodyfikować każdą z kilkuset nazw.

3. A co z dużymi literami?

Właściwości mają większy zasięg lub widoczność niż pola lub zmienne lokalne. Tworzenie właściwości zaczyna się od dużej litery, a pola i zmienne - od małej idzie w tym kierunku.

Jeśli weźmiesz pod uwagę C #, ta logika jest wystarczająco spójna.

Jeśli wziąć pod uwagę Javę, metody zaczynają się od małych liter, co nie jest zgodne z logiką.

Więc nie, nie ma ostatecznego dowodu, że ta konwencja jest lepsza od twojej. Po prostu ten jest używany na całym świecie, a twój nie. Żadne nie jest lepsze .

W JavaScript funkcje zaczynają się od małej litery, chyba że wymagają newwcześniejszego. Czy nie byłoby lepiej na odwrót? Może. Faktem jest, że od lat programiści JavaScript używali tego standardu, a nie odwrotnie. Przepisanie każdej książki i zmuszenie każdego programisty do zmiany stylu byłoby teraz nieco skomplikowane.


1
Jeśli chodzi o tę część, że kod jest mniej czytelny, ponieważ spełnia nieco inny standard, nigdy nie miałem tego problemu. O ile czyjeś zmienne nie są tak nazwane hookyDookyDoo, żadna konwencja nazewnictwa ani obudowy nie wpływa na czytelność. Pamiętaj też, że nie mówię, że moja konwencja jest „lepsza”, ponieważ tak naprawdę nie wnosi nic specjalnego do stołu deweloperów. Wreszcie, nie rozumiem twojego punktu [Właściwości mają większy zakres ... idzie w tym kierunku] . Co zakres ma wspólnego z konwencją obudów? Idź w jakim kierunku?
oscilatingcretin

23
@oscilatingcretin, pytanie nie brzmi, czy kiedykolwiek miałeś ten problem, ale czy mają go twoi koledzy . Oczywiście, że tak, inaczej nie narzekaliby.
Karl Bielefeldt,

1
Re: twoja edycja: Twój pierwszy przykład kodu pokazuje po prostu źle skonstruowany, podatny na katastrofy kod. W moim OP nie chodzi o źle skonstruowany, podatny na katastrofy kod. Chodzi o dokładnie ten sam kod, co w twoim drugim przykładzie, ale inną konwencję obudów. Zredagowałem twój drugi przykład kodu i zamieściłem go w moim OP z moją konwencją dotyczącą obudów. Zastąp to swoim pierwszym przykładem kodu.
oscilatingcretin

5
@oscilatingcretin: Pierwszy przykład kodu pokazuje nie słabo skonstruowany kod, ale kod napisany przez zespół, w którym każdy programista postępował według własnego stylu. Dzieje się tak w przypadku zbyt wielu baz kodów, biorąc pod uwagę wystarczającą ilość czasu (na przykład pięć lat). Uwaga: czy przeoczyłeś: „Faktem jest, że kod jest w ten sposób o wiele bardziej czytelny i nadal byłby, gdyby używali innego standardu”. ?
Arseni Mourzenko,

6
@oscilatingcretin Istnieje wiele badań, które pokazują, że spójność znacznie zmniejsza wysiłek poznawczy wymagany do zrozumienia czegoś, co czytasz. Regularna proza, zła pisownia, słaba interpunkcja i kiepska gramatyka utrudniają komuś czytanie - niezależnie od tego, czy zauważają to świadomie, czy nie. Kod jest wystarczająco trudny do odczytania, nie utrudniając go - przestrzeganie „wspólnego standardu” (dla stosu technologii wybranego przez ciebie) zwiększa ogólną spójność i uwalnia neurony do skoncentrowania się na ważnej działalności związanej z tym, co robi kod, zamiast na tym, jak To jest napisane.
Bevan

10

Technicznie nie ma to znaczenia (a przynajmniej w większości języków nie ma znaczenia).

Jednak większość społeczności programistycznych (niezależnie od tego, czy są to ogólnoświatowe społeczności, które utworzyły się wokół jednego określonego języka, podgrupy takich społeczności, grupy, które powstały wokół popularnej biblioteki lub zestawu narzędzi, czy tylko pojedyncze zespoły) opracowały ustalone standardy kodowania. Dokładne szczegóły są stosunkowo mało ważny (choć w wielu przypadkach dobrym argumentem może być dla nich), co jest ważne jest, aby trzymać się ich.

Nie dlatego, że są najlepsi, ale dlatego, że są tym, czego wszyscy inni używają; jeśli będziesz trzymał się tego standardu, twój kod będzie zgodny z większością innych kodów, których ostatecznie użyjesz - bibliotek, kodu członków drużyny, wbudowanych języków. Konsekwentne nazewnictwo to jedna potężna broń produktywności, ponieważ oznacza to, że kiedy odgadniesz nazwę czegoś, zwykle zgadniesz. Jest to file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? Konwencja nazewnictwa powie ci.

Przenoszenie osobistych preferencji na każdy język, z którym się spotykasz, jest szczególnie niebezpieczne, ponieważ przede wszystkim każdy język ma swoją kulturę, a konwencje nazewnictwa są często niezgodne; a po drugie, istnieje wiele subtelnych różnic między językami, jeśli chodzi o nazewnictwo.

Tylko jeden przykład: w języku C # typy i zmienne żyją w osobnych przestrzeniach nazw; kompilator jest wystarczająco inteligentny, aby poznać różnicę. Jednak w C oba rodzaje nazw mają wspólną przestrzeń nazw, więc nie można mieć typu i zmiennej o tej samej nazwie w tym samym zakresie. Z tego powodu C potrzebuje konwencji nazewnictwa, która odróżnia typy od zmiennych, podczas gdy C # nie.


Wygląda więc na to, że niektóre starsze języki utorowały drogę do kodowania standardów dla przyszłych języków (jak na przykład C / C #). Jest to najbardziej niefortunne, ponieważ śledzenie, w jaki sposób wielkość liter w zmiennych i elementach obiektu po prostu dodaje niepotrzebnego poziomu złożoności, bez którego można tego dokonać.
oscilatingcretin

4
@oscilatingcretin Kiedy wszyscy stosują tę samą konwencję, nie dodaje to ciągłej złożoności, konwencja staje się częścią twojego modelu mentalnego dla danego języka ORAZ ułatwia korzystanie z tego języka. Jest to możliwe do udowodnienia i wymierne.
Mr.Mindor,

Chciałem cię zagłosować, ale najpierw powiesz, że to nie ma znaczenia, a następnie napiszesz kilka akapitów wyjaśniających, dlaczego to ma znaczenie. Jeśli usuniesz „to nie ma znaczenia” na początku, zagłosuję za tobą.
Tulains Córdova

10

Dziwi mnie, że nikt inny tego nie powiedział, ale myślę, że różnica wielkości liter jest niezwykle pomocna z jednego powodu: miło i wygodnie jest wiedzieć, czy zmienna ma zasięg lokalny, czy nie. Jeśli zmienna jest lokalna, nie martwię się tak bardzo o skutki uboczne jej zmiany, takie jak refaktoryzacja nazwy. Lubię więc konwencję, która rozróżnia członków klasy od prywatnych zmiennych klasy od zmiennych lokalnych.

W przypadku nowoczesnego Intellisense ma to coraz mniejsze znaczenie, ale nadal daje mi pewne punkty orientacyjne, gdy czytam kod, aby wiedzieć, gdzie powinienem szukać definicji.

Spora część tego może pozostać z mojego gorszego stylu sprzed lat, kiedy metody nie były tak prawdopodobne, aby zmieściły się na jednym ekranie.


Wiele projektów, nad którymi pracowałem, określa coś takiego w swoim przewodniku po stylach.
anaximander

7

To wydaje się bardziej kwestią konwencji niż konkretnej konwencji.

Z każdą złamaną konwencją dodajesz więcej pracy dla wszystkich innych. Być może w idealnym świecie cała firma pracuje nad jednym produktem przez całe życie ... jednak w rzeczywistości nie jest to prawdą. Ludzie przeskakują między projektami, czasem między firmami, a nawet dla zabawy. Im bardziej losowy jest kod, tym trudniej i drożej jest pracować. Jako właściciel firmy lub interesariusz nie chciałbym zatrudniać programistów, którzy myślą samolubnie, niż dla dobra projektu.

Sprowadza się to do profesjonalizmu: czasami musimy odłożyć nasz osobisty styl na bok i zastosować coś, co jest bardziej skuteczne w przypadku masowej adopcji. To zachęca do współpracy i usuwa zewnętrzne bariery, których przede wszystkim nie powinno być.

Zgodnie z twoją obecną konwencją, CapitalCamelCase jest zwykle zarezerwowane dla nazw klas (lub w JavaScript, konstruktorów). Jeśli zobaczę zmienną pisaną wielkimi literami, wyedukowane przypuszczenie będzie dyktować, że muszę ją utworzyć, aby z niej skorzystać. Jeśli to źle, będę wkurzony, że kod nie spełnia standardów społeczności. Nawet w przypadku większości innych języków wszyscy inni, którzy patrzą na to po raz pierwszy, są natychmiast wprowadzani w błąd. Chcę, żeby kod był oczywisty, a nie wprowadzający w błąd.


„Jeśli zobaczę zmienną pisaną wielkimi literami, wyuczone przypuszczenie narzuci, że będę musiał utworzyć jej instancję, aby z niej skorzystać”. Nie rozumiem. W jaki sposób zobaczenie zmiennej pisanej wielką literą sprawi, że pomyślisz, że musisz ją utworzyć przed użyciem? Ponieważ wygląda jak nazwa klasy? Więc nie znasz różnicy między MyClass MyClass = nulli class MyClass { }?
oscilatingcretin

3
Tak, widzę różnicę. Konwencja istnieje, aby zapobiec dwuznaczności. var car = new Car();Zgodnie z moją ostatnią linią - dlaczego nie uczynić tego oczywistym?
Adrian Schneider,

3
@oscilatingcretin Istnieje oczywiście różnica. Ale ludzki mózg korzysta z wizualnych wskazówek, których parser komputerowy nie potrzebuje. Wygląda na to, że kwestionujesz potrzebę konwencji / standardów ... co jest ważnym, choć innym pytaniem niż to, co pierwotnie zadałeś.
Andres F.,

2

„ponieważ pełna właściwa wielkość liter powinna być zarezerwowana dla właściwości i metod void. Zmienna lokalna i metody zwracające wartość powinny mieć pierwsze słowo pisane małymi literami”, ponieważ jest to standardowa konwencja.

Inni programiści wyciągają teraz twój kod i myślą, że jest to właściwość, a tak naprawdę zmienna lokalna, co utrudnia pracę.


1
Czy przeczytałeś w całości moje pytanie? Spójrz na koniec, gdzie powiedziałem:NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
oscilatingcretin

8
Tak i tak, to ma znaczenie, następny programista nigdy nie powinien myśleć o NuggetCount, powinieneś być w stanie spojrzeć na nazwę i powiedzieć. Dobra książka do przeczytania to „Czysty kod”, powinieneś być w stanie przeczytać kod jak opowieść i wiedzieć, co się dzieje.
N4TKD

2
@oscilatingcretin Myślę, że frustracja, jaką odczuwasz, gdy ludzie odpowiadają na nieco inne pytania niż zadajesz, jest dowodem zamieszania, które może powstać, gdy złamiesz przyjęte konwencje.
Mr.Mindor

7
Konwencje mają znaczenie. Jeśli zgodnie z konwencją NuggetCount implikuje właściwość, oznacza to, że ma zasięg wykraczający poza to, co miałaby zmienna lokalna. Co oznacza, że ​​muszę więcej badań, aby określić ten zakres. Muszę ustalić: czy są jakieś skutki uboczne zmiany? Czy mogę ufać, że jego wartość nie zostanie zmieniona przez inny wątek podczas jego używania? nuggetCount zakłada zasięg lokalny i powinienem być w stanie założyć, że cała jego historia jest lokalna.
Mr.Mindor,

5
@oscilatingcretin TAK! Dokładnie! Ufałem, że to, co napisali, było zgodne z konwencją i zawierało wszystko, co z nią związane. Ufałem, że pracują jako część zespołu i mogłem czerpać korzyści z korzystania z tej konwencji (wiedząc, co nuggetCount jest w skrócie). Jeśli nie, prawdopodobnie robię to, co zrobili twoi współpracownicy: staram się kształcić odpowiedzialnego i tracę więcej czasu następnym razem, gdy muszę ich przestrzegać, nie ufając. Nie przestrzegając konwencji, stworzyli mniej czytelny, mniej konserwowalny kod. Czy masz powód, by chcieć przełamać konwencję?
Mr.Mindor,

0

Jak inni powiedzieli, nie ma żadnego prawdziwego powodu, z wyjątkiem uzyskania konwencji nazewnictwa. Jeśli umieścisz cały zespół na tej samej stronie, prawdopodobnie zaoszczędzisz trochę czasu. Na przykład osobiście zacząłem normę kodowania, która weszła w to i użyliśmy camelCase do wszystkich prywatnych odmian, a także rzeczy przekazanych przez Val, podczas gdy PascalCase użyliśmy do rzeczy publicznych, a także rzeczy przekazanych przez Ref.

Linie stają się trochę rozmyte, gdy mamy do czynienia z takimi rzeczami, jak chroniony, Out czy coś takiego.


-2

Język (z formalnym i konwencjonalnym aspektem) jest ważny dla uporządkowania myśli, ma władzę nad twoimi sposobami myślenia. Tak więc przejście od jednego stylu do drugiego jest bardzo uciążliwe.

Symbole pisane małymi i dużymi literami mają duże różnice semantyczne w Haskell, również różnią się nieznacznie w Scali i użyłem obu z nich. Inne języki, których używam, nie robią różnicy między tymi dwoma rodzajami identyfikatorów, ale trzymanie myśli w sposób, w jaki Haskell postrzega identyfikatory, jest dla mnie o wiele łatwiejsze niż dzielenie umysłu na różne języki.


-2

Dla mnie sprowadza się to do oczekiwań.

Kiedy czytam większość kodu, oczekuję, że wszystko, co zaczyna się od a, lowerCasebędzie zmienną lokalną lub funkcją (w języku C # to byłaby tylko zmienna). Gdybym zobaczył zmienną lokalną ProperCase, prawdopodobnie potknęłbym się i przez pewien czas byłbym zdezorientowany, myśląc, że jest to albo nazwa klasy, albo własność, albo coś innego. Spowoduje to, że ponownie przeczytam kod i irytuje mnie.

To prawdopodobnie dzieje się w twoim przypadku.

Ponadto wygodnie jest móc określić rolę, jaką odgrywa zmienna, patrząc tylko na pierwszą literę, i pozwala uniknąć konfliktów między nazwą instancji a nazwą klasy.


-3

Dla lokalnych zmiennych należy używać małych liter, aby ułatwić pisanie (klawisz prędkości / brak klawisza Shift). Wielkie litery są używane, aby poprawić czytelność, oddzielając słowa w nazwie. Kod z lokalnymi pojedynczymi słowami zmiennych (które powinny być wspólne) jest szybki i łatwy do wpisania. Używanie wielkich liter dla każdego nowego słowa w nazwie jest również szybsze (i mniej miejsca) niż stosowanie podkreślników, które dodają inny znak - jest to również znane jako wielbłąd.


Myślę, że to bardzo dobra odpowiedź i nie rozumiem głosów negatywnych. To logiczna odpowiedź - oparta na faktach wymaganych przez PO. Jeśli głosujesz w dół, proszę się wytłumacz. Naciśnięcie klawisza Shift w tym miejscu jest ogromne. Pomyśl o tym, prawie każde słowo, które wpiszesz w kodzie, uruchomi PascalCase i dla każdego z nich będziesz potrzebować kolejnego klawisza Shift. Jeśli chcesz być minimalistyczny i skuteczny, warto usunąć niepotrzebne naciśnięcia klawiszy Shift. I logicznie rzecz biorąc, chciałbyś być bardziej produktywny, co z tego, co stoję, oznacza naciskanie mniejszej liczby klawiszy. Po co naciskać więcej?
AIon

-3

Zgadzam się z PO tutaj. camelCase wygląda po prostu źle. Zgadzam się również z faktem, że jest to standard i musimy trzymać się tego samego standardu lub jaki jest sens posiadania standardu. Ma to również sens, że PascalCaps może być używany do metod itp., A camelCase do własnych zmiennych itp. Jako sposób na rozróżnienie, gdy nie używa się IDE, które koloruje metody dla ciebie.

Aby obejść ten problem, zawsze poprzedzam nazwy mojego obiektu typem obiektu. Więc jeśli jest to zmienna łańcuchowa, nazywam strMyVariable. Jeśli jest to jakiś obiekt, nazywam go objMyObject itp. W ten sposób zaczyna się od małych liter zgodnie ze standardem i wygląda dobrze.


3
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami poczynionymi i wyjaśnionymi w poprzednich 11 odpowiedziach
gnat
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.