Czy jest jakiś powód, aby pisać słowo kluczowe „prywatne” w języku C #?

O ile mi wiadomo, privatejest domyślnym wszędzie w C # (co oznacza, że jeśli nie piszę public, protected, internal, itd. To będzie privatedomyślnie). (Proszę, popraw mnie jeśli się mylę.)

Więc jaki jest powód napisania tego słowa kluczowego lub dlaczego w ogóle istnieje ono dla członków?

Na przykład, gdy program obsługi zdarzeń jest generowany automatycznie, wygląda to tak:

private void RatTrap_MouseEnter(object sender, CheeseEventArgs e)
{

}

Ale dlaczego w ogóle pisze prywatne, jeśli jest to domniemane i domyślne? Tylko po to, aby początkujący programiści (którzy nie wiedzą, że jest to domyślne C #) wiedzą, że jest prywatny? A może jest różnica w kompilatorze?

Ponadto istnieje przypadek, w którym pisanie „prywatny” (samo) będzie zmieniać dostępności elementu?

AFAIK, private jest domyślne wszędzie w C # (co oznacza, że ​​jeśli nie napiszę publicznego, chronionego, wewnętrznego itp., Będzie domyślnie prywatne). (popraw mnie, jeśli się mylisz).

To nie jest prawda. Typy zdefiniowane w przestrzeni nazw (klasy, struktury, interfejsy itp.) Będą domyślnie wewnętrzne . Ponadto elementy członkowskie w różnych typach mają różne domyślne ułatwienia dostępu (takie jak publiczne dla elementów członkowskich interfejsu). Aby uzyskać szczegółowe informacje, zobacz Poziomy ułatwień dostępu w witrynie MSDN.

Również,

Więc jaki jest powód napisania tego słowa kluczowego lub dlaczego w ogóle istnieje?

Określenie tego wyraźnie pomaga wskazać zamiar uczynienia tego typu prywatnym, bardzo wyraźnie. Pomaga to w utrzymaniu kodu w czasie. Może to pomóc innym programistom (lub tobie) wiedzieć, czy członek jest domyślnie prywatny, czy celowo itp.

AFAIK, prywatne jest domyślne wszędzie w C #

Niezupełnie - domyślnie jest to „najbardziej ograniczony dostęp dostępny dla tej deklaracji”. Na przykład dla typu najwyższego poziomu domyślną wartością jest internal; dla typu zagnieżdżonego wartością domyślną jest private.

Więc jaki jest powód napisania tego słowa kluczowego lub dlaczego w ogóle istnieje?

Wyraża to wyraźnie, co jest dobre z dwóch powodów:

• To sprawia, że ​​jest to jaśniejsze dla tych, którzy nie znają wartości domyślnych, jak na twoje pytanie (osobiście nigdy nie podobał mi się ten argument, ale pomyślałem, że warto o nim wspomnieć)
• Sprawia wrażenie, że celowo zdecydowałeś się uczynić go prywatnym, zamiast po prostu przejść z domyślnymi.

Jeśli chodzi o ostatnią część:

Co więcej, czy istnieje przypadek, w którym zapis „prywatny” (sam) zmieni dostępność członka?

Tak, za uczynienie połowy nieruchomości bardziej restrykcyjną niż druga:

// Public getter, public setter
public int Foo { get; set; }

// Public getter, private setter
public int Bar { get; private set; }

I wykorzystywane do przejść z domyślnych wszędzie mogłem, ale byłem przekonany (częściowo przez Eric Lippert), który czyni go wyczyścić, że już o tym myślał i postanowił zrobić coś prywatny jest dobrym pomysłem.

Osobiście żałuję, że nie ma sposobu na zrobienie tego również dla zapieczętowanych / nieopieczętowanych również dla deklaracji typu - prawdopodobnie nawet nie mają wartości domyślnej. Podejrzewam, że wielu programistów (łącznie ze mną, jeśli nie jestem ostrożny) pozostawia otwarte klasy tylko dlatego, że jest to mniej wysiłku niż ich zapieczętowanie.

privatedodaje wizualnego bałaganu. Tych, którzy nalegają, aby to wyjaśniało, zapytam: czy robisz to również z matematyką? Na przykład:

var answer = a + b / c;

Czy uważasz to za niejasne bez zbędnych nawiasów wokół b / c?

Zasada w C # jest bardzo prosta: domyślnie wszystko jest tak zbliżone do prywatnego, jak to tylko możliwe. Jeśli więc chcesz, aby coś było bardziej widoczne niż domyślne, dodaj modyfikator. W przeciwnym razie nie dodawaj do kodu niepotrzebnych słów kluczowych.

O ile wiem, prywatna jest domyślna wszędzie w C #

Jawne określenie jako prywatne oznacza, że wiesz, że jest ono prywatne. Nie tylko myśl, że tak jest, ponieważ o ile wiesz, jest to ustawienie domyślne. Oznacza to również, że ktoś, kto patrzy na kod, wie, co to jest.

Nie ma „Myślę, że tak”, „Jestem pewien, że tak jest” itd. Po prostu jest . I wszyscy są na tej samej stronie.

Nie jestem programistą C # . Gdybym musiał pracować z jakimś kodem, który nie został wyraźnie określony jako prywatny , prawdopodobnie założyłbym, że jest to kod wewnętrzny .

Nie lubię, gdy rzeczy są ustawione domyślnie. Nigdy nie jest tak jasne, jak wtedy, gdy są wyraźnie ustawione.

Czytelność - nie każdy może wiedzieć, że zachowanie prywatne jest domyślnym zachowaniem.

Zamiar - daje wyraźne wskazanie, że wyraźnie oznaczyłeś nieruchomość jako prywatną (z dowolnego powodu).

Czytelność, demonstracja intencji to dwa ważne powody, o których mogę pomyśleć.

Jednym z dobrych powodów, aby wyraźnie określić widoczność, jest to, że nie musisz zastanawiać się, jaki jest domyślny kontekst, w którym się znajdujesz.

Innym dobrym powodem jest to, że FxCop każe ci to zrobić.

Wiele osób (takich jak ja!) Regularnie programuje w kilku różnych językach. Mówienie wprost o takich rzeczach nie pozwala mi na zapamiętywanie wszystkich tajemniczych szczegółów wszystkich języków, w których programuję.

Powiedziałbym za spójność z czytelnością zakresu reszty klasy.