Programmieren: Ist es sinnvoll Teilaufgaben in Funktion zu unterteilen?
Hallo,
wenn ich z.B. eine große Funktion habe (hier die main) und dort Teilaufgaben wie z.B. irgendwas komplex zu sortieren in weitere Funktionen unterteile (sort funktion) die aber wirklich nur 1x aufgerufen werden, stellt sich mir die Frage, ob das sinnvoll ist, oder bad practice.
Ich tue das ganze nur aus dem Grund, um den Funktionsablauf übersichtlich zu halten. Letztendlich geht es um die Frage, wie "teuer" (inperformant) ein Funktionsaufruf ist.
Hier BEISPIELCODE kein Sinn dahinter, nur zur Verdeutlichung:
function sort(image, arr) { // Subfunktion
const min = min_val;
const max = max_val;
for (let i = 0; i < arr.length; i++) {
for (let k = 0; k <= arr[0].length; k++) {
if (arr[i][k] < min) arr[i][k] = min;
if (arr[i][k] > max) arr[i][k] = max;
}
}
for (let i = 0; i < image.length; i++) {
for (let k = 0; k < image[0].length; k++) {
image[i][k] = arr[parseInt(image[i][k])];
}
}
return image;
}
function main() {
const array = new Uint8Array(20);
crypto.getRandomValues(array);
const arrayEncoded = btoa(String.fromCharCode(...array)).split('');
const arrayFiltered = arrayEncoded.filter(value => {
switch (value){
case "+" :
return false;
case "/" :
return false;
case "=" :
return false;
default :
return true;
}
});
const sortedArray = sort(arrayFiltered, arrayEncoded) // Hier wird unterfunktion aufgerufen
var arr = new Uint8Array((sortedArray || 40) / 2)
window.crypto.getRandomValues(arr)
return Array.from(arr, dec2hex).join('')
}
Versucht nicht, den Code zu verstehen, es sind einfach nur zusammengewürfelte Zeilen von irgendwo.
7 Antworten
Moin,
naja - im Grunde nimmt es sich dann nichts - aber es macht den Code gerade bei vielen Zeilen wesentlich lesbarer - auch wenn einige Methoden nur einmalig verwendet werden.
Man weiß ja nie, eventuell kommt sie ja doch nochmal zum Einsatz? Aus dem Grund sollte man immer objektorientiert bleiben.
LG
Funktionsaufrufe sind in der Regel sehr billig (und oft genug vom Compiler wegoptimierbar, gerade in der von dir geschilderten Situation). Man darf und soll sie aktiv zur Strukturierung von Programmen nutzen.
Wenn es um Performanceoptimierung geht, ist das Thema wirklich weit unten auf der Liste.
Das Unterteilen in Funktion und bei Objektorientierter Programmierung in Klassen ist ein sehr hilfreiches Mittel, um Verständlichkeit zu verbessern und die später auch die Wartbarkeit zu erhöhen. Was das ausmacht merkst du, wenn du an dem gleichen Code einige Monate später wieder arbeiten musst.
In der heutigen Zeit sind die Kosten für Funktionsaufrufe, etc... tatsächlich bei den meisten Anwendungen egal. Zum einen macht ein Compiler (oder Interpreter) im Hintergrund sehr viel und fügt teilweise den Code von Funktionen an die jeweilige Stelle des Funktionsaufrufes ein (Inlining), bzw. merken es manche Interpreter, wenn eine Funktion häufiger ausgeführt wird und optimieren die Ausführung(z.B. Python, oder die Java-Bytecode-Ausführende JVM mit Hotspot), zum anderen benötigen die meisten Anwendungen nicht über längere Zeit 100% CPU-Kapazitäten, sodass sich eine geringe Verzögerung (wir sprechen von ein paar Takten je Funktionsaufruf), kaum auswirkt.
Die Verwendung von Funktionen erleichtert in jedem Fall das Programmieren.
So kannst Du im Main erstmal Dein Grundgerüst "bauen" ohne über die präzise Funktionsweise nachzudenken. Anschließend kannst Du Funktionen zum Leben erwecken ohne am Rahmenkonzept herum zu fummeln.
Die Verwendung von Funktionen/Methoden und Objekten erleichtert das Programmieren insoweit, das man einzelne Arbeiten voneinander trennt und bearbeiten kann ohne andere Stellen "anzufasse" .
Mein Spezialgebiet hier ist Batch. Nicht gerade der Renner in Sachen Performance und jeder call auf eine Subroutine ist geradezu Gift fürs Tempo. Trotzdem arbeite ich soweit möglich wärend der Entwicklung mit Subroutinen (Funktionen) und etscheide erst beim Finalisieren ob es angebrachter ist eine den Code einer Subroutine direkt in den laufenden Code einzufügen oder bei häufigen Aufrufen als Macro zu definieren. Das ganze ist immer eine Abwägung verschiedener Prämissen.
Im Falle deines sort solltest Du dieses als Funktion belassen. Sollte Dir das Licht ausgehen, dass Dein Sort wesentlich effizienter sein könnte, musst Du nur die Funktion bearbeiten.
Ein Funktionsaufruf hat Kosten, Kosten die man aber gerne bezahlen sollte, wenn der Code dadurch deutlicher und lesbarer wird. Gute Modularisierung und Strukturierung machen das Leben erheblich einfacher.
Kommen wir zum Kostenfaktor: Je nach Sprache kann ich Funktionen fürs Inlining markieren, das ist dann sinnvoll, wenn diese Funktion sehr einfach und kurz ist und in hoher Frequenz aufgerufen würde - Ich separiere also auf sprachlicher Ebene in eine eigene Funktion, erbitte aber fürs Kompilat die Eliminierung des Funktionsaufrufs, indem die Funktion direkt 'eingeklebt' wird.
Das ist ähnlich wie beim Unrolling: Ich kann FOR-Schleifen händisch entrollen, oder ich lasse das den Compiler machen, letzteres gibt mir Gewissheit des lesbareren Codes. Manuell mache ich das ggf. in Biliotheken, wenn ich weiß, daß es performancekritisch ist.