Kann eine Funktion zu kurz sein?

Immer wenn ich die gleiche Logik mehrmals schreibe, schreibe ich sie normalerweise in eine Funktion, sodass es nur eine Stelle in meiner Anwendung gibt, an der ich diese Logik beibehalten muss. Ein Nebeneffekt ist, dass ich manchmal mit ein oder zwei Zeilenfunktionen ende, wie zum Beispiel:

function conditionMet(){
   return x == condition;
}

ODER

function runCallback(callback){
   if($.isFunction(callback))
     callback();
}

Ist das faul oder eine schlechte Übung? Ich frage nur, weil dies zu einer größeren Anzahl von Funktionsaufrufen für sehr kleine Teile der Logik führt.

Hehe, oh Mr. Brown, wenn ich nur alle Entwickler, denen ich begegne, überreden könnte, ihre Funktionen so klein zu halten, glauben Sie mir, die Software-Welt wäre ein besserer Ort!

1) Ihre Codelesbarkeit verzehnfacht sich.

2) So einfach, den Prozess Ihres Codes wegen der Lesbarkeit herauszufinden.

3) TROCKEN - Wiederholen Sie sich nicht - Sie passen sich dem sehr gut an!

4) Testbar. Winzige Funktionen sind millionenfach einfacher zu testen als die 200-Zeilen-Methoden, die wir viel zu oft sehen.

Oh und mach dir keine Sorgen über "Funktionssprung" in Bezug auf die Leistung. "Release" Builds und Compiler-Optimierungen erledigen dies für uns sehr gut, und die Leistung ist zu 99% in anderen Bereichen des Systemdesigns zu finden.

Ist das faul? - Ganz im Gegenteil!

Ist das schlechte Praxis? - Absolut nicht. Besser diese Art der Herstellung als die Teerbälle oder "God Objects", die ach so üblich sind.

Mach weiter so mein Handwerkskollege;)

Ich würde sagen, dass eine überarbeitete Methode zu kurz ist, wenn entweder:

• Es dupliziert eine primitive Operation nur, um sie zu einer Methode zu machen:

Ex:

boolean isNotValue() {
   return !isValue();
}

oder...

• Der Code wird nur einmal verwendet und seine Absicht ist auf einen Blick leicht zu verstehen.

Ex:

void showDialog() {
    Dialog singleUseDialog = new ModalDialog();
    configureDialog(singleUseDialog);
    singleUseDialog.show();
}

void configureDialog(Dialog singleUseDialog) {
    singleUseDialog.setDimensions(400, 300);
}

Dies könnte ein gültiges Muster sein, aber in diesem Beispiel würde ich nur die configureDialog () -Methode einbinden, es sei denn, ich beabsichtige, sie zu überschreiben oder diesen Code an einer anderen Stelle wiederzuverwenden.

Kann eine Funktion zu kurz sein? Im Allgemeinen nicht.

In der Tat der einzige Weg, um sicherzustellen, dass:

1. Sie haben alle Klassen in Ihrem Entwurf gefunden
2. Ihre Funktionen machen nur eine Sache.

Ist, um Ihre Funktionen so klein wie möglich zu halten. Oder mit anderen Worten, extrahieren Sie Funktionen aus Ihren Funktionen, bis Sie nicht mehr extrahieren können. Ich nenne das "Extrakt bis zum Umfallen".

Um dies zu erklären: Eine Funktion ist ein Bereich mit Funktionsblöcken, die über Variablen kommunizieren. Eine Klasse ist auch ein Bereich mit Funktionsblöcken, die über Variablen kommunizieren. So kann eine lange Funktion immer durch eine oder mehrere Klassen mit kleiner Methode ersetzt werden.

Eine Funktion, die groß genug ist, um eine andere Funktion daraus zu extrahieren, ist per Definition mehr als eine Sache . Also , wenn Sie können eine Funktion von einem anderen extrahieren, Sie sollten diese Funktion extrahieren.

Einige Leute befürchten, dass dies zu einer Verbreitung von Funktionen führen wird. Sie haben recht Es wird. Das ist eigentlich eine gute Sache. Es ist gut, weil Funktionen Namen haben. Wenn Sie bei der Auswahl guter Namen vorsichtig sind, fungieren diese Funktionen als Wegweiser, die andere Personen durch Ihren Code leiten. In der Tat sind gut benannte Funktionen in gut benannten Klassen in gut benannten Namespaces eine der besten Möglichkeiten, um sicherzustellen, dass Ihre Leser NICHT verloren gehen.

Darüber gibt es in Episode III von Clean Code auf cleancoders.com noch viel mehr

Wow, die meisten dieser Antworten sind überhaupt nicht hilfreich.

Es sollte keine Funktion geschrieben werden, deren Identität ihre Definition ist . Das heißt, wenn der Funktionsname einfach der in Englisch geschriebene Codeblock der Funktion ist, dann schreibe ihn nicht als Funktion.

Betrachten Sie Ihre Funktion conditionMetund diese andere Funktion addOne(verzeihen Sie mir mein rostiges JavaScript):

function conditionMet() { return x == condition; }

function addOne(x) { return x + 1; }

conditionMetist eine richtige konzeptionelle Definition; addOneist eine Tautologie . conditionMetist gut, weil Sie nicht wissen, was conditionMetbedeutet, addOnewenn Sie nur "Bedingung erfüllt" sagen, aber Sie können sehen, warum es albern ist, wenn Sie es auf Englisch vorlesen:

"For the condition to be met is for x to equal condition" <-- explanatory! meaningful! useful!

"To add one to x is to take x and add one." <-- wtf!

Schreiben Sie aus Liebe zu allem, was noch heilig sein könnte, bitte keine tautologischen Funktionen!

( Schreiben Sie aus dem gleichen Grund keine Kommentare für jede Codezeile !)

Ich würde sagen, wenn Sie der Meinung sind, dass die Absicht eines Codes durch Hinzufügen eines Kommentars verbessert werden kann, extrahieren Sie den Code in eine eigene Methode, anstatt diesen Kommentar hinzuzufügen. Egal wie klein der Code war.

Wenn Ihr Code zum Beispiel so aussehen würde:

if x == 1 { ... } // is pixel on?

Lass es stattdessen so aussehen:

if pixelOn() { ... }

mit

function pixelOn() { return x == 1; }

Mit anderen Worten, es geht nicht um die Methodenlänge, sondern um selbstdokumentierenden Code.

Ich denke, genau das möchten Sie tun. Im Moment besteht diese Funktion vielleicht nur aus einer oder zwei Zeilen, aber im Laufe der Zeit könnte sie wachsen. Wenn Sie außerdem mehr Funktionsaufrufe haben, können Sie die Funktionsaufrufe lesen und nachvollziehen, was dort vor sich geht. Dies macht Ihren Code sehr trocken (Don't Repeat Yourself), was viel besser zu pflegen ist.

Ich stimme allen anderen Posts zu, die ich gesehen habe. Das ist guter Stil.

Der Overhead einer so kleinen Methode kann null sein, da der Optimierer den Abruf optimieren und den Code einbinden kann. Ein einfacher Code wie dieser ermöglicht es dem Optimierer, seine beste Arbeit zu leisten.

Code sollte aus Gründen der Klarheit und Einfachheit geschrieben werden. Ich versuche, eine Methode auf eine von zwei Rollen zu beschränken: Entscheidungen treffen; oder Arbeit verrichten. Dies kann einzeilige Methoden erzeugen. Je besser ich das kann, desto besser finde ich meinen Code.

Code wie dieser weist tendenziell eine hohe Kohäsion und eine niedrige Kopplung auf, was eine gute Kodierungspraxis ist.

EDIT: Ein Hinweis zu Methodennamen. Verwenden Sie einen Methodennamen, der angibt, was die Methode nicht tut, wie sie es tut. Ich finde verb_noun (_modifier) ​​ist ein gutes Namensschema. Dies gibt Namen wie Find_Customer_ByName und nicht Select_Customer_Using_NameIdx. Der zweite Fall neigt dazu, falsch zu werden, wenn die Methode geändert wird. Im ersten Fall können Sie die gesamte Implementierung der Kundendatenbank austauschen.

Das Umgestalten einer Codezeile in eine Funktion scheint übertrieben. Es kann Ausnahmefälle geben, wie z. B. sehr viele Zeilen oder Erweiterungen, aber ich würde dies nicht tun, es sei denn, ich weiß, dass die Funktion in Zukunft erweitert wird.

und Ihr erstes Beispiel weist auf die Verwendung von Globals hin (die möglicherweise von anderen Problemen im Code sprechen). Ich würde es weiter überarbeiten und diese beiden Variablen als Parameter definieren:

function conditionMet(x, condition){
   return x == condition;
}
....
conditionMet(1,(3-2));
conditionMet("abc","abc");

Das conditionMetBeispiel könnte nützlich sein , wenn die Bedingung war lange und sich wiederholende wie zum Beispiel:

function conditionMet(x, someObject){
   return x == ((someObject.valA + someObject.valB - 15.4) / /*...whole bunch of other stuff...*/);
}

Bedenken Sie:

Eine einfache Kollisionserkennungsfunktion:

bool collide(OBJ a, OBJ b)
{
    return(pow(a.x - b.x, 2) + pow(a.y - b.y, 2) <= pow(a.radius + b.radius, 2));
}

Wenn Sie diese "einfache" Zeile die ganze Zeit in Ihren Code geschrieben haben, könnten Sie irgendwann einen Fehler machen. Außerdem wäre es wirklich mühsam, das immer und immer wieder zu schreiben.

Nein, und das ist selten ein Problem. Wenn jemand der Meinung ist, dass keine Funktion länger als eine Codezeile sein sollte (wenn es nur so einfach sein könnte), wäre dies ein Problem und in gewisser Weise faul, weil er nicht darüber nachdenkt, was angemessen ist.

Ich würde sagen, sie sind zu kurz, aber das ist meine subjektive Meinung.

Weil:

• Es gibt keinen Grund, eine Funktion zu erstellen, wenn sie nur ein- oder zweimal verwendet wird. Springen auf Defs saugen. Besonders mit erstaunlich schnellem VS- und C ++ - Code.
• Klassenübersicht. Wenn Sie Tausende kleiner Funktionen haben, macht es mich wütend. Ich genieße es, wenn ich Klassendefinitionen anzeigen und schnell sehen kann, was es tut, nicht wie es SetXToOne, SetYToVector3, MultiplyNumbers, + 100 Setter / Getter.
• In den meisten Projekten werden diese Helfer nach einer oder zwei Umgestaltungsphasen unfähig, und dann "alle durchsuchen" -> "löschen", um veralteten Code zu entfernen, in der Regel ~ 25% +.

Funktionen, die lang sind, sind schlecht, aber Funktionen, die kürzer als 3 Zeilen sind und nur 1 Ding ausführen, sind IMHO gleich schlecht.

Also würde ich sagen, schreibe nur kleine Funktionen, wenn es:

• 3+ Codezeilen
• Gibt es Dinge, die Junior-Entwickler vermissen könnten (nicht wissen)
• Führt eine zusätzliche Validierung durch
• Wird verwendet oder wird mindestens 3x verwendet
• Vereinfacht häufig verwendete Benutzeroberfläche
• Wird beim nächsten Refactoring nicht zum Eigengewicht
• Hat eine spezielle Bedeutung, zum Beispiel Template-Spezialisierung oder so
• Erledigt einige Isolationsaufgaben - const-Referenzen, beeinflusst veränderbare Parameter, ruft private Mitglieder ab

Ich wette, der nächste Entwickler (Senior) wird bessere Dinge zu tun haben, als sich an alle Ihre SetXToOne-Funktionen zu erinnern. So werden sie ziemlich bald in totes Gewicht verwandeln.

Das Beispiel Nr. Gefällt mir nicht. 1, weil es ein Gattungsname ist.

conditionMetscheint nicht generisch zu sein, steht es also für eine bestimmte Bedingung? Mögen

isAdult () = { 
  age >= 18 
}

Das wäre in Ordnung. Es ist ein semantischer Unterschied, während

isAtLeast18 () { age >= 18; } 

wäre nicht gut für mich.

Vielleicht wird es oft verwendet und kann später geändert werden:

getPreferredIcecream () { return List ("banana", "choclate", "vanilla", "walnut") }

ist auch in Ordnung. Wenn Sie es mehrmals verwenden, müssen Sie nur einen Ort wechseln, wenn Sie müssen - vielleicht wird Schlagsahne morgen möglich.

isXYZ (Foo foo) { foo.x > 15 && foo.y < foo.x * 2 }

ist nicht atomar, und sollte Ihnen eine schöne Testmöglichkeit geben.

Wenn Sie eine Funktion übergeben müssen, übergeben Sie natürlich alles, was Sie möchten, und schreiben Sie ansonsten albern aussehende Funktionen.

Aber im Allgemeinen sehe ich viel mehr Funktionen, die zu lang sind, als Funktionen, die zu kurz sind.

Ein letztes Wort: Einige Funktionen sehen nur deshalb passend aus, weil sie zu ausführlich geschrieben sind:

function lessThan (a, b) {
  if (a < b) return true else return false; 
}

Wenn Sie sehen, dass es das gleiche ist wie

return (a < b); 

Sie werden kein Problem mit haben

localLessThan = (a < b); 

Anstatt von

localLessThan = lessThan (a, b); 

Es gibt keinen Code wie keinen Code!

Halten Sie es einfach und nicht zu kompliziert.

Es ist nicht faul, es macht deinen Job!

Ja, es ist in Ordnung, eine Funktionscode-Funktion zu haben. Bei Methoden wie "Getter", "Setter" und "Accesors" ist dies, wie bereits erwähnt, weit verbreitet.

Manchmal sind diese kurzen "accesors" -Funktionen virtuell, da die Funktionen beim Überschreiben in Unterklassen mehr Code enthalten.

Wenn Sie möchten, dass Sie nicht so kurz funktionieren, ob global oder methodisch, verwende ich normalerweise eine "Ergebnis" -Variable (Pascal-Stil) anstelle einer direkten Rückgabe. Dies ist sehr hilfreich, wenn Sie einen Debugger verwenden.

function int CalculateSomething() {
  int Result = -1;

   // more code, maybe, maybe not

  return Result;
}

Zu kurz ist nie ein Problem. Einige Gründe für kurze Funktionen sind:

Wiederverwendbarkeit

Wenn Sie z. B. eine Funktion haben, wie z. B. eine Set-Methode, können Sie diese festlegen, um sicherzustellen, dass die Parameter gültig sind. Diese Überprüfung muss überall dort erfolgen, wo die Variable gesetzt ist.

Wartbarkeit

Möglicherweise verwenden Sie eine Aussage, von der Sie glauben, dass sie sich in Zukunft ändern könnte. Sie zeigen jetzt beispielsweise ein Symbol in einer Spalte an, das sich später jedoch möglicherweise zu etwas anderem (oder sogar zu einem Piepton) ändert.

Gleichmäßigkeit

Sie verwenden z. B. das Fassadenmuster und eine Funktion gibt die Funktion nur exakt an eine andere weiter, ohne die Argumente zu ändern.

Wenn Sie einem Codeabschnitt einen Namen geben, dient dies im Wesentlichen dazu, ihm einen Namen zu geben . Dies kann verschiedene Gründe haben, aber der entscheidende Punkt ist, ob Sie ihm einen aussagekräftigen Namen geben können, der Ihr Programm erweitert. Namen wie "addOneToCounter" würden nichts hinzufügen, conditionMet()würden aber .

Wenn Sie eine Regel benötigen, um herauszufinden, ob das Snippet zu kurz oder zu lang ist, überlegen Sie, wie lange Sie brauchen, um einen aussagekräftigen Namen für das Snippet zu finden. Wenn Sie dies nicht innerhalb einer angemessenen Zeitspanne tun können, ist das Snippet nicht in der richtigen Größe.

Nein, aber es kann zu knapp sein.

Denken Sie daran: Code wird einmal geschrieben, aber mehrmals gelesen.

Schreiben Sie keinen Code für den Compiler. Schreiben Sie es für zukünftige Entwickler, die Ihren Code warten müssen.

Ja, meine Liebe, die Funktion könnte immer kleiner werden und ob sie gut oder schlecht ist, hängt von der Sprache / dem Framework ab, das Sie verwenden.

Meiner Meinung nach beschäftige ich mich hauptsächlich mit Front-End-Technologien. Kleine Funktionen werden meistens als Hilfsfunktionen verwendet, die Sie bei der Arbeit mit kleinen Filtern und der Verwendung der gleichen Logik in Ihrer gesamten Anwendung häufig verwenden müssen. Wenn Ihre Anwendung zu viel gemeinsame Logik hat, wird es eine Menge kleiner Funktionen geben.

In einer Anwendung, in der Sie keine gemeinsame Logik haben, müssen Sie keine kleinen Funktionen ausführen, sondern können Ihren Code in Segmente aufteilen, die für Sie einfacher zu verwalten und zu verstehen sind.

Im Allgemeinen ist die Aufteilung Ihres großen Codes in kleine Funktionen ein sehr guter Ansatz. In modernen Frameworks und Sprachen sind Sie dazu verpflichtet, z

data => initScroll(data)

ist eine anonyme Funktion in ES 2017 JavaScript und Typescript

getMarketSegments() {
 this.marketService.getAllSegments(this.project.id)
  .subscribe(data => this.segments = data, error => console.log(error.toString()));
}

Im obigen Code sehen Sie 3 Funktionsdeklarationen und 2 Funktionsaufrufe. Dies ist ein einfacher Service-Aufruf in Angular 4 mit Typescript. Sie können sich das als Ihre Anforderungen vorstellen

([] 0)
([x] 1)
([x y] 2)

Die oben genannten sind 3 anonyme Funktionen in Clojure Language

(def hello (fn [] "Hello world"))

Das obige ist eine Funktionserklärung in Clojure

Also ja FUNKTIONEN können so kleiner sein aber ob es gut oder schlecht ist wenn du Funktionen hast wie:

incrementNumber(numb) { return ++numb; }

Das ist keine gute Vorgehensweise, aber wenn Sie diese Funktion in einem HTML-Tag verwenden, wie wir es in Angular Framework tun, wenn Increment oder Decrement in Angular HTML-Vorlagen nicht unterstützt werden, wäre dies die Lösung für mich.

Nehmen wir ein anderes Beispiel

insertInArray(array, newKey) {
 if (!array.includes(newKey)) {
   array.push(newKey);
 }
}

Das obige Beispiel ist ein Muss, wenn Arrays in Angular HTML-Vorlagen abgespielt werden. Manchmal müssen Sie also kleine Funktionen erstellen

Ich bin damit nicht einverstanden, dass zu diesem Zeitpunkt fast eine Antwort gegeben wird.

Kürzlich habe ich einen Kollegen gefunden, der alle Klassenmitglieder wie folgt schreibt:

 void setProperty(int value){ mValue=value; }
 int getProperty() const { return (mValue); }

Dies könnte in sporadischen Fällen ein guter Code sein, aber sicherlich nicht, wenn Sie viele Klassen mit vielen und vielen Eigenschaften definieren. Ich möchte damit nicht sagen, dass Methoden wie die oben genannten nicht geschrieben werden sollen. Wenn Sie jedoch den größten Teil des Codes als "Wrapper" der realen Logik schreiben, stimmt etwas nicht.

Wahrscheinlich vermisst der Programmierer die Gesamtlogik, hat Angst vor zukünftigen Änderungen und vor der Überarbeitung des Codes.

Die Definition der Schnittstelle beruht auf einem tatsächlichen Bedarf. in der Tat, wenn Sie eine einfache Eigenschaft setzen und erhalten müssen (ohne viel Logik, die das Mitglied kürzer macht), ist es möglich. Aber wenn der tatsächliche Bedarf auf andere Weise analysiert werden könnte, warum nicht eine intuitivere Benutzeroberfläche definieren?

Um die Frage wirklich zu beantworten, ist es natürlich nein, und der Grund liegt auf der Hand: Die Methode / Eigenschaft / Whatelse muss für das definiert werden, was sie benötigt. Auch eine leere virtuelle Funktion hat einen Grund zu existieren.