Denominazione: dovresti sacrificare la brevità per chiarezza?

Ad esempio, la seguente funzione scorre in un array che contiene il nome e gli errori di un campo di input. Lo fa controllando il nome del campo di convalida e quindi spingendo le informazioni di errore nell'array di campi non validi.

È meglio essere brevi e scrivere questo:

addInvalidField (field, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === field.name
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
},

O essere più specifico come questo?

addInvalidField (validatingField, message) {
  const foundField = this.invalidFields.find(invalidField => {
    return validatingField.name === invalidField.name
  })
  if (!foundField.errors.some(foundFieldError => foundFieldError.name === message)) {
    fouldField.errors.push({ name: message, message })
  }
},

Se la brevità può essere sacrificata per chiarezza, dovrebbe. Ma se la verbosità può essere sacrificata per chiarezza, ancora meglio.

addInvalidField (field, message) {
  const foundInvalidField = this.invalidFields.find(x => x.name === field.name)
  if (!foundInvalidField.errors.some(x => x.name === message)) {
    foundInvalidField.errors.push({ name: message, message })
  }
},

Quando una variabile vive solo fino a quando una riga può essere davvero molto breve. FoundInvalidFieldè usato in tre righe ed è al centro di questo lavoro. Merita un nome esplicativo.

Come sempre, il contesto è re.

In realtà favorisco il tuo primo esempio di codice.

È chiaramente evidente cosa fa il codice semplicemente leggendolo. Mantenendo il più piccolo possibile i nomi delle variabili, si rende il codice ancora più facile da leggere. Nomi di variabili più descrittivi sarebbero necessari solo se le funzioni fossero più lunghe, le variabili fossero più numerose e / o le variabili fossero utilizzate in un ambito di codice più ampio.

È perché hai mantenuto brevi le tue funzioni che puoi anche mantenere brevi i nomi delle tue variabili. A parità di altre condizioni, meno codice è sempre meglio.

Penso di essere d'accordo con lo zio Bob nel preferire la chiarezza senza incorrere in eccessiva verbosità . Negli esempi che mostri, direi che l'intento del secondo è più chiaro senza incorrere in eccessiva verbosità . Inoltre sarebbe più facile trovare quel particolare frammento durante la ricerca attraverso la base di codice invalidFieldpiuttosto che per value.

Bene, sto citando Clean Code qui (saltalo se sei stufo della predicazione di zio Bob (che non lo sono):

Usa nomi che rivelano l'intenzione

È facile dire che i nomi dovrebbero rivelare l'intento. Ciò che vogliamo impressionare è che siamo seri a riguardo. La scelta di buoni nomi richiede tempo ma consente di risparmiare più di quanto ci vuole. Quindi prenditi cura dei tuoi nomi e cambiali quando ne trovi di migliori. Chiunque legga il tuo codice (incluso te) sarà più felice se lo fai.

Evitare la disinformazione

I programmatori devono evitare di lasciare falsi indizi che oscurano il significato del codice. Dobbiamo evitare le parole i cui significati radicati variano dal nostro

Fai distinzioni significative

I programmatori creano problemi per se stessi quando scrivono codice esclusivamente per soddisfare un compilatore o un interprete.

Usa nomi ricercabili

Usa nomi che ti aiuterebbero a fare un grep -iIR whateveryouaresearching . (non un codice pulito, qui CC parlava solo di variabili a lettera singola).

Evita la mappatura mentale

I lettori non dovrebbero dover tradurre mentalmente i tuoi nomi in altri nomi che già conoscono. Questo problema nasce generalmente dalla scelta di non utilizzare né termini del dominio problematico né termini del dominio della soluzione.

Usa nomi di dominio problematici

Quando non esiste un "programmatore-eese" per quello che stai facendo, usa il nome dal dominio problematico. Almeno il programmatore che mantiene il tuo codice può chiedere a un esperto di dominio cosa significa.

Opterei sempre per essere più descrittivo in questi giorni - il completamento del codice IDE significa che non dovrai scrivere nomi di variabili descrittivi, quindi non riesco a vedere un aspetto negativo.

Nella preistoria avevi restrizioni sui nomi delle variabili e l'utilizzo di nomi di variabili significativi poteva effettivamente comportare un costo misurabile (ad esempio in BBC BASIC l'uso delle variabili statiche intere A% ecc. Era molto più economico rispetto all'utilizzo di un numero intero significativo - e in un sistema con 1MHz processore, salvando alcuni cicli di clock in un loop effettivamente importato)

L'aspetto della seconda variante mi rende perplesso. Quando guardo solo la firma, mi chiedo se il campo è già noto come non valido? O sarà prima convalidato (come viene chiamato validatingField), per scoprire se è davvero non valido? Quindi non si tratta solo di informazioni ridondanti qui, ma le informazioni extra sembrano in qualche modo fuorvianti. Questo tipo di "chiarezza" non è più chiaro, è il contrario.

In realtà, quando ho visto la tua prima funzione, mi ha reso perplesso. Mi sono chiesto perché diamine la tua funzione prende semplicemente un campo, ma poi non la usa e ne cerca un'altra invalidFields? Cercare un campo sembra avere molto più senso quando viene dato solo un fieldname, come questo:

addInvalidField (fieldname, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === fieldname
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
}

Tuttavia, immagino che Bob Martin farebbe probabilmente un ulteriore passo avanti e renderebbe il codice più dettagliato - per maggiore chiarezza - in una direzione diversa. Un refactoring tipico sulla falsariga del libro "Clean Code" sarebbe probabilmente simile a questo:

addInvalidField (fieldname, message) {
  const foundField = findInvalidField(fieldName)
  addMessageForInvalidField(foundField,message)
}

con tre funzioni aggiuntive

  findInvalidField(fieldname){
    return this.invalidFields.find(value => { return value.name === fieldname })
  }

  addMessageForInvalidField(field,message){
    const errors = field.errors
    if (!doesErrorsContain(message)) {
      errors.push({ name: message, message })
    }
  }

  doesErrorsContain(message){
     return errors.some(error => error.name === message)
  }

È discutibile se paga andare così lontano con il principio della responsabilità unica. In realtà ha alcuni pro e contro. Il mio punto di vista personale è che il codice originale è "abbastanza pulito" per la maggior parte del codice di produzione, ma quello refactored è migliore.

Quando sapevo che dovevo aggiungere qualcosa alla prima variante in modo che crescesse sempre di più, lo avrei diviso in anticipo in queste funzioni più piccole, quindi il codice non avrebbe nemmeno iniziato a diventare un disastro.

Non esiste una risposta corretta in generale nella denominazione. Molte persone quando ricevono lo stesso identico set di attività nomineranno le funzioni e le variabili risultanti in modo molto diverso. Ovviamente vuoi che gli altri che leggono il tuo codice capiscano, ma più a lungo non significa sempre che qualcosa sia più chiaro. Se il tuo codice è più denso, allora deve esserlo, quindi ci vorrà più tempo per capire che anche ogni linea delle tue funzioni è chiara e descrittiva come può essere.

Personalmente, mi piace di più il primo esempio. È dritto e al punto anche con le variabili che non hanno nomi descrittivi come nel secondo esempio. Onestamente, i nomi delle variabili nel secondo esempio non sono molto più chiari rispetto al primo secondo me e mantenere la funzione breve rende più facile capire la funzione stessa.

Alla fine, la cosa migliore dipenderà da te e da chiunque lavori. Dopo tutto, ecco chi lo leggerà e lo manterrà.