Dovresti creare una funzione booleana che faccia l'opposto di una funzione esistente solo così il suo scopo è chiaro?

No, certamente non la migliore pratica a tutti. Tutte le lingue che ho mai usato hanno un operatore "non", quindi usalo. È molto chiaro, molto facile da leggere e salva i metodi di scrittura essenzialmente duplicati.

es. il significato e l'intenzione del codice qui sotto mi sembra abbastanza chiaro:

if (!In(...)) 
{...}

Anche se ho visto un po 'di codice come questo:

if (NotIn(...))
{...}

Io penserei, "questo è probabilmente l'opposto di In() , ma se fosse perché non hanno appena scritto !In() ". Quindi, finirò per avere per controllare i documenti o il codice: (

Ovviamente non è sintatticamente sbagliato scrivere un metodo del genere, non è solo idiomatico (in qualsiasi lingua langua che abbia mai usato).

Modifica Come Amir menziona sui commenti, questo è il tipo di cosa che potrebbe essere trattata negli standard di codifica, insieme a come denominare un metodo (o una proprietà) che restituisce un valore booleano.

Nei linguaggi funzionali, questo può essere a volte conveniente per i predicati passati ad altre funzioni, ad es.

filter ('notElem' xs) ys

sembra più bello di

filter ((!) . ('elem' xs)) ys

Questo esempio di Haskell dimostra che le regole di sintassi possono costringere a scrivere 4 parentesi extra solo per una semplice negazione. Poiché la chiarezza diminuisce il troppo proporzionale al numero di parentesi, è bene avere notElem .

No, non dovresti assolutamente. Un operatore di negazione è sufficiente.

Tuttavia potresti voler prima pensare a quale sia l'uso più "popolare" di questa funzione - per chiedere una risposta diretta o per una risposta negativa. Quindi fai il controllo più utilizzato per impostazione predefinita.

Ad esempio, se hai un metodo Question.IsOpen() e osservi che lo stai principalmente chiamando insieme alla negazione come !Question.IsOpen() puoi invertirlo in Question.IsClosed() . Qui si nota come sia possibile trovare una parola separata per una situazione negata.

Finché si escludono a vicenda non dovresti. Dovresti comunque farlo, se avessi una logica a 3 valori (Vero, Falso, sconosciuto). Il che è tipico ad esempio in SQL .

link

Se ho una proprietà a cui sono vincolato nel dire un progetto mvvm in WPF, creo versioni esplicite di proprietà che sono l'opposto di altre. Però, preferisco usare simboli abbastanza dettagliati di quale sia il significato piuttosto che semplicemente anteporre "Not" davanti al nome della proprietà opposta. Immagino che se stai parlando di funzioni e di codice puro probabilmente sarei d'accordo sul fatto che dovresti invece usare gli operatori non appropriati.

Direi che dipende. Ruby, ad esempio, lo incoraggia a causa della leggibilità / chiarezza > tutto il resto. È prassi comune in un'app Rails avvolgere l'operatore di negazione in un metodo per rendere il codice più simile all'inglese se non "fluisce" in modo naturale utilizzando la parola chiave unless .