Czy jestem niemoralny, używając nazwy zmiennej, która różni się od jej typu tylko wielkością liter?

Na przykład weź ten fragment kodu:

var person = new Person();

lub dla Ciebie Pythonistas:

person = Person()

Ciągle słyszę, jak źle to jest, ale nie widziałem jeszcze przykładu niemoralności tych dwóch wierszy kodu. Dla mnie osoba jest Osobą i próba nadania jej innego imienia jest stratą czasu. Przypuszczam, że w dniach poprzedzających podświetlanie składni byłaby to wielka sprawa. Ale obecnie dość łatwo odróżnić nazwę typu od nazwy zmiennej. Heck, nawet łatwo zauważyć różnicę w SO.

A może jest coś, czego mi brakuje? Jeśli tak, byłoby pomocne, gdybyś mógł podać przykład kodu, który powoduje problemy.

Jakie jest rozumowanie tych, którzy mówią ci, że to jest złe? Robię to cały czas. Jest to najprostszy, wyrazisty sposób nazwania pojedynczej zmiennej typu. Jeśli potrzebujesz dwóch Personobiektów, możesz poprzedzić personznaczącymi przymiotnikami, takimi jak

fastPerson
slowPerson

inaczej po prostu

person

nie przeszkadza mi.

Często używam tego wzorca w sygnaturach metod. Jeśli nie mogę podać alternatywnej nazwy opisowej, a następnie IMHO, nie ma w tym nic złego.

Źle byłoby, gdybyś miał dwa typy: osoba i osoba, to bardzo, bardzo źle.

Używam go cały czas do tymczasowych odniesień do obiektów. Uniknąłbym tego jak plagi dla prymitywnych typów danych.

Person person = new Person(); // okay

int Int = 42; // pure evil

Jeśli ktoś mówi, że to złe, zapytaj go, czy tak jest lepiej:

var abc = new Person();

Jeśli w kontekście osoba jest osobą ogólną, to „osoba” to naprawdę dobre imię. Oczywiście, jeśli osoba ma określoną rolę w kodzie, lepiej jest nazwać ją za pomocą tej roli.

Przypuszczam, że zostanę zlekceważony za to, ale ...

Właśnie przeszliśmy przez stulecie, będąc świadkami epickich morderstw i chciwości, my, programiści, jesteśmy naprawdę błogosławieni, jeśli najbardziej niemoralną rzeczą, jaką możemy zrobić, jest nazwanie zmiennej.

Nie wydaje mi się, żeby to było „złe”, ale oczywiście jeśli możesz to określić, aby nadać mu więcej kontekstu, np. Jakiego rodzaju jest to osoba (masz do czynienia tylko z jedną z przypuszczalnie wielu możliwych osób), wtedy ktoś inny ją wybierze się może lepiej zrozumieć.

Jason - Nie jestem pewien, kto ci powiedział, że to jest złe. Wielu autorów używa tego jako standardowego sposobu wyrażania Instancji (małe litery) klasy (pisane wielką literą).

Używam tego dość często, ponieważ stwierdzam, że zmienna pisana małymi literami faktycznie przekazuje mi nie tylko informację, że jest to instancja, ale także nazwę klasy.

O ile ktoś nie ma solidnego argumentu przeciwnego, z pewnością będę to kontynuować.

Powodem, dla którego jest to uważane za złe, jest to, że jeśli w przyszłości potrzebujesz mieć 2 osoby, możesz skończyć z kodem, który wygląda jak.

Osoba osoba = nowa Osoba ();

Osoba osoba2 = nowa Osoba ();

Byłoby to wtedy z pogranicza „Zła”. Jednak w takim przypadku powinieneś dokonać refaktoryzacji swojej oryginalnej osoby, aby odróżnić je od siebie.

Na przykład nazwa zmiennej „osoba” jest doskonale opisową nazwą obiektu „Osoba”. Dlatego nie ma w tym nic złego.

Podaję nazwę, co to jest: jeśli zmienna reprezentuje osobę z 2 psami, nazwij ją personWith2Dogs. Jeśli zmienna ma krótki zasięg (jak zmienna pętli), osoba jest w porządku.

Używam tego dużo w moim kodzie i nie sądzę, że jest w nim coś złego. To powiedziawszy, (prawdopodobnie) nie użyłbym go w metodzie dłużej niż, powiedzmy, jeden ekran i jeśli istnieje wiele wystąpień klasy Person. Zdecydowanie nie nazywaj ich osoba1, osoba2, osoba3 ... zamiast tego użyj czegoś bardziej opisowego, na przykład person_to_del, person_to_ban, person_to_update itp.

Nie niemoralne, ale globalne wyszukiwanie znajdzie oba Personi personjeśli nie włączysz rozróżniania wielkości liter. Wolę prefiks, aby ułatwić globalne wyszukiwanie / zamianę, ale absolutnie NIE węgierski ani coś długiego / skomplikowanego. Więc używam ...

Persondla klasy / typu aPersondla zmiennej lokalnej thePersondla parametru metody myPersondla zmiennej instancji ourPersondla zmiennej klasy

W rzadkich przypadkach mogę użyć pw lokalnym kontekście, w którym mam DUŻO odniesień, ale zwykle dotyczy to tylko indeksów pętli i tym podobnych.

To zależy.

Jeśli masz ścisły styl wielkich liter, więc zmienne zaczynają się małymi literami (i używaj under_scores lub camelCase do łamania słów), a klasy zaczynają się od wielkich liter, wtedy jest oczywiste, że osoba jest zmienną, a osoba jest klasą, a kiedy ktoś to rozumie , nie wydają się znajdować w nakładających się przestrzeniach nazw. (Podobnie, ludzie prawie nigdy nie są myleni między czasownikiem lub rzeczownikiem „polski” a przymiotnikiem „polski”.)

Jeśli nie masz takiego stylu, masz dwie nazwy, które można łatwo pomylić i różnią się tylko wielkością liter. To źle.

Jakich dokładnie argumentów używają ci ludzie?

Jeśli nie pozwalają na użycie osoby jako nazwy zmiennej, możesz rozważyć dodanie przedrostka „a”.

aPerson = Person()

Myślę, że to, co robisz, jest w porządku. Myślę, że ogólnie ważne jest, aby uzgodnić standardy kodowania.

Na przykład używam lowerCamelCase dla instancji, zmiennych i UpperCamelCase dla klas itp

Standardy kodowania powinny usunąć ten problem.

Kiedy patrzę na odnoszące sukcesy programy open source, często mają one standardy kodowania

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

Uzgodnienie standardów kodowania powinno być ostatnią bitwą, jaką masz w tej sprawie.

W rzeczywistości spójrz na wpis wikipedii (z http://en.wikipedia.org/wiki/CamelCase )

Styl programowania i kodowania

Czasami zalecane jest używanie wielkich liter w celu wskazania granic słów w wytycznych dotyczących stylu kodowania przy pisaniu kodu źródłowego (np. Język programowania Mesa i język programowania Java). Zalecenia zawarte w niektórych z tych wytycznych są wspierane przez narzędzia do analizy statycznej, które sprawdzają zgodność kodu źródłowego.

Te zalecenia często rozróżniają między UpperCamelCase i lowerCamelCase, zwykle określając, która odmiana powinna być używana dla określonych rodzajów jednostek: zmiennych, pól rekordów, metod, procedur, typów itp.

Jeden szeroko stosowany styl kodowania w Javie nakazuje, aby UpperCamelCase był używany do klas, a lowerCamelCase do instancji i metod. [19] Rozpoznając to użycie, niektóre IDE, takie jak Eclipse, implementują skróty oparte na CamelCase. Na przykład w funkcji pomocy treści Eclipse wpisanie tylko wielkich liter słowa CamelCase zasugeruje dowolną pasującą nazwę klasy lub metody (na przykład wpisanie „NPE” i aktywacja pomocy treści może zasugerować „NullPointerException”).

Oryginalna notacja węgierska dotycząca programowania określa, że ​​mały skrót oznaczający „typ użycia” (nie typ danych) powinien poprzedzać wszystkie nazwy zmiennych, a pozostałą część nazwy należy wpisać w UpperCamelCase; jako taka jest formą lowerCamelCase. CamelCase to oficjalna konwencja nazw plików w Javie i dla komputerów osobistych Amiga.

Microsoft .NET zaleca lowerCamelCase dla parametrów i niepublicznych pól oraz UpperCamelCase (aka „Pascal Style”) dla innych typów identyfikatorów. [20]

Python zaleca UpperCamelCase dla nazw klas. [21]

Rejestr NIEM wymaga, aby elementy danych XML używały UpperCamelCase, a atrybuty XML korzystały z lowerCamelCase.

Nie ma jednej konwencji umieszczania skrótów wielkich liter (głównie akronimów i inicjałów) w nazwach CamelCase. Podejścia obejmują pozostawienie całego skrótu wielkimi literami (np. „UseHTTPConnection”) i pozostawienie tylko pierwszej litery wielkiej (np. „UseHttpConnection”).

Obudowa wielbłąda nie jest bynajmniej uniwersalna w komputerach. Użytkownicy kilku nowoczesnych języków programowania, zwłaszcza tych z rodzin Lisp i Forth, prawie zawsze używają łączników. Wśród powodów, które czasami podaje się, jest to, że nie wymaga to zmiany na większości klawiatur, że słowa są bardziej czytelne, gdy są rozdzielone, oraz że wielbłądowe litery mogą po prostu nie być niezawodnie zachowane w językach bez rozróżniania wielkości liter lub ze składaniem wielkości liter (takich jak Common Lisp, który, choć technicznie jest językiem uwzględniającym wielkość liter, domyślnie kanonizuje (składa) identyfikatory do wielkich liter).

Można mocniej argumentować, że tego rodzaju nazwy metod są nie tylko nieszkodliwe, ale mogą być wskaźnikiem dobrej jakości kodu.

• Wskaźnik dobrej szczegółowości kodu: jeśli Twoje metody są krótkie, przeznaczone do jednego celu i opisowo nazwane, nie potrzebujesz wielu informacji w nazwach zmiennych. Jeśli masz długie metody, które wykonują wiele rzeczy i musisz śledzić wiele kontekstów i stanów, nazwy zmiennych muszą być bardziej opisowe.

• Wskaźnik spychania obliczeń ogólnego przeznaczenia do metod ogólnego przeznaczenia: jeśli wykonujesz pośrednią manipulację strukturami danych w metodzie biznesowej, na przykład tablica użytkowników musi zostać zdeduplikowana, będziesz musiał mieć zmienne w zakresie o nazwach takich jak users[]i deduplicatedUsers[]. Jeśli przeniesiesz deduplikację do metody narzędziowej, możesz wywołać tę metodę Utils.dedup(array)i możesz wywołać zdeduplikowaną tablicę deduplicatedArraylub po prostu result.

• Dekompilatory Java często używają takiego schematu do nazywania zmiennych lokalnych (zmienne instancji i klasy są zwykle dostępne w kodzie bajtowym, ale zmienne lokalne nie są), a wyniki są bardziej czytelne niż można by się spodziewać, w rzeczywistości często bardziej czytelne niż Pierwotnym źródłem.

• Zobacz zasadę Larry'ego Walla „Lokalna niejednoznaczność jest OK” - http://www.wall.org/~larry/natural.html .

Powiedziałbym, że kiedy tworzysz obiekt, prawdopodobnie masz na myśli jakieś szczególne zastosowanie. Sam typ bardzo rzadko odzwierciedla to użycie.

Więc jeśli chcesz utworzyć nowy kontakt w swojej aplikacji książki adresowej, możesz chcieć wywołać zmienną newContact.

A jeśli testujesz jednostkowo swój kod, aby sprawdzić zachowanie Personobiektów bez ustawionych nazw, możesz chcieć je wywołać unnamedPersonlub coś podobnego.

Nazywanie go po prostu oznacza personrezygnację z dużej szansy na samodokumentację kodu.

Tylko jeśli programujesz w VB6. W takim przypadku to, co robisz, jest nielegalne, ale nie niemoralne.

Ja też to robię i nie rozumiem też, dlaczego miałoby to być „niemoralne”. Chociaż rozumiem, że czasami może to być mylące, ale dzisiaj mamy IDE z inteligencją i podświetlaniem składni, które zapewnią, że (jeśli popełnisz błąd i odniesiesz się do zmiennej zamiast do klasy i odwrotnie) dość szybko zobaczysz swój błąd. Mamy też kompilator. :)

Nie widzę też żadnego problemu w tej praktyce. Dopóki istnieje tylko jedna zmienna tej klasy, jest łatwa do napisania i łatwa do odczytania. Imo, to działa nawet w podstawowym edytorze tekstu. Osobiście nie przypominam sobie, żeby ktokolwiek nazwał to złym lub nawet niemoralnym. Po prostu kontynuuj to :)

Myślę, że „reguła”, o której możesz pomyśleć, jest przeznaczona bardziej dla typów pierwotnych i klas, w których nazwa klasy jest złą nazwą zmiennej.

Na przykład, gdybyś miał do czynienia z kalkulacją ceny konkretnego towaru w sklepie internetowym, poniższy kod nie byłby dobrą formą:

Decimal _decimal = item.BaseCost + item.Tax;

Zamiast tego zalecana byłaby bardziej opisowa nazwa, na przykład „_total” lub „_cost”.

Jedyny problem z tego rodzaju rzeczami, jaki znalazłem, to to, że chcesz mieć taką samą nazwę dla członka prywatnego, a także własności publicznej.

Jeśli różnią się one tylko wielkością liter, będzie działać dobrze w językach z rozróżnianiem wielkości liter, takich jak C #, ale nie w VB.NET.

Więc na przykład w VB napisałbym

Private _name As String

ale

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

Zrobiłbym to samo w C #, aby tłumaczenie z jednego do drugiego było bezbolesne. Dzięki temu jest trochę mniej podatny na błędy, ponieważ bardzo łatwo jest źle odczytać, a nawet błędnie wpisać słowa, które różnią się tylko wielkością liter.

Nie niemoralne, ale jeśli najlepszą nazwą dla zmiennej jest nazwa typu, coś jest nie tak lub po prostu udowadniasz koncepcję lub coś w tym rodzaju. Dla mnie nazwa zmiennej musi odnosić się do znaczenia w kontekście biznesowym, a nie do języka programowania. Zrozumienie kodu będzie trudniejsze.

Często używam Person person = new Person()siebie. Powszechnie używane w Javie / C #.

Chociaż wczoraj zastanawiałem się, dlaczego

private enum DataType {NEW, OLD}

nie działa w C # ...

Zwłaszcza widząc, jak można użyć String, string, Double, double, ... do woli w języku C #.

Person person = new Person()

jest w porządku w mojej książce.

Kiedy to staje się okropne, jest:

string Person;
string person;

Bardzo łatwo wymieszać 2.

To, co zostało mi powiedziane, poza tym, że nie spełnia naszych standardów kodowania, to unikanie dodawania nieporozumień, gdy ktoś inny czyta mój kod. Osobiście nie widzę z tym problemu, o ile znaczenie jest jasne.

Jeśli chodzi o typy CLR (int, string itp.), Możesz użyć String lub string (itp.) Do zadeklarowania typu, więc unikałbym używania czegoś takiego

int Int = 0;
string String = "hi there";

Dokonywanie wielkich liter jedyną różnicą jest niebezpieczne ... rób to dalej dla dużego projektu, a gwarantuję , że napotkasz dziwne błędy, których nie możesz zlokalizować.

fastPerson / slowPerson, jak wyżej, są w porządku ... są opisowe i różnią się od nazwy typu zmiennej ... ale daj spokój, man, wywołanie int "Int" byłoby po prostu leniwe.

Powiedziałbym, że nigdy nie jest niemoralne - tak naprawdę to tylko nazwa zmiennej linii bazowej. Jeśli nie można wymyślić lepszej nazwy, nazywając go po jego typ jest domyślnie dobry (Dla typów złożonych. Tylko - dla typów wbudowanych w jego zło ) i dużo czasu tak naprawdę nie jest lepsza nazwa przyczyna don” nie wiem nic więcej o zmiennej. Podobnie jak w przypadku tej metody

void SaveToDatabase(Person person) {...}

Jedyną rzeczą, którą możesz rozsądnie nazwać osobę, jest person_to_savecoś takiego, co wydaje się zbędne.

Jednak w wielu przypadkach można poprawić czytelność kodu, zastępując osobę bardziej opisową nazwą. Na przykład jest to mniej opisowe

void AddToAccount(Account account, Person person)  {...}

od tego

void AddToAccount(Account account, Person dependent)  {...}

Jednak proszę - bardzo proszę, nie umieszczaj „a” ani „t” przed nazwą typu. IE aPerson dla „osoby” lub tPerson dla „osoby”. Jest to zbyt skomplikowane i nie dodaje wiele, jeśli w ogóle, wartości. Dodatkowo zaczynasz zanieczyszczać swój zasięg kilkoma zmiennymi zaczynającymi się od a lub t, co może zminimalizować wartość funkcji intelli-sense.

Nie powiedziałbym, że to straszne. Zwykle poprzedzam nazwę zmiennej „a” w tego rodzaju rzeczach, aby pokazać, że jest to pojedyncza instancja tego typu, więc zrobiłbym

Person aPerson = new Person();

Myślę, że to sprawia, że ​​kod jest czytany bardziej naturalnie.

Absolutnie nie ma w tym nic złego, z zastrzeżeniem zastrzeżeń wskazanych przez innych (podsumowanie tutaj dla wygody): nie robienie tego z typami prymitywnymi, refaktoryzacja oryginalnej instancji, jeśli później zostanie dodana inna instancja, nie używanie wielkości znaków do rozróżniania nazw klas itp.

Moja praktyczna zasada? Instrukcje w kodzie powinny wyglądać jak proste angielskie zdania.

Osoba osoba = nowa Osoba ();

Pracownik pracownik = person.getRole (PRACOWNIK);

Rodzic rodzic = person.getRole (PARENT);

person.getFullName ();

pracownik.getSalary ();

parent.getChildren ();

parent.getFullName (); // zakładanie wzorca dekoratora w grze

if (person.hasRole (PRACOWNIK)) {

  ...

}

I tak dalej.

Jeśli zakres zmiennej jest ograniczony (na przykład metoda hermetyzacji to 10-15 wierszy), mógłbym nawet użyć „p” zamiast „osoba”. Krótsze nazwy zmiennych są mniej rozpraszające, gdy próbujesz utrzymać kontekst w głowie. Unikaj nieuzasadnionych przedrostków, takich jak „a” lub (dreszcz) notacja węgierska i jej odgałęzienia. (Pamiętaj, nie mam nic przeciwko takim prefiksom, gdy są używane w odpowiednim kontekście - kod API C ++ / COM / ATL / Win32 itp., Gdzie pomaga to zachować proste przypisania / typowanie).

Moje dwa (!) Bity :-)