Errori di ortografia intenzionali per evitare parole riservate

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

Sono anche completamente d'accordo con il secondo punto. Assegnare un nome a una variabile class , anche se lo si potesse fare, sarebbe altrettanto negativo che nominarlo tmp o a . Che tipo di lezione? Una classe di cosa? I nomi dovrebbero essere descrittivi.

La Guida allo stile di Python richiama specificamente questo problema e suggerisce:

If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling.

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

Odore di codice.

string stringVariable = "";

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

class Klass

Stesso problema

string UserNameString = "bmackey"

Il codice precedente non dovrebbe richiedere la stringa di parole chiave aggiunta al nome della variabile. Se ti ritrovi 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 si intende la lingua-meccanica o la variabile. Con questo in mente, ciò implica che si aspettano che le persone abbiano bisogno di una variabile come una parola riservata.

Passando attraverso l'origine 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 male, ma gli altri 9 della tua squadra pensano che sia buono, allora devi mordere il proiettile e accettarlo. Finché c'è comunicazione su ciò che è ok e ciò che non lo è, e stai sollevando problemi che vedi come li vedi, dovrebbe andare bene.

Il modo in cui il tuo team pensa allo stile del codice è più importante della mia opinione o di qualsiasi altro in questo post . Questo vale per questo e per qualsiasi altra decisione sullo stile del codice che potresti avere.

Errori di ortografia intenzionali per evitare parole riservate sono 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 ortografici incongruenti competano all'interno del codice, il che rende il codice più difficile da scrivere e più difficile da leggere.

• Le parole riservate si riferiscono alla lingua utilizzata per risolvere il problema, non al problema stesso. Un nome di variabile dovrebbe puntare a un concetto correlato al problema.

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

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

Class clazz ha l'odore di "Non mi sono preoccupato di provare a trovare un buon nome". Una variabile rappresenta sempre qualcosa e un buon nome lo descrive. Mi rifiuto di immaginare che clazz , ad esempio, in qualsiasi circostanza sia il miglior nome possibile. È un riferimento a una classe - > class_reference, is is una copia di un oggetto di classe - > class_copy, ecc. È possibile anche eliminare "class" e utilizzare 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 di destinazione su cui eseguire il controllo, quindi

checkMemberAccess(Class<?> target, int which)

sarebbe molto meglio descrivere per cosa è usato il parametro di quanto non lo farà Clazz.

Se usano un nome riservato per una variabile, è una variabile con un nome non valido. Anche se si tratta di un nome legittimo, come Class for software in aula.

Le variabili con un nome errato sono un segno di codice scarsamente pensato o casuale - fai attenzione ad altri trucchi nel pezzo di software che stai mantenendo.

Penso che errori di ortografia o abbreviazioni intenzionali siano una buona idea se usati con attenzione e coerentemente .

Considera 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 non per usare gli errori ortografici in cui potresti essere tentato.

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

Nel primo caso, è abbastanza ovvio che la pigrizia è raramente una buona politica per creare 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 fare questo 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 di Class klass durante la riflessione, in cui lavori effettivamente con un'istanza della classe Class .

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

Per le variabili locali e gli argomenti formali, non ha importanza.

Qualsiasi nome va bene purché non sia intenzionalmente fuorviante o fastidioso da distrarre. 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 inserirò solo l'espressione:

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

La lunghezza di un nome di variabile dovrebbe 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 chiedo se mi sia sfuggito qualcosa quando vedo la parola klass . (Intendevano class , o intendevano il pirata?) Almeno per me, tutti gli errori ortografici che riconosco sono irritanti.

Per i pochissimi casi, in cui la parola riservata è davvero l'unica cosa significativa che si conosce della variabile, vorrei usare le seguenti alternative:

• Se si tratta di un argomento di funzione, utilizza aClass anziché class .

• Se è una variabile locale o membro, utilizza myClass anziché class .

• Se si tratta di un accessorio, usa getClass() anziché class() .

Ovviamente, il prefisso aggiunto è piuttosto inutile, e dovrebbe essere usato sempre come ultima risorsa, di conseguenza. 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 di codice per cose uniche, piuttosto che per parole comuni, dove troppo spesso troverai tutte le cose sbagliate e 1000 di esse. Ad esempio, ero proprietario di kzpg.com. Google che ora e vedrai solo pochi colpi. È unico e quindi molto rintracciabile.

Ma a una misura penso che questa domanda sia più di opinione che di sostanza. Sono cresciuto personalmente su Forth, dove si parlava solo di parole e di molte di esse. Uno ha imparato a diventare molto creativo per salvare le dita. Alla fine ho avuto 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.