Perché vedo più convenzioni di denominazione booleani in cui "è" viene utilizzato come prima parola nella variabile (ad esempio, IsUserAdmin vs UserIsAdmin)? [chiuso]

Come ha detto @Joe nel suo commento, è ridondante inserire il nome dell'oggetto nel nome del metodo. Supponi di chiamare:

if (user.isUserAdmin()) {

È piuttosto sciocco, perché il nome del metodo ripete il nome della classe (probabilmente qualcosa come User , o forse una sottoclasse chiamata Admin ). A partire da is o are o can ha senso nel contesto immediato dell'oggetto su cui stai chiamando.

Tuttavia, ha senso quando si ricevono informazioni da un oggetto su un altro oggetto di cui è responsabile. Ad esempio:

if (user.ordersAreValid()) {

Allora diventerà un po 'confuso. areOrdersValid ha senso perché è sotto forma di domanda. D'altra parte, ordersAreValid diventa una frase quando combinato con una struttura di controllo come if o while (ad esempio "se gli ordini sono validi"). Mi chino verso il secondo, ma potrebbe essere più una questione di gusti.

Uno dei motivi per farlo è quello di aiutare con il completamento automatico. Ad esempio, le app di Windows Form hanno sofferto di un'inconsistente API di .NET Framework in cui non si sarebbe mai saputo se è necessario includere "è" o meno. Ad esempio, per verificare se una casella di controllo è selezionata, dovresti scrivere this.checkbox.Checked . In WPF, questo è stato modificato, e ora devi usare this.checkbox.IsChecked che è più facile da ricordare.

Detto questo, non vedo come AreOrdersClosed sarebbe migliore di OrdersAreClosed . Una possibile spiegazione potrebbe essere lo stesso completamento automatico: è più semplice trovare proprietà e campi booleani.

Ma questo può essere criticato:

• Se iniziamo a farlo, perché non usare anche la notazione ungherese? Poiché la notazione ungherese non deve essere utilizzata nella maggior parte delle lingue utilizzate oggi, non c'è motivo di usarla solo per i booleani.
• Le variabili booleane possono iniziare con is , are o can . Tre prefissi per lo stesso tipo sono troppi se l'unico motivo è un migliore completamento automatico. Se vogliamo essere coerenti, AreOrdersClosed deve essere IsOrdersClosed e CanResumeDownloads deve essere IsResumeDownloadsPossible , che è brutto.

Probabilmente le persone iniziano con le proprietà grammaticali formate come Is + <Adjective> , e quando si tratta dei rari casi di <Noun> + Is + <Adjective> , la mettono solo come Is + <Noun> + <Adjective> per avere un'API più uniforme.

Ora, ci sono alcuni casi in cui "è" può essere trovato tra due parole in un nome di una variabile, e non riesco a ricordare alcun caso valido da .NET Framework. In realtà, guardando i tuoi esempi, mi sento come se ci fosse un refactoring da fare:

• IsUserAdmin può essere IsAdmin , come suggerito dai commenti,
• AreOrdersClosed può anche essere rinominato in AreClosed o qualcos'altro a seconda del contesto. Ad esempio, se questo è un valore che indica se qualcuno non può aggiungere nuovi prodotti al carrello, preferirei creare una proprietà IsClosed o IsFinished a Cart o Order .

È solo un modo per restringere una ricerca in auto complete / Intellisense. Quando inizi a scrivere un condizionale, digitando "È" è un buon modo per trovare ciò che stai cercando senza dover scorrere tutto, quando non conosci il nome del membro che stai cercando.

L'unica ragione per cui facciamo questo per "È" e nient'altro è perché sappiamo che i membri booleani vengono spesso utilizzati nel contesto di un ramo o di un ciclo. Non è un caso che i booleani siano tra i pochi tipi in cui la maggior parte delle lingue ha così tante parole chiave e strutture speciali da riconoscere.

Sono sicuro che troveremmo più cose da notare con prefissi simili se potessimo capire quali sarebbero i contesti appropriati.