usa areFoo o isFoo?

Se parli di Java, potresti incontrare dei problemi perché i JavaBeans sono definiti con is<PropertyName> (vedi Spec Capitolo 8.3.2)

Penso che alcuni framework siano molto rigidi e utilizzino is<name> per impostare booleani per riflessione, quindi non troveranno are<name> .

Dovresti usare "è" o "sono" come appropriato per il numero di oggetti in questione. Stai ancora mantenendo la "buona forma" di porre una domanda con la variabile booleana. vale a dire. "è ... ?" o "sono ...?"

Quindi non vedo nulla di sbagliato nell'usare "sono" con un oggetto plurale.

Nei casi in cui la risposta non è immediata, le domande principali che dovresti porle sono:

• Rende il codice più leggibile ed espressivo rispetto all'intenzione?
• È probabile che un cambiamento futuro invaliderà il modo in cui si formula la domanda booleana?
• La risposta annulla la natura booleana della domanda?

Questa terza domanda è un po 'strana, quindi vorrei fare un esempio concreto. %codice%? viene risposto abbastanza chiaramente con " sì, è " o " no, non è ." Quando chiedi IsPointValid ? potenzialmente abbiamo un terzo caso di " parzialmente valido: alcuni sono, alcuni non sono ." Se hai quel terzo caso, usa un tipo di variabile diverso da un booleano.

Ricorda inoltre che la domanda booleana è un aiuto per l'espressività del codice. È non un tentativo di creare correttezza grammaticale all'interno del codice. Fintanto che non ti blocchi troppo su ArePointsValid rispetto a is allora il tuo codice andrà bene e gli altri capiranno l'intento.

Spesso trovi che ha un'alternativa all'essere. Nel tuo caso potresti optare per hasValidSetupParameters di conseguenza, il che ha perfettamente senso. Tuttavia, non fa parte delle specifiche JavaBeans menzionate in precedenza.

Parlerò contro usando isSetupParametersValid, per il seguente motivo: Il nostro obiettivo principale con i metodi di denominazione dovrebbe essere quello di rendere il codice leggibile. Ad esempio, in un codice del mondo ideale leggerebbe come frasi. Tornando al tuo esempio questo significa che le tue opzioni sono

object are setup parameters valid

vs.

object has valid setup parameters

Penso che tu capisca cosa sto suggerendo.

Il problema con "sono" come prefisso è a cosa si applica? 'X è nello stato Y' è perfettamente chiaro a tutti, ma 'Xs nello stato Y' non è così chiaro - significa che sono tutti gli oggetti X in quello stato, o solo alcuni di essi? Cosa succede se solo alcuni di essi non sono nello stato corretto o tutti - hai bisogno di una risposta che dice "sì / no / parzialmente"?

Nei casi in cui ritieni che la grammatica inglese suggerisca di utilizzare come prefisso - ad esempio "sono validi parametri di configurazione", puoi facilmente riformulare la domanda in cui "la configurazione è valida", effettuando una query su più elementi in un risposta sì / no a una singola raccolta.

Però è piuttosto semplice, e lo standard considerato è usare 'is', quindi direi che continuate a usare e non preoccuparti di tutto.

Is the lack of use of "are" in boolean methods, simply an arbitrary convention or a side-effect of using best practices.

La risposta dipende in parte dal linguaggio e dal framework che stai utilizzando.

Ad esempio, in Objective-C dovresti sempre usare foo o isFoo e mai areFoo perché i primi due sono compatibili con Codifica valore-chiave mentre l'ultimo non lo è.

Nei contesti orientati agli oggetti, metodi come isFoo sono comuni mentre metodi come areFoo non sono perché la cosa a cui si applica il test è solitamente l'oggetto che riceve il messaggio. Dato che di solito puoi chiamare un metodo solo su un oggetto alla volta, il verbo plurale è non ha senso.

Nella tua domanda, sembra che tu voglia chiedere all'oggetto se alcuni set di valori che stai trasmettendo siano validi invece di chiedere informazioni sull'oggetto stesso. Potrebbe essere più convenzionale, e quindi più facile da comprendere per gli altri, se si trasforma quella domanda in una domanda sul ricevitore. Invece di myObject.areParemetersValid(...) , considera myObject.isAbleToUseParameters(...) o più semplicemente myObject.canUseParameters(...) .

Per riassumere, la convenzione non è arbitraria, deriva dal fatto che la maggior parte dei linguaggi OO consente di chiamare un metodo su un solo oggetto alla volta.

La tua domanda fa un'ipotesi limitante. Facciamo un passo indietro qui. Perché non solo bool ParametersValid (o Boolean parametersValid )? È perfettamente sufficiente secondo me.

Tutti quei isThis , isThat mi ricordano quel segretario aneddotico che archivia tutto sotto "T" ("l'affitto", "le fatture" ecc.):)

Se la necessità di tali prefissi diventa acuta (non è immediatamente evidente ciò che parametersValid rappresenta), potrebbe indicare che la progettazione dell'oggetto è semplicemente negativa.

L'uso dei prefissi è una sorta di notazione ungherese e, in questo contesto, è il sostituto dell'uomo povero di un adeguato refactoring e divisione della classe.

Riguardo alle critiche di Caleb :

OP's question is about the particular isFoo style of naming boolean methods which is conventional in a number of languages

Forse, ma la domanda non è contrassegnata con il nome di un particolare linguaggio di programmazione, quindi la considero come indipendente dalla lingua.

suggesting a different convention is not useful.

Non sto davvero suggerendo una convenzione diversa, sto piuttosto dicendo che non è necessario seguire alcuna stretta convenzione in questo aspetto, a parte il buon senso e una chiara denominazione in generale.

L'idea che sia necessaria una stretta convenzione è ciò che ha creato il problema dell'OP in primo luogo.

Se adotta il mio punto di vista, il suo problema va via, quindi la mia risposta è (potenzialmente, ovviamente - come ogni altra risposta) utile.

Scelgo la semplicità. Vedi BackgroundWorker class in .NET. Ha una proprietà CancellationPending - non IsCancellationPending , non WasCancelled o HasBeenCancelled ecc. Basta che sia semplice!

Furthermore, the convention you suggest is ambiguous by your own admission ("...it's not immediately obvious...")

L'ho scritto in modo condizionale, l'hai preso fuori dal contesto. Se non è immediatamente ovvio ... implica che la classe è troppo grande, che è un problema a sé stante.

Finally, the is in isFoo should be read as a verb; this use of prefixes is distinct from any Hungarian notation and in any case it's not necessarily indicative of poor design.

Verbo o non verbo, riflette solo il fatto che il tipo restituito è booleano, che è ridondante.

Ecco perché ho detto che è una notazione ungherese di sorta .