Come faccio a indirizzare efficacemente il feedback di revisione del codice sui nomi di classi e metodi senza un suggerimento per un nome migliore o alternativo?

Questo è un problema di comunicazione tra te e il revisore. Una revisione del codice non è a senso unico "lo farai in questo modo o altro" nella discussione sul codice. È un'opportunità per molti altri sviluppatori sul tuo sito di vedere quali, se possibile, potrebbero utilizzare miglioramenti. Il più delle volte, durante le revisioni del codice di altri sviluppatori, imparo qualcosa di nuovo.

Se il tuo revisore non ha un esempio concreto di come il nome della tua classe / funzione / metodo possa essere nominato, allora non appartiene alla revisione. Chiedi al revisore per un esempio che sarebbe appropriato.

Se sei il revisore e non sai cosa sta facendo la routine, chiedi allo sviluppatore cosa fa il codice da una prospettiva di alto livello. Guida / istruisci su una risposta accettabile per entrambi.

In entrambi i casi, dovrebbe essere un punto di discussione che come revisore guidi o come riesaminato.

Hai due problemi. Uno è che hai difficoltà a nominare le cose. L'altro è che hai difficoltà a comunicare riguardo a cosa c'è di sbagliato in un nome. I tuoi colleghi che stanno leggendo il codice potrebbero condividere questa difficoltà, oppure potrebbero presumere che la precisione non sia necessaria perché pensano che tu possa capirlo da solo. In ogni caso, imparare a nominare in un modo più obiettivo ti aiuterà non solo con i nomi, ma anche con l'aspetto della comunicazione.

Ci sono libri con interi capitoli sul tema della denominazione e una moltitudine di siti web che discutono di questi capitoli. Controlla Pulisci codice , Codice completo e < a href="http://amzn.com/0201485672"> Refactoring e fai ricerche su google come "Nomi di codice puliti". La denominazione è certamente un'abilità che può essere migliorata utilizzando misure oggettive.

Un riepilogo di alto livello di Clean Code dal sommario:

• Utilizza nomi che rivelano l'intenzione. Ad esempio, elapsedTimeInDays anziché d .
• Evita la disinformazione. Ad esempio, non utilizzare accountList se non è un List .
• Fai distinzioni significative. Ad esempio, non utilizzare ProductInfo e ProductData per indicare cose diverse.
• Utilizza nomi pronunciabili.
• Utilizza nomi ricercabili. Nessun nome a una sola lettera (tranne che come i locali in metodi brevi) o valori letterali numerici.
• Evita codifiche come ungherese, ecc.
• Evita la mappatura mentale. Non fare in modo che il programmatore traduca il vero significato nella sua testa.
• Le classi dovrebbero avere nomi di nomi di nomi o nomi.
• I metodi dovrebbero avere nomi di espressioni verbali o verbali
• Non essere carino.
• Scegli una parola per concetto. Ad esempio, non hai fetch , retrieve e get significano le stesse cose in diverse classi.
• Non fare il gioco di parole. Ad esempio, non utilizzare add per indicare cose diverse in classi diverse.
• I termini di utilizzo con cui i programmatori hanno familiarità, come i nomi dei modelli.
• Utilizza termini familiari per le persone che conoscono il dominio del problema.
• Aggiungi contesto significativo. Ad esempio, usa addressState invece di solo state se non puoi facilmente capire che tipo di stato proviene dal contesto.
• Non aggiungere un contesto gratuito. Ad esempio, accountAddress e customerAddress sono nomi validi per le istanze, ma non per le classi, che dovrebbero essere appena chiamate Address .

Per trovare un nome migliore, devi prendere il tempo per capire cosa fanno le classi e i metodi. Penseresti che durante una revisione del codice, sarebbero in grado di capirlo, ma a quanto pare guardano i nomi e si fermano proprio lì. Non possono dirti cosa manca o più preciso.

Sembra che la tua unica risposta sia, "Questa classe è Foo perché è un foo che è un _ . Cos'altro potrei chiamarlo?" Se non riescono a darti una risposta, devi solo lasciarla.