Warum ist die Verwendung von Konjunktionen in Methodennamen eine schlechte Namenskonvention? [geschlossen]

In meinem Team arbeiten wir eng mit einigen Softwarearchitekten zusammen. Sie genehmigen alle Entwurfsentscheidungen unserer Projekte, führen einige Codeüberprüfungen durch usw.

Unsere Projekte bestehen hauptsächlich aus Backend-Funktionen, die in PHP mithilfe des Symfony 2-Frameworks implementiert wurden. Syntaktisch gesehen sehen Code, Namenskonventionen und Projektstruktur fast identisch aus wie Java (Symfony 2 unterstützt eine solche Struktur). Ich erwähne dies, weil in unserem Fall auch Java-spezifische Konventionen gelten (falls möglich).

Kürzlich schlug sie etwas , dass ich sehr seltsam finden: alle Methoden sollten Konjunktionen in ihrem Namen zum Beispiel haben getEntityOrNull, setValueOrExceptionusw.

Eine solche Namenskonvention fühlt sich für mich sehr falsch an, aber ich kann keine konkreten Argumente oder Online-Artikel / Seiten finden, die dies speziell in Frage stellen.

Das einzige, was ich mir ausgedacht habe, ist:

• Solche Informationen sollten in den Anmerkungen der Methode enthalten sein, z. B. @returnoder@throws
• Die Verwendung von Konjunktionen ("und", "oder" usw.) in Methodennamen deutet normalerweise darauf hin, dass das Prinzip der Einzelverantwortung nicht ordnungsgemäß eingehalten wird

Was sind andere konkrete Argumente gegen diese Namenskonvention?

Sie tun dies wahrscheinlich aufgrund von Namenskonflikten. Ich gehe davon aus, dass Sie nicht zwei Methoden benennen können getEntity, eine, die möglicherweise eine Ausnahme auslöst, und eine, die zurückgibt null. Deshalb müssen Sie sie entsprechend benennen.

Zum einen mag ich die Praxis nicht, viele verschiedene Arten zu haben, dieselbe Methode aufzurufen, es sei denn, sie führt eine Änderung durch, die nur diese bestimmte Klasse durchführen kann.

Mit anderen Worten, wenn getValueOrNulleinfach aufgerufen getValueOrException, die Ausnahme erfasst und in diesem Fall zurückgegeben wird null, kann dies vom Anrufer ausgeführt werden. Es überfüllt die Klasse mit Methoden, die nichts Nützliches beitragen. Eher würde ich das vorziehen getValueund wissen, dass es die Ausnahme auslöst. Besser noch, ich würde es vorziehen zu wissen, dass alle get-Methoden möglicherweise Ausnahmen auslösen, und keine von ihnen nullstattdessen zurückgibt, sodass das Verhalten in meinem Projekt einheitlich ist, oder umgekehrt, dass alle potenziell zurückkehren nullund wissen, dass der Aufrufer eine Ausnahme auslösen müsste, wenn das war erwünscht.

Es ist jedoch auch wahr, dass Sie nicht dafür verantwortlich sind. Mein Rat ist, es zur Sprache zu bringen, aber schwitzen Sie nicht die kleinen Dinge. Letztendlich liegt die Verantwortung für solche Namenskonventionen auf ihren Schultern, unabhängig davon, ob sie Ihren Rat befolgen oder nicht, und weil es ihre Ärsche sind, glaube ich, dass es ihr Vorrecht ist, meiner bescheidenen Meinung nach Nein zu sagen.

Obwohl die Verwendung von Konjunktionen häufig auf eine Verletzung der SRP hinweist, zeigt sie in diesem Fall nur den Rückgabewert des algebraischen Datentyps eines armen Mannes an, der einer von zwei Werten sein kann, entweder ein nulloder ein "Erfolgswert".

Sie verwenden eine Art ungarische Notation , um Schwachstellen im Typensystem auszugleichen, nämlich das Fehlen nicht nullbarer Typen. Mit anderen Worten, es gibt keine Möglichkeit, in Ihrer @returnAnmerkung anzugeben, dass die Funktion niemals zurückgegeben wird null, und umgekehrt gibt es keine Möglichkeit, in Ihrer @returnAnmerkung anzugeben, dass die Funktion möglicherweise zurückgegeben wird null.

Ich glaube auch, dass @throwsAnnotationen in PHP nicht obligatorisch sind, sodass das Fehlen der Annotation nicht das Fehlen einer Ausnahme anzeigt, obwohl dies besser gelöst werden kann, indem die Annotation in Ihrem Styleguide obligatorisch gemacht wird.

Angesichts dieser Einschränkungen der von Ihnen verwendeten Sprache ist dies kein völlig unvernünftiger Stil.

In meinem Code erstelle ich manchmal Methodenpaare mit Namen wie getEntity () und getEntityOrNull (). Der Name macht das erwartete Verhalten deutlich. Wenn getEntity () keine Entität findet, wird eine Ausnahme ausgelöst. getEntityOrNull () gibt eine Null zurück.

Auf diese Weise wird der aufrufende Code etwas klarer. Wenn der aufrufende Code eine Entität haben muss, erledigt getEntity den Trick. Wenn es sich bei der Entität um eine optionale Sache handelt, ist getEntityOrNull die Methode der Wahl.

Dasselbe könnte mit einer einzigen Methode erreicht werden, aber das verlagert dann einen Teil der Belastung auf das aufrufende Programm. Sie müssen immer auf eine Null testen oder Sie benötigen einen Try / Catch-Block. In beiden Fällen muss bei jedem Aufruf der Methode zusätzlicher Code dupliziert werden.

Wenn Ihre Architekten diese Art von Methodenpaaren nicht verwenden, würde ich die Notwendigkeit des Suffixes in Frage stellen.

Ich habe nie wirklich eine setValueOrException-Methode gesehen. Ich kann mir keinen guten allgemeinen Anwendungsfall dafür vorstellen.

Sie könnten die Architekten fragen, warum. Diejenigen, die ich kenne, sind immer froh, ihre Entscheidungen zu erklären. Oft sehr detailliert (und manchmal qualvoll).

Ihre beiden Argumente sind stichhaltig. Aber wenn sie für die Entscheidung über die Namenskonvention verantwortlich sind, versuchen Sie, sich nicht zu schlecht zu fühlen, wenn Sie damit nicht einverstanden sind.

Wenn Sie schon dabei sind, sollten Sie sie davon überzeugen, die Abschnitte "get" und "set" nicht zu verwenden, es sei denn, diese Methoden setzen oder erhalten direkt eine Mitgliedsvariable.