Errori ortografici intenzionali per evitare parole riservate

Vedo spesso un codice che include errori ortografici intenzionali di parole comuni che nel bene e nel male sono diventate parole riservate:

• klasso clazzper classe :Class clazz = ThisClass.class
• kountper il conteggio in SQL:count(*) AS kount

Personalmente trovo che ciò riduca la leggibilità. Nella mia pratica non ho trovato troppi casi in cui un nome migliore non avrebbe potuto essere usato - itemClasso recordTotal.

Un esempio di JavaDocs per Class lo mostra nei parametri:

 public <U> Class<? extends U> asSubclass(Class<U> clazz)

Questo mostra un caso d'uso ragionevole?

IMHO, questa è una pessima idea. Le parole riservate sono riservate per un motivo e ciò riduce la leggibilità.

Sono anche pienamente d'accordo con il tuo secondo punto. Denominare una variabile class, anche se tu potessi farlo, sarebbe altrettanto male che nominarla tmpo a. Che tipo di classe? Una classe di cosa? I nomi dovrebbero essere descrittivi.

La Guida allo stile di Python evidenzia questo problema in modo specifico e suggerisce:

Se il nome del tuo attributo pubblico si scontra con una parola chiave riservata, aggiungi un singolo trattino finale al nome del tuo attributo. È preferibile un'abbreviazione o un'ortografia corrotta.

Questa sembra una regola generale piuttosto buona, supponendo che non sia in conflitto con la semantica di un particolare linguaggio.

Odore di codice.

string stringVariable = "";

Il codice sopra non mi dice nulla sull'uso previsto delle variabili.

class Klass

Stesso problema

string UserNameString = "bmackey"

Il codice sopra riportato non dovrebbe richiedere la stringa di parole chiave aggiunta al nome della variabile. Se ti trovi a dover identificare i tipi in base al nome della variabile, il tuo codice è troppo lungo. Condensare-refactoring.

Personalmente, penso che sia un'opzione perfettamente valida per il tuo stile di codice.

Sono parole riservate, quindi il compilatore non deve decidere se intendevi il meccanico del linguaggio o la tua variabile. Con questo in mente, implica che si aspettano che le persone abbiano bisogno di una variabile come una parola riservata.

Scorrendo la fonte in bundle con JDK 1.6 R21, trovo 917 occorrenze di "clazz". Apparentemente, hanno pensato che fosse uno stile accettabile.

Come si sente la tua squadra al riguardo? Se pensi che sia cattivo, ma gli altri 9 ragazzi della tua squadra pensano che sia buono, allora devi mordere il proiettile e accettarlo. Finché c'è comunicazione su ciò che va bene e cosa non lo è, e stai sollevando problemi che vedi come li vedi, dovrebbe andare bene.

Le opinioni del tuo team sullo stile del codice sono più importanti della mia opinione o di chiunque altro in questo post . Questo vale per questa e tutte le altre decisioni sullo stile di codice che potresti avere.

Errori ortografici intenzionali per evitare parole riservate è una cattiva idea.

• Gli errori di ortografia sono difficili da distinguere dall'ortografia corretta, pertanto rendono il codice più difficile da leggere.

• Gli errori di ortografia sono difficili da ricordare, quindi è probabile che diversi errori di ortografia siano in concorrenza all'interno del codice, il che rende il codice più difficile da scrivere e più difficile da leggere.

• Le parole riservate si riferiscono al linguaggio utilizzato per risolvere il problema, non al problema stesso. Un nome di variabile dovrebbe indicare un concetto correlato al problema.

È quindi meglio scegliere un nome descrittivo alternativo o, se non esiste un'alternativa soddisfacente, qualificare la parola riservata come in:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}

Class clazzodora di "Non mi sono preoccupato di cercare di trovare un buon nome". Una variabile rappresenta sempre qualcosa e un buon nome lo descrive. Mi rifiuto di immaginare che clazzad esempio in ogni caso sia il miglior nome possibile. È un riferimento a una classe -> class_reference, is è una copia di un oggetto di classe -> class_copy, ecc. Eventualmente anche rilasciare "class" e usa semplicemente la parola descrittiva, ad es.

java.lang.SecurityManager.checkMemberAccess(Class<?> clazz, int which)
Parameters
    clazz -- the class that reflection is to be performed on.

Qui clazz è la classe target su cui deve essere eseguito il controllo, quindi

checkMemberAccess(Class<?> target, int which)

descriverebbe meglio a cosa serve il parametro di quanto mai clazz.

Se usano un nome riservato per una variabile, è una variabile mal nominata. Anche se è un nome legittimo, ad esempio Class per il software di classe.

Le variabili mal nominate sono un segno di codice mal concepito o casuale - attenzione agli altri aspetti del software che si sta mantenendo.

Penso che errori ortografici o abbreviazioni intenzionali siano una buona idea se usati con cura e coerenza .

Considerare in Java:

class X { public X() { } }
X x = new X();
x.getClass;  // Wha?  How does "get" help anything?
x.class;     // Best, but requires more lexer/parser work
x.klass;     // At least as good as getClass
x.clazz;     // Same

Il posto dove usare gli errori ortografici è dove la parola riservata è chiaramente la parola migliore per il lavoro. Ci sono due posti in cui non puoi usare l'ortografia in cui potresti essere tentato.

1. Non hai voglia di pensare a un buon nome
2. Vuoi solo una variabile fittizia e non ha bisogno di un nome descrittivo

Nel primo caso, è abbastanza ovvio che la pigrizia è raramente una buona politica per la creazione di un codice di qualità. Nel secondo caso, scegli una variabile molto breve. Questo è ciò che i matematici fanno sempre e i programmatori fanno per gli indici. Non c'è motivo di limitarsi a farlo per gli indici se è davvero solo una variabile fittizia:

boolean isMyName(String testName) { return myName.equals(testName); }
boolean isMyName(String s) { return myName.equals(s); }

Date nextMeeting(Klass klass) { return /* something */ }
Date nextMeeting(Klass k) { return /* something */ }

Non perdi nulla con nomi di variabili brevi quando il metodo o la struttura del codice ti dice cosa deve essere lì.

Ho visto usi legittimi Class klassquando si fa riflessione in cui si lavora effettivamente con un'istanza della Classclasse.

Vedo spesso un codice che include errori ortografici intenzionali di parole comuni che nel bene e nel male sono diventate parole riservate:

klass o clazz per la classe: Class clazz = ThisClass.class

kount per conteggio in SQL: count (*) AS kount

Personalmente trovo che ciò riduca la leggibilità. Nella mia pratica non ho trovato troppi casi in cui un nome migliore non avrebbe potuto essere usato - itemClass o recordTotal.

Tuttavia, è così comune che non posso fare a meno di chiedermi se sono l'unico? Qualcuno ha qualche consiglio o ancora meglio, citati consigli di programmatori di tutto rispetto su questa pratica?

Per variabili locali e argomenti formali, non importa.

Qualsiasi nome va bene purché non sia intenzionalmente fuorviante o fastidiosamente fastidioso. Nel tuo esempio:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

non importa se la singola variabile locale è "clazz" o "klass" o "cls" o semplicemente "c". Probabilmente aggiungerei semplicemente l'espressione:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

La lunghezza di un nome di variabile deve essere correlata all'ambito della variabile. Per le variabili locali in metodi brevi (e dovrebbero essere tutte brevi), i nomi molto brevi vanno bene.

Penso che gli errori ortografici siano sempre una cattiva idea. Non è carino per i tuoi lettori. Io, per esempio, mi chiederei se mi mancasse qualcosa quando vedo la parola klass. (Intendevano classo intendevano il pirata?) Almeno per me, tutti gli errori di ortografia che riconosco sono irritanti.

Per i pochissimi casi, in cui la parola riservata è davvero l'unica cosa significativa conosciuta sulla variabile, utilizzerei le seguenti alternative:

• Se si tratta di un argomento di funzione, utilizzare aClassinvece di class.

• Se si tratta di una variabile locale o membro, utilizzare myClassinvece di class.

• Se si tratta di un accessorio, utilizzare getClass()invece di class().

Ovviamente, il prefisso aggiunto è piuttosto inutile e, di conseguenza, dovrebbe essere usato solo come ultima risorsa. Ma almeno non interferisce con il parser mentale del tuo lettore ed è un modo sicuro per evitare parole riservate.

Uno dei vantaggi dell'ortografia creativa è la migliore capacità di ricerca. Penso che sia molto più facile fare una ricerca completa del codice per cose uniche, piuttosto che per parole comuni, dove troppo spesso troverai tutte le cose sbagliate e 1000 di esse. Ad esempio, possedevo kzpg.com. Google che ora e vedrai solo alcuni hit. È unico e quindi molto rintracciabile.

Ma in una certa misura penso che questa domanda sia di opinione più che di sostanza. Sono cresciuto personalmente su Forth, dove si trattava solo di parole e molte di esse. Uno ha imparato a diventare molto creativo per salvare le dita. Alla fine avevo circa 640.000 caratteri, più o meno nella mia base di origine. Quindi mantenere le parole brevi era importante per portare a termine il lavoro.