Widziałem zbyt wiele kodu C# i C++, gdzie konwencja nazw zmiennych wydaje się prosić programistów o zapisywanie nazw zmiennych za pomocą podkreślenia przed tekstem zmiennej. e.gr.dlaczego C# i C++ używają konwencji kodowania _ <variableName>?
int? _countMoney;
Jakie są przesłanki uzasadniające tę konwencję?
W języku C# zwykle poprzedzam prefiksem _ pól prywatnych, ale nigdy zmiennych lokalnych. Uzasadnieniem tego jest to, że kiedy potrzebuję zmiennej prywatnej, wpisz _, a Intellisense filtruje listę i łatwiej ją znaleźć. W ten sposób mogę również odróżnić zmienne prywatne od lokalnych i nie muszę już wpisywać pól klasy this.variablename, ale po prostu _variablename.
To prosty sposób na identyfikację prywatnych zmiennych członków.
Podobnie jak wszystkie inne konwencje, chodzi o to, aby łatwiej było zrozumieć kod.
Widziałem to jako konwencję dla prywatnych pól - w takim przypadku bardzo łatwo zauważyć, że używane jest prywatne pole.
Możesz zadać to samo pytanie na temat hungarian notation.
Joel napisał interesującą obronę notacji węgierskiej: http://www.joelonsoftware.com/articles/Wrong.html –
Kluczem jest używanie ** Apps węgierski ** notacja, a nie ** Systemy węgierskie **! – CaffGeek
Chociaż osobiście nie jestem fanem węgierskiej notacji, jeśli używa się go do opisania wartości zmiennej, myślę, że jest znacznie bardziej akceptowalna.To jest, gdy ludzie używają go do oznaczenia czegoś takiego, jak typ zmiennej, który moim zdaniem jest niewłaściwie używany. W artykule Joela mówi o używaniu prefiksu "us" do oznaczenia "niebezpiecznych ciągów". Twierdzę, że w nowoczesnym języku, takim jak C#, jeśli chcesz użyć takiego prefiksu, kod byłby bardziej przejrzysty, gdybyś rozszerzył prefiks "nas" na "niebezpieczny". –
Czasami ludzie robią to w zmiennych członkowskich, aby odróżnić je od zmiennych lokalnych. Jeśli masz bezpośredni dostęp do zmiennej podkreślenia, być może powinieneś używać gettera/ustawiającego do uzyskiwania dostępu.
Co jest nie tak z tą odpowiedzią? Uważam, że punkt jest całkowicie poprawny. – Lazer
Jak powiedzieli inni, konwencja nazewnictwa pomaga odróżnić zmienne składowe od lokalnych. Daje to dwie główne zalety:
Zapobiega nazewnictwa starcia. Potrafię napisać konstruktora takiego:
SomeObject(int foo, int bar)
{
_foo = foo;
_bar = bar;
}
w ten sposób, nie trzeba wymienić argumenty new_foo czy coś takiego.
W C++ przynajmniej możesz napisać konstruktor w następujący sposób: 'SomeObject (int foo, int bar): foo (foo), bar (bar) {}' i "poprawna" rzecz. –
@Oli: Co nie musi oznaczać, że powinieneś to robić ... – sbi
Prawda. Jest to coś, czego nauczyłem się w C# dni (gdzie listy inicjatora członków nie są dozwolone, IIRC). –
Nie należy używać _ jako przedrostka w C++. Nazwy zaczynające się od _ są zarezerwowane dla kompilatora.
Najczęstszym prefiks C++ to m_ (tak jak w „członek)
C# jego bardzo powszechne użycie _.
Na moim miejscu, gdzie robimy równą ilość C++ i C# możemy zawsze wykorzystać M_ być spójne
Nie, w C++ nazwy zaczynające się od _Uppercase są zarezerwowane. _wolne sprawy są w porządku. – Detmar
@Detmar: Właściwie [jest to bardziej skomplikowane] (http://stackoverflow.com/questions/3650623/trailing-underscores-for-member-variables-in-c/3651336#3651336), ale obaj nadal punkt. – sbi
ze standardu "Każda nazwa zaczynająca się od podkreślenia jest zarezerwowana dla implementacji do użycia jako nazwa w globalnej przestrzeni nazw". Teoretycznie możesz sobie z tym poradzić, ale po co jeździć na krawędzi? – pm100
Microsoft wytyczne dla państw nazewnictwie określa, że nie należy używać prefiksów dla pól.
Nie używaj prefiksu dla nazw pól. Na przykład nie używaj g_ lub s_ do odróżniania pól statycznych od niestatycznych.
Możesz przeczytać wytyczne firmy Microsoft dotyczące nazw here. To dotyczy oczywiście C#.
to wciąż bardzo powszechna praktyka, która sprawia, że mnóstwo sensu ... –
Osobiście nie lubię praktyki używania prefiksu. Twoje IDE powinno wyjaśnić ci, co jest lokalne, a co jest członkiem. Jest to oczywiście zależne od osobistych upodobań (lub standardów kodowania projektów), ale ta odpowiedź daje +1. – rmeador
Jest to jedna z niewielu wskazówek, z którymi się nie zgadzam. Używam 'm_' i' s_' do rozróżniania między instancjami i polami statycznymi. Jest to dla mnie ważne, ponieważ należy założyć, że dostęp do pól statycznych można uzyskać za pomocą wielu wątków i jako taki powinieneś zadbać o ochronę przed problemami z wątkami. Użycie prefiksów w ten sposób ułatwia szybkie sprawdzenie, czy występują jakieś problemy. Konwencję tę zaproponował Jeffery Richter, który właśnie miał głos w opracowywaniu tej wytycznej. Musiał stracić na tym konkretnym punkcie :) –
Coś, co zauważyłem przez programistów Java w środowisku Eclipse, gdy musiałem wykonywać prace w języku Java, nie podkreślą tam vars. Powód jest? Partie vars były oznaczone kolorami w IDE ... nie czułem potrzeby robienia tego, by tak rzec. Z przyzwyczajenia wynikało to naturalnie, ponieważ z łatwością znalazłem element członkowski VS IDE za pomocą jakiegoś wizualnego wskaźnika ... a podkreślenie było tym, że jest dość popularne. W rzadkich przypadkach musisz przyjrzeć się kodowi w jego najsurowszej formie ... tekst ... tego typu rzeczy pomagają ogromnie.
Nie jestem do końca pewien, co jest uzasadnieniem tej konwencji. Osobiście nie obchodzi mnie użycie jakiegokolwiek rodzaju prefiksu nazwy zmiennej do oznaczania zakresu zmiennej, ani nie zwracam szczególnej uwagi na użycie podkreśleń w nazewnictwie czegokolwiek. Co jest złego w używaniu słowa kluczowego "this" i przyjęciu konwencji nazw o niższych nazwach wielbłądów dla prywatnych instancji/zmiennych członkowskich?
public void IncrementFoo()
{
this.foo += 1;
}
To tylko 5 dodatkowych znaków do wpisania, ale jest bardzo jednoznaczne. Jeśli przyjęto niższą konwencję wielbłądów dla prywatnych zmiennych instancji, oznacza to od razu, że uzyskujesz dostęp do prywatnej instancji/zmiennej członkowskiej, i nie trzeba było używać przedrostka dowolnego do oznaczenia go .
Prefiks _ jest bardzo istotny w VB.NET, ponieważ nie rozróżnia wielkości liter. Kodujemy zarówno w C#, jak i VB.NET, i dla dobra wszystkich ludzi ważne jest, aby mieć takie same konwencje nazewnictwa w obu językach.
+1 także dla mnie, głównym pomysłem jest filtrowanie zmiennych. – Lazer
Robiłem to na długo przed intellisense, aby odróżnić zmienne członkowskie. Było to kontynuacją C++ dni i MS przy użyciu m_ dla zmiennych członkowskich –
Jeśli nie możesz określić, czy zmienna jest lokalna, czy nie w ciągu kilku sekund od spojrzenia na metodę, czy nie można argumentować, że twoja metoda mogła być zbyt skomplikowanym? Co do filtrowania IntelliSense, czy pisanie kodu dostosowanego do konkretnej cechy IDE jest naprawdę dobrym pomysłem? –