Benennung: Sollten Sie die Kürze für Klarheit opfern?

Die folgende Funktion durchläuft beispielsweise ein Array, das den Namen und die Fehler eines Eingabefelds enthält. Dazu wird der Name des Validierungsfelds überprüft und anschließend die Fehlerinformationen in das Array für ungültige Felder verschoben.

Ist es besser, sich kurz zu fassen und Folgendes zu schreiben:

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 })
  }
},

Oder genauer so sein?

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 })
  }
},

Wenn die Kürze der Klarheit halber geopfert werden kann, sollte dies der Fall sein. Aber wenn Ausführlichkeit für Klarheit geopfert werden kann, noch besser.

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 })
  }
},

Wenn eine Variable nur so lange wie eine Zeile lebt, kann sie tatsächlich sehr kurz sein. FoundInvalidFieldwird in drei Zeilen verwendet und steht im Mittelpunkt dieser Arbeit. Es verdient einen erklärenden Namen.

Wie immer ist der Kontext König.

Ich bevorzuge tatsächlich Ihr erstes Codebeispiel.

Es ist klar ersichtlich, was der Code tut, wenn man ihn liest. Indem Sie die Variablennamen so klein wie möglich halten, wird der Code noch einfacher zu lesen. Beschreibendere Variablennamen wären nur erforderlich, wenn Ihre Funktionen länger wären, Ihre Variablen zahlreicher wären und / oder die Variablen über einen größeren Codebereich verwendet würden.

Weil Sie Ihre Funktionen kurz gehalten haben, können Sie auch Ihre Variablennamen kurz halten. Wenn alle anderen Dinge gleich sind, ist weniger Code immer besser.

Ich glaube, ich stimme Onkel Bob darin zu , Klarheit zu bevorzugen, ohne übermäßige Ausführlichkeit zu verursachen . In den Beispielen, die Sie zeigen, würde ich sagen, dass die Absicht des Zweiten klarer ist, ohne dass es zu übermäßiger Ausführlichkeit kommt . Außerdem wäre es einfacher, dieses bestimmte Snippet zu finden, wenn Sie in der Codebasis nach suchen invalidFieldals nach value.

Nun, ich zitiere hier Clean Code (überspringen Sie ihn, wenn Sie genug von Onkel Bobs Predigt haben (was ich nicht bin):

Verwenden Sie absichtliche Namen

Es ist leicht zu sagen, dass Namen Absichten offenbaren sollten. Wir möchten Sie beeindrucken, dass wir das ernst meinen. Die Auswahl guter Namen kostet Zeit, spart aber mehr als nötig. Pass also auf deine Namen auf und ändere sie, wenn du bessere findest. Jeder, der Ihren Code liest (einschließlich Sie), ist glücklicher, wenn Sie dies tun.

Desinformation vermeiden

Programmierer müssen vermeiden, falsche Hinweise zu hinterlassen, die die Bedeutung von Code verschleiern. Wir sollten Wörter vermeiden, deren tief verwurzelte Bedeutungen von unseren abweichen

Machen Sie sinnvolle Unterscheidungen

Programmierer verursachen Probleme für sich selbst, wenn sie Code nur schreiben, um einen Compiler oder Interpreter zufrieden zu stellen.

Verwenden Sie durchsuchbare Namen

Verwenden Sie Namen, die Ihnen dabei helfen würden grep -iIR whateveryouaresearching . (kein Clean Code, hier sprach CC nur über Einzelbuchstabenvariablen).

Vermeiden Sie mentales Mapping

Leser sollten Ihre Namen nicht mental in andere Namen übersetzen müssen, die sie bereits kennen. Dieses Problem ergibt sich im Allgemeinen aus der Wahl, weder Problemdomänenbegriffe noch Lösungsdomänenbegriffe zu verwenden.

Verwenden Sie Problem Domain Names

Wenn für das, was Sie tun, kein "Programmierer" vorhanden ist, verwenden Sie den Namen aus der Problemdomäne. Zumindest der Programmierer, der Ihren Code verwaltet, kann einen Domain-Experten fragen, was dies bedeutet.

Ich würde mich heutzutage immer dafür entscheiden, aussagekräftiger zu sein - die Vervollständigung des IDE-Codes bedeutet, dass Sie keine beschreibenden Variablennamen schreiben müssen, damit ich keinen Nachteil sehe.

In der Vorgeschichte gab es Einschränkungen bei Variablennamen, und die Verwendung aussagekräftiger Variablennamen konnte tatsächlich messbare Kosten verursachen (z. B. in BBC BASIC war die Verwendung der ganzzahligen statischen Variablen A% usw. viel billiger als die Verwendung einer aussagekräftigen Ganzzahl - und in einem System mit 1 MHz Prozessor, das Speichern einiger Taktzyklen in einer Schleife war tatsächlich wichtig)

Die zweite Variante macht mich verwirrt. Wenn ich nur die Signatur betrachte, frage ich mich, ob das Feld bereits als ungültig bekannt ist. Oder wird es zuerst validiert (wie es heißt validatingField), um herauszufinden, ob es wirklich ungültig ist? Dies sind also nicht nur redundante Informationen, sondern die zusätzlichen Informationen scheinen etwas irreführend zu sein. Diese Art von "Klarheit" ist nicht klarer, es ist das Gegenteil.

Als ich Ihre erste Funktion sah, war ich auch verwirrt. Ich habe mich gefragt, warum zum Teufel nimmt Ihre Funktion nur ein Feld, verwendet es dann aber nicht und sucht nach einem anderen in invalidFields? Die Suche nach einem Feld scheint viel sinnvoller zu sein, wenn nur ein Feldname angegeben wird:

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 })
  }
}

Ich denke jedoch, dass Bob Martin wahrscheinlich noch einen Schritt weiter gehen und den Code - für mehr Klarheit - ausführlicher in eine andere Richtung gestalten würde. Ein typisches Refactoring nach dem Vorbild des Buches "Clean Code" würde wahrscheinlich folgendermaßen aussehen:

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

mit drei zusätzlichen Funktionen

  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)
  }

Es ist fraglich, ob es sich auszahlt, mit dem Prinzip der Einzelverantwortung so weit zu gehen. Es hat tatsächlich einige Vor- und Nachteile. Mein persönlicher Standpunkt ist, dass der ursprüngliche Code für die meisten Produktionscodes "sauber genug" ist, aber der überarbeitete Code ist besser.

Wenn ich wusste, dass ich der ersten Variante etwas hinzufügen musste, damit sie immer größer wurde, teilte ich sie vorher in diese kleineren Funktionen auf, damit der Code nicht einmal zu einem Chaos wird.

Es gibt im Allgemeinen keine richtige Antwort bei der Benennung. Viele Menschen benennen die resultierenden Funktionen und Variablen sehr unterschiedlich, wenn sie genau die gleiche Aufgabe erhalten. Natürlich möchten Sie, dass andere, die Ihren Code lesen, verstehen, aber länger bedeutet nicht immer, dass etwas klarer ist. Wenn Ihr Code dichter ist, muss es sein, dann dauert es länger, bis Sie verstanden haben, dass jede Zeile Ihrer Funktionen so klar und beschreibend wie möglich ist.

Persönlich mag ich das erste Beispiel mehr. Es ist gerade und auf den Punkt gebracht, auch wenn die Variablen nicht so beschreibende Namen haben wie im zweiten Beispiel. Ehrlich gesagt sind die Variablennamen im zweiten Beispiel meiner Meinung nach nicht viel klarer als die ersten, und wenn man die Funktion kurz hält, ist es einfacher, die Funktion selbst zu verstehen.

Am Ende des Tages liegt es an Ihnen und mit wem auch immer Sie arbeiten, was besser ist. Immerhin ist es derjenige, der es liest und pflegt.