Jak nazwać swoje prywatne zmienne w C #? [Zamknięte]

Jaka jest najlepsza praktyka, najczęściej akceptowane konwencje nazewnictwa dla zmiennych prywatnych w języku C #?

1. private int myInteger;
2. private int MyInteger;
3. private int mMyInteger;
4. private int _myInteger;
5. private int _MyInteger;
6. Tajemnicza inna opcja

Z którego korzystasz i dlaczego? (Moja firma jest dość nowa w C # i chciałbym wybrać najbardziej akceptowaną w branży metodę, aby spróbować uzyskać dostęp do naszego standardu kodowania.)

Wytyczne dotyczące projektowania klasy MSDN http://msdn.microsoft.com/en-us/library/ta31s3bc.aspx zaleca opcję 1 - myInteger.

Zawsze używałem tego stylu. Osobiście nie lubię postaci _.

Korzystam z opcji 4 powyżej:

private int _myInteger;

Lubię mieć pewne oznaczenie zakresu w moich nazwach zmiennych, a do tego celu wystarcza podkreślenie. Jest również dość łatwy do odczytania.

Używam następującego schematu nazewnictwa:

• 1st (myInteger) dla zmiennych o zasięgu lokalnym
• 2nd (MyInteger) dla właściwości publicznych
• 4. (_myInteger) dla zmiennych prywatnych

Myślę, że opcja 4 jest naprawdę najbardziej czytelną opcją. Pomaga ci to zrobić:

public Person(string name, int age) 
{
    this.name = name;
    this.age = age;
}

Dzięki temu wszyscy członkowie prywatni są bardziej zauważalni. W poniższym przykładzie, skąd, u diabła, agepochodzi? Bez thiskwalifikatora trudniej powiedzieć.

private void Method()
{
    var x = 2;
    var y = age + x;
}

Jest to o wiele łatwiejsze do zrozumienia:

private void Method()
{
    var x = 2;
    var y = _age + x;
}

Po pierwsze, PascalCasing jest zwykle zarezerwowany dla publicznych właściwości, stałych, metod itp. Klasy. Pominąłbym więc 2 i 5.

Po drugie, notacja węgierska jest odradzana w świecie .NET, więc (tak myślę) 3 jest już dostępna. Zakładając, że tak właśnie jest z 3.

To pozostawia z camelCasing i _camelCasing. Zazwyczaj używam _camelCasing dla zmiennych klas, a zwykły stary camelCasing dla zmiennych o zakresie do metody lub węższej. Obudowa wielbłąda jest przyjętym standardem stosowanym dla argumentów metod, nazw zmiennych chronionych / prywatnych i zmiennych w ramach metody lub węższym zakresie.

Lubię też dodawać znaki podkreślenia, aby moje prywatne zmienne były zgrupowane w mojej inteligencji. Robię to jednak tylko w przypadku zmiennych o określonym typie. Zmienne zadeklarowane w ramach metody lub węższego zakresu pomijam podkreślenie. Ułatwia rozdzielenie ich i utrzymanie razem mniej używanych zmiennych.

private int integer

Jeśli pomylisz się między zmiennymi składowymi a zmiennymi lokalnymi w zakresie metody, prawdopodobnie konieczne będzie zrefaktoryzowanie.

Uważam, że najlepszym sposobem na to (w każdym razie w C # /. Net) jest kombinacja 2 i 6:

private int MyInteger { get; set; }

Teoretycznie nie ma tu żadnej zmiennej, ale wygląda i działa jak zmienna instancji prywatnej. Jeśli musimy dodać do tej wartości logikę biznesową (jest to wartość całkowicie wewnętrzna, więc możemy zrobić wszystko, co chcemy), to jest już dla nas „własność”. Gorący parowy puchar wygranej!

Robię opcję nr 4, ponieważ tak wygląda SSCLI, ale szczerze mówiąc, nie obchodzi mnie zbytnio nazywanie zmiennej prywatnej. Publiczna to inna historia.

BTW zapomniałeś m_MyInteger

Nie nazwałbym tego „moim” niczym!

Ale powiedziałbym

class C
{
     int VariableName { get; set; }
}

dość często jest to przyjemniejsze niż posiadanie wyraźnych zmiennych. Gdybym miał jawną zmienną prywatną, nazwałbym jąint _variableName;

W C ++ często używam _, ponieważ często zmieniam edytory, co nie pozwala mi sprawdzić, czy jest prywatny.

W przypadku C # zwykle zostawiam _, ponieważ Visual Studio pozwala mi sprawdzić, czy jest prywatny.

Zwykle używam do tego celu Camel Case.

Używam 4 ( private int _myInteger;), ponieważ:

private int myInteger;

Tak nazywam moje zmienne lokalne.

private int MyInteger;

Tak nazywam stałe.

private int mMyInteger;

To nie jest styl C #.

private int _MyInteger;

To wygląda dziwnie.

z podkreśleniem.

Bill Wagner wyjaśnia, dlaczego w Effective C # . Ale nigdy nie nazwałbym liczby całkowitej moją liczbą całkowitą , lepiej coś takiego jak _age lub _length. Dołączanie TypeName do nazwy instancji jest okropną praktyką. Nazwy powinny być zrozumiałe, a ponieważ C # jest typem, typy można zawsze znaleźć.

Musisz podać bardziej konkretny przykład, ale:

private int count, private int badFileCount ,private static readonly int ReconnectAttemptsLimit

Nawiasem mówiąc, otrzymujesz to wszystko ZA DARMO, gdy instalujesz i zaczynasz korzystać z najnowszych i najlepszych MSFT Stylecop.

Wybieram opcję 5: private int _MyFoo

Nie widzę jednak żadnej rzeczywistej przewagi konkurencyjnej nad _myFoo.

Użyj camelCasing dla zmiennych prywatnych takich jak myInteger

Rozważ poprzednie, _jeśli zmienna jest kopią zapasową właściwości w celu zmniejszenia nieporozumień -
Zmienna _myPropertydla właściwościMyProperty

Mam ReSharper nazwać moje zmienne, nie tylko moje, ale wszyscy inni też to robią. Projekt zapewnia dużą spójność.

Juval Lowy's IDesign C # Coding Standard jest dość popularny. Ten standard zaleca poprzedzanie zmiennych prywatnych członków znakiem „m_” (opcja 6). Tak właśnie robimy w naszym zespole.

private int m_myInteger;

Opcja 4 ( _myInteger) jest dopuszczalną odmianą tego standardu.

Nie podobało mi się zalecenie MSDN ( myInteger), ponieważ utrudnia odróżnienie członka prywatnego od zmiennej lokalnej. Ich zalecenie oczywiście rozwiązuje ten problem, kwalifikując członków prywatnych this, co wydaje mi się zbędne.