Czy zmienna powinna mieć nazwę Id lub ID? [Zamknięte]

126

To trochę pedantyczne, ale widziałem, jak niektórzy ludzie używają Id:

private int userId;
public int getUserId();

i inni używają:

private int userID;
public int getUserID();

Czy jedno z nich jest lepsze niż drugie? Dlaczego? Widziałem to bardzo niekonsekwentnie w dużych projektach. Gdybym ustalił standard, który zna większość ludzi? Który jest standardem?

coding-style naming variables

— Adam
źródło

40

Najważniejsza jest spójność. Może to być wielbłąd, podkreślenie lub coś w tym stylu. Bądź konsekwentny.

38

Spójrz na interfejsy API XML swojego języka, aby zobaczyć, jak to robią. Klasy nazw Java jak SAXParseri. DOMExceptionNazwy klas .NET jak XmlDocument. Na tej podstawie powiedziałbym „ID” w Javie, „Id” w C #.

— luiscubal

1

Ale identyfikatory pisane wielkimi literami są z reguły używane w Javie dla pól statycznych, więc nazwa „ID” dla pola podstawowego nie jest najlepsza. I pojawia się konsekwencja ...

— Danubian Sailor

8

Czy nazwałbyś zmienne EGOi SuperEGO? Nie myślałem tak. ;)

— kojiro

4

Co?! Konsystencja? Gdzie jest wojna furii ?! To jest to, niniejszym mianuję się opiekunem świętego płomienia składni wielbłąda i niniejszym postanawiam, że robienie wielkich liter akryonimami jest dla noobów. Prawidłowo jest też chcieć, aby rolka papieru toaletowego była od góry, chyba że masz koty, które się nudzą i robią dziwne rzeczy, w takim przypadku znacznie trudniej im jest rozłożyć papier toaletowy, aby zwinąć się z dołu, dzięki czemu taka herezja jest akceptowalna dla właściciele kotów. Nie wiem, dlaczego mam to wydać. Wydaje mi się, że Bob, opiekun świętego płomienia w kierunku toaletki, jest zajęty.

— Erik Reppen

56

Najważniejszą zasadą, której należy przestrzegać w tych przypadkach, jest konsekwencja: Postępuj tak, jak wszyscy inni.

Na przykład spójrz na interfejsy API XML swojego języka, aby zobaczyć, jak to robią.

Klasy nazw Java, takie jak SAXParser i DOMException , klasy nazw .NET, takie jak XmlDocument .

Na tej podstawie powiedziałbym „ID” w Javie, „Id” w C #.

Widziałem jednak, że Java EE 6 ma adnotację o nazwie @Id(patrz dokumentacja ), więc wygląda na to, że Java uważa „Id” za zwykłe słowo.

— luiscubal
źródło

@Id wskazuje nazwę klasy adnotacji, a nie nazwę zmiennej. Niewłaściwy przykład.

— jwenting

3

SAXParser może być (a na szczęście nie jest) SimpleAPIforXMLParser (lub nawet SimpleApplicationProgramingInterfaceforExtesibleMarkupLanguageParser). Każda wielka litera zaczyna się od słowa. Nawet w Javie powinien to być „Id”

— user470365

2

@jwenting Problem polega na ustaleniu, czy „identyfikator” jest traktowany jak słowo, czy jak dwa słowa. @Idmówi, że jest to pojedyncze słowo, więc nazwa zmiennej to „id”.

— luiscubal

Nie. SAX jest akronimem, podczas gdy Id nie.

— dokładnie

8

Masz rację, używając Idw C # (i .NET w ogóle), ale z innego powodu. Reguła polega na pisaniu wielkimi literami dwuliterowego akronimu (np. IPAddress) I tylko pisaniu pierwszej litery dłuższych akronimów (jak podany przez XmlDocumentciebie przykład ). Ale Idi Oksą wyjątki od tej reguły, konkretnie wspomniane. Pełen opis znajduje się w Capitalization Rules for Acronymssekcji tego Capitalization Conventionsartykułu. Ale nawet Microsoft łamie tę zasadę (np. DbConnectionVs. DBNull)

— Allon Guralnek

110

Konsekwencja jest królem; wybierz jedno lub drugie, ale rób to konsekwentnie wszędzie.

To powiedziawszy, wolę pierwszą odmianę, ponieważ nie narusza camelCase (robienie tego oznacza, że musisz zapamiętać dwie reguły stylu, nie tylko jedną).

Z tego powodu czasami używane są dwie wielkie litery , ale identyfikator jest tak naprawdę tylko formą potwierdzenia tożsamości.

— Robert Harvey
źródło

18

Na przykład nie podobałoby mi się, gdyby program komputerowy próbował uzyskać dostęp do mojego identyfikatora.

— Blrfl

1

userIdOfSender

— Sean McSomething,

19

@SeanMcSomething: Ick. SenderUserId

— Robert Harvey

5

Chociaż zgadzam się z tobą, że „Id” jest preferowanym sposobem, w jaki mogę zobaczyć, gdzie pojawia się zamieszanie: w codziennej rozmowie mówimy to tak, jakby to był akronim, jak w „czy mogę zobaczyć twój identyfikator?”

— 500 - Błąd wewnętrznego serwera

3

Spójrz na inne akronimy w przypadku wielbłąda. Istnieje SoapProtocol, a nie SOAPProtocol. Identyfikator jest skrótem od dokumentu tożsamości, więc nie rozumiem, dlaczego należy go traktować w wyjątkowy sposób w przypadku wielbłądów. To powiedziawszy, wolę identyfikator użytkownika używany spójnie niż identyfikator użytkownika i identyfikator użytkownika używany niekonsekwentnie w moim programie.

— Neil

76

TL; DR: W kontekście bibliotek klas .NET firma Microsoft zaleca używanie identyfikatora. Jest to nieco sprzeczne z intuicją, ponieważ jest to rzadki przykład skrótu, który jest dozwolony / zalecany (skróty są zwykle odrzucane).

Jeśli mówimy o konwencjach bibliotek klas C # lub .NET, Microsoft ma pewne dość dobrze zdefiniowane wytyczne dotyczące nazewnictwa . Są dobrze przemyślane i zawierają wiele wyjaśnień na różne tematy - w rzeczywistości każdy programista powinien poświęcić trochę czasu na przeczytanie całej sekcji Wytycznych projektowych .

Jeśli chodzi o akronimy , ogólna zasada jest taka: w przypadku akronimów dwuliterowych zwykle używasz wielkich liter (tam, gdzie ma zastosowanie IOStreamwielkość Pascala), więc np. Może to być nazwa klasy. W przypadku dłuższego akronimu, mała część reszty akronimu, np . XmlDocumentLub HtmlParser. W rzeczywistości jest to w większości jednoznaczna zasada (nie ma zamieszania co do tego, gdzie kończy się jedno słowo, a następne zaczyna, chyba że tworzysz dwuliterowe akronimy) i przyzwyczajasz się do niego bardzo szybko.

Czy to jest identyfikator czy identyfikator? Cóż, według Microsoftu, może nie być tak, jak myślisz:

Akronimy różnią się od skrótów tym, że skrót skraca jedno słowo. Na przykład ID to skrót identyfikatora . Ogólnie nazwy bibliotek nie powinny używać skrótów.

Dwa skróty, których można użyć w identyfikatorach, to ID i OK. W identyfikatorach z pascalami powinny występować jako Id i Ok. Jeśli użyte jako pierwsze słowo w identyfikatorze wielbłąda, powinny pojawić się odpowiednio jako id i ok.

Anegdotycznie nie jestem pewien, kiedy to rozróżnienie zaczęło pojawiać się w wytycznych, ale kilka lat temu (około 3,0 / 3,5) ogólny trend nazewnictwa w bibliotekach klas zmienił się z ID na Id.

— Daniel B.
źródło

1

Jest to wytyczna, której zwykle się kieruję. Ponieważ id jest skrótem, a nie akronimem, zawsze wolę używać „Id”.

— Toby

Używam identyfikatora, ponieważ łamie on konwencję i wyróżnia się wyjątkowością, a jak na ironię :)

— RhysW

Myślę, że Microsoft się myli. ID to inicjalizacja dokumentu tożsamości, nie jest skrótem od tożsamości. (Pedantycznie akronimy są wymawiane.)

— Tom Hawtin - tackline

@ TomHawtin-tackline Robisz interesujący punkt, chociaż podejrzewam, że zależy to od kontekstu. Coś w rodzaju właściwości IDNumber na obiekcie Person miałoby wiele sensu, ale dla VehicleId czytać jako „Dokument tożsamości pojazdu” kontra „Identyfikator pojazdu”? W kontekstach programowych identyfikator jest dość powszechnym słowem dla wszystkiego, co jednoznacznie identyfikuje instancję, i argumentowałbym, że bardziej pasuje tutaj.

— Daniel B

@DanielB W językach komputerowych, nawet SQL, „identyfikator” zwykle odnosi się do nazwy, takiej jak nazwa kolumny. Zazwyczaj jest skracane do „ident”. Pojazd jest interesującym przykładem, ponieważ istnieją ustalone schematy VIN (numery identyfikacyjne pojazdu). W typowym kontekście programowania „dokument” dla jednostki jest liczbą (może nawet być niewybaczalną funkcją).

— Tom Hawtin - tackline

15

Przeczytałem bardzo dobre wyjaśnienie w dokumencie niektórych konwencji kodujących. CamelCase należy zawsze używać w przypadku akronimów i skrótów, ponieważ łatwiej jest odróżnić granice słów (porównać XmlIdWriterdo XMLIDWriter).

— gilden
źródło

12

Oto jeszcze lepszy pomysł na rozróżnienie granic słów: rzeczywiste granice słów! xml_id_writer.

— Kaz.

4

@Kaz Cóż, duh! Jednak CamelCase jest tradycyjnie używany w niektórych językach i byłoby raczej nie na miejscu stosowanie podkreślników w takich sytuacjach. Konsekwencja jest królem, jak wspomniano wcześniej.

— gilden

1

Używanie CamelCase tylko dlatego, że w podstawowych bibliotekach niektórych języków jest używana, nie jest to spójność, ale zgodność.

— Kaz

3

@Kaz: W swoim sklepie masz więcej bitew niż konwencje kodeksowe.

— Robert Harvey

2

Jak widzimy w domyślnej funkcji JavaScript getElementById (); Identyfikator jest zapisany w etui na wielbłąda ...

Użyj „id”, jeśli używasz ze znakiem podkreślenia. Przykład: identyfikator_użytkownika

Użyj „Id”, jeśli nazywasz var bez podkreślenia, aby rozróżnić różne słowa. Przykład: userId

Jeśli jest to zmienna składająca się z jednego słowa, powinna być zapisana małymi literami, jeśli zmienna składa się z wielu słów, użyj małej litery Camel. Przykład: thisIsExample

Ale zdecydowanie nie poleciłbym „ID” wszystkich w CAPS, ponieważ generalnie używamy wszystkich wielkich liter do definiowania KONSTANCJI.

— Sukrit Gupta
źródło

W trzecim akapicie twój przykład nie pasuje do twojego tekstu?

— ruakh

@ruakh thanx .. Rektyfikowany ..

— Sukrit Gupta

0

Po pierwsze, unikaj skrótu.

Po drugie, jeśli skrót jest bardzo dobrze znany, zalecam stosowanie futerału na wielbłąda.

To dlatego, że nie musisz brać pod uwagę tego znaczenia. traktuj to jak normalne słowo

— Sungguk Lim
źródło