nicht angemeldet
fischlak
Rolf B
encoder
fischlak
Felix Riesterer
fischlak
Felix Riesterer
fischlak
Rolf B
Ich arbeite aktuell an einem Shop. Dazu gehören natürlich auch JS-Dateien. Eine davon hat inzwischen ~ 3500 Zeilen. Um mir das Leben leichter zu machen, arbeite ich (unter Kubuntu) mit Kate, weil Kate ein gutes Folding und LSP mit sich bringt. Mithilfe des Foldings ist es dann ja bekanntlich viel leichter, sich in großen Dateien zurechtzufinden. Da hab ich mich gefragt, wie macht ihr es denn so, wenn ein Projekt größer wird und ihr die Übersicht nicht verlieren wollt?
Mit OOP hab ich nicht die besten Erfahrungen gemacht, denn ich arbeite alleine. Wenn im Laufe der Zeit das Projekt fortschreitet, dann kommen ja die Erweiterungen/Ergänzungen und damit meistens auch die Änderungen. OOP hat es mit sich gebracht, dass ich dann auch in die Klasse rein muss und ändern/anpassen. Also eigentlich nur noch mehr Hin- und Herhüpfen und noch mehr geöffnete Tabs. So komme ich mit Folding und einer folding-basierten Code-Strukturierung am besten klar.
Ich pers. halte auch nichts von den bekannten Dogmen, jede kleine Funktionalität in eine extra Funktion auszulagern, oder eine Funktion soll nicht mehr als 10 Zeilen haben. Solches Coden bedeutet am Ende nur noch mehr Hin- und Herspringen. Da hab ich den Code lieber "vor Ort".
Welche Strategien verfolgt ihr denn so, um den Code so zu strukturieren, dass man auch nach 6 Monaten noch gut damit klarkommt, jetzt mal abgesehen von geeigneter Kommentierung? Gibt es Editoren, die in Punkto Strukturierung besondere Features mit sich bringen, von denen ich noch nichts weiss?
Hallo fischlak,
ich arbeite bei größeren Themen objektorientiert, weil man damit den Code gut strukturieren kann. Kleinere Themen kann man rein funktional gut realisieren.
Ich beachte die Clean Code Maximen von Robert Martin. Die Zeilenzahl einer Methode ist kein Kriterium, sondern dies: Eine Methode soll genau eine Sache tun (Koordinieren anderer Methoden ist auch eine Sache). Damit sieht man ihr an, was sie tut, und wenn sie gut benannt ist, muss der Aufrufer nicht unbedingt in den Code schauen, um zu wissen, was passiert. Man soll Dinge nicht mehrfach an unterschiedlichen Positionen programmieren. DRY (don't repeat yourself) statt WET (write everything twice). Wenn eine Methode 50 Zeilen oder mehr hat, dann tut sie in den meisten Fällen mehr als eine Sache und sollte zerlegt werden.
In C# arbeite ich mit Dependency Injection. Das vereinfacht - oder ermöglicht erst - das Mocken für Unit Tests und hilft der Codestabilität. In JavaScript habe ich dafür noch keinen guten DI-Container gefunden, und bei stark UI-lastigen Programmen sind Unit Tests auch weniger hilfreich.
In JavaScript packe ich meine Klassen in Module, jedes in einer eigenen Datei. Für den Produktionscode werden sie gebündelt und minifiziert. Da meine Anwendung schon älter ist und auch im IE lief, ist das Tool dafür noch require.js. Es sind aber nur ca 1000 Zeilen JavaScript. Ein großer Teil der Logik läuft auf dem Server (ASP.NET mit C#). Daher kommt Visual Studio (das große, nicht Code) als Editor-Tool, mit Folding und Intellisense. Wobei ich Folding selten benötige.
Natürlich hat man durch Clean Code mehr Codezeilen. Es mag auch etwas langsamer sein. Aber ich komme damit besser klar als mit 1000 Zeilen langen Funktionen, wo man am Ende nicht weiß, was am Anfang passiert ist und man sich mit den Variablen ständig gegenseitig auf den Füßen steht.
Arbeit im Team? In den letzten Jahren betreibe ich meine Projekte alleine. Aber trotzdem ist eine saubere Modularisierung viel sinnvoller als alles in einer Riesendatei zu haben. Visual Studio hilft mir dabei sehr mit der Funktion "Go To Definition". Damit ist man, wenn man einer Aufrufkette folgen will, immer schnell am Ziel. Ich habe auch Projekte in größeren Teams gemacht. Dort bin ich mit OOP eher auf Schwierigkeiten gestoßen, weil Refactoring öfter man den Code der Kollegen zerbröselt hat. Aber das war, bevor ich von SOLID gehört hatte. Richtig verstanden habe ich es immer noch nicht…
Also kurz gesagt: Meine Arbeitsweise ist so ziemlich das Gegenteil von Deiner. Vor 41 Jahren habe ich bei deiner Arbeitsweise angefangen. Mit COBOL. Und im Lauf der Jahrzehnte genug Schmerzen damit gehabt, um OOP und Clean Code schätzen zu lernen.
Rolf
Hallo Rolf!
Mir geht es ja nur darum, die Übersicht im Falle einer Erweiterung/Änderung/Revision/Refraktorierung nicht zu verlieren.
Es läuft doch immer so: Wenn ich erweitern/ändern möchte, dann springe ich durch eine Kette von aufgerufenen Funktionen. Und je länger und umfangreicher diese Kette ist, desto schneller verliert man die Übersicht. Wer kennt das nicht?
Ich habe diesbezüglich folgende Erfahrung gemacht: Je größer ein Projekt wird, desto mehr Code entsteht logischerweise. Auch dann, wenn ich mich an die bekannten Dogmen halte. Der Vorsatz, Funktionalität in möglichst kleine Einheiten zu erlegen, sodass jede Einheit nur 1 Sache tut, führt zwangsläufig zu größerer Fragmentierung. Auch OOP kann das nicht verhindern, sonden im Gegenteil – OOP vergrößert die Fragmentierung noch.
Ich hatte eine Zeit, da hab ich jede Kleinigkeit gleich in eine Hilfsfunktion gepackt, weil die Funktionalität "1 Sache" tat. Hatte nur den Erfolg, dass ich noch mehr springen musste, wenn es etwas zu Erweitern/Ergänzen gab. Solange ich nur debugge – kein Problem. Der Debugger hüpft ja von ganz alleine zu den Stellen.
Aber wenn ich ändern will, dann muss ich den Code erstmal verstehen. In den Moment, in dem ich den Code schreibe, befindet er sich im "organischen Hauptspeicher" und ist sehr präsent. Dann ist jede Code-Ecke bekannt und klar zu sehen. Aber was ist 6 Monate später? Wer kennt diesen Moment nicht, sich in seinen eigenen Code wieder hineinversetzen zu müssen. Und genau dann, wenn ich mich wieder hineinversetzen muss, hüpfe ich im Code hin- und her, um so nach und nach wieder zu verstehen, "wie es war". Davor schützt mich auch nicht, wenn ich mich an Dogmen halte, an OOP‑Traditionen, an Clean-Code- Maximen, an DRY-Minimalismus. Und wenn dann noch Team‑Konventionen hinzukommen, dann ist die Fragmentierung maximal.
Der Aufbau einer JS-Datei ist doch immer gleich: oben Variablen, darunter Funktionen (und möglichst viele – für jede Sache eine eigene Funktion), darunter Event-Handler bzw. Listener und die Aufrufe. Alles linear, alles flach.
Große Funktionen verschlimmern es dann noch, weil wir Menschen nicht dazu gemacht sind "viel auf einmal" aufzufassen. Wir brauchen eben kleine Häppchen.
Dehalb ist mir Folding so wichtig. Wenn ich eine Funktion fertig hab, dann klappe ich sie ein und sehe ja an ihrem Namen, was sie macht. Das Funktions-Innere interessiert mich dann nicht mehr, sofern es funktioniert.
Ich stecke auch Hilfsfunktionen nicht wie früher "oben zu den Funktionen hin", sondern stecke sie lokal und inline an Ort und Stelle, möglichst dicht zum Funktionsaufruf hin. Dann klappe ich sie zu und der Raum, den der Code einnimmt, stört nicht mehr. Und dann, bei Bedarf, wenn ich wissen möchte, was in der Funktion läuft, klappe ich sie einfach wieder auf.
Ich gehe sogar so weit, dass ich semantisch zusammengehörende Abschnitte in eine Funktion kapsele, die nur den einen Grund hat: zu existieren, um zu kapseln. Das sieht dann prinzipiell so aus:
Vorher:
Julius
Gunnar Bittersmann
MudGuardCodezeile 1
Codezeile 2
Codezeile 3
Codezeile 4
Nachher:
Codezeile 1
function xyz() {
Codezeile 2
Codezeile 3
}
xyz();
Codezeile 4
Wobei ich dann den Inhalt von xyz() mit Folding einklappe, sodass final rein visuell das zu sehen ist:
Codezeile 1
function xyz() {
xyz();
Codezeile 4
So hab ich mir angewöhnt, "folding-orientiert" zu coden. Hat riesengroße Vorteile, weil man dann nicht mehr so viel hüpfen muss. Folding "kapselt" eine Funkktionalität rein visuell. Sowas kann ich mit Funktionen, die irgendwo oben im Code stehen, nicht erreichen. Auch OOP schützt Dich nicht vor Fragmentierung, denn ob die Funktionalität in der aktuellen Datei in einer Funktion steht oder in einer extra Datei als Klasse – im Falle einer Änderung musst Du hinhüpfen.
Folding ist nicht einfach nur Zuklappen, wie die meisten meinen. Wenn Du Folding aktiv als Strukturprinzip einsetzt, dann wirst Du automatisch "folding-orientiert" Coden. Und das ist ein vollkommen anderes Coden als ohne Folding.
Wiederverwendbaren Code kann man mit Folding natürlich nicht "vor Ort" kapseln. Das sind dann die Situationen, wo man mit dem Hüpfen leben muss.
Leider gibt es nicht sehr viele Editoren, die Folding visuell gut darstellen. Deshalb ja meine Frage, ob jemand diesbezüglich gute Erfahrungen gemacht hat.
Gruß, fischlak
PS: Sorry für die vergessene Anrede in meinem ersten Posting, hatte ich im Eifer des Gefechts vergessen. Wollte ich gerade ändern, aber "Bearbeiten" geht nicht mehr...
Hallo fischlak,
generell bin ich mit Visual Studio Code ganz zufrieden, den gibt's auch für Linux. Unter Windows liebe ich auch Notepad++.
Ansonsten will ich deine Arbeitsweise nicht schlecht reden. Ich sage nur, dass ich anders arbeite. Dass ich mein 6, 12 oder 24 älteres Ich dabei regelmäßig verfluche, ist wohl normal.
Code in Funktionen zu kapseln, nur um ihn wegfalten zu können, spricht gegen den Editor. Für den Fall, dass dein Editor {}-Pärchen falten kann, reicht es schon, den Code, den Du einklappen willst, in geschweifte Klammern zu setzen.
Ein Vorteil von Kapselfunktionen ist, dass man damit schon vor 20 Jahren lokale Variablen definieren konnte, die außerhalb nicht sichtbar sind. Das kannst Du, wenn Du Variablen mit let oder const deklarierst, mittlerweile auch schon mit geschweiften Klammern haben. Die definieren einen Anweisungsblock, der auch ohne if oder while existieren darf.
let a = 3;
{
let a = 9, b = 4;
console.log(a, b); // 9
}
console.log(a); // 3
console.log(b); // ReferenceError: b is not defined
Nicht, dass ich Dir raten wollte, a zu überlagern. Ich wollte nur die Lokalität der Variablen in den geschweiften Klammern zeigen. Mit var statt let würde a nach dem {..} Block weiter den Wert 9 haben und b noch zugreifbar sein.
Wenn Du unbedingt Funktionen willst - kennst Du IIFEs (immediately invoked function expression)? Damit kannst Du deine Einklapp-Funktionen anonym halten:
(function() {
// Codezeilen
})();
Rolf
Hallo Rolf, Code in geschweifte Klammern zu setzen, um sie einklappen zu können, würde nicht das Ziel erreichen, das ich anstrebe, weil der Editor dann nur den Klammerbereich verbirgt, und ich wüßte nicht, was dahintersteckt, während ein sprechender Funktionsname sehr oft schon ohne Kommentar auskommt. Auch reicht es nicht, z.B. einen if-Block einzuklappen, weil ich auch hier nicht weiß, was da passiert. Das entscheidende ist: Eine Funktion hat einen Namen, der nach dem Einklappen stehen bleibt. Der Inhalt der Funktion ist dann für mich eine Blackbox. Ich muss nicht wissen, was da passiert, sondern nur, was ich bekomme. Und was ich bekomme, steht im Funktionsnamen. Deshalb ist es wichtig, für sowas Funktionen zu nehmen und das Folding nicht als "einfach zuklappen" zu verstehen, sondern als Methode der visuellen Strukturierung, als Coding-Strategie. Vielleicht sollte ich mal ein praktisches Beispiel aus meinem Projekt nehmen – Bilder sagen ja mehr als 1000 Worte.
Ich hab eine Hilfsfunktion, die ich normalerweise "oben zur Gruppe Funktionen" platzieren würde. Aber das würde, falls ich mal in diese Funktion reisehen möchte, dazu führen, dass ich unnötig STRG+F, dann zur Funktion springen, danach wieder zurück springen oder scrollen. Solches Hüpfen lässt sich deutlich reduzieren, wenn ich die Funktion lokal und inline setze. Hier mal herauskopiert aus einer größeren Funktion:
// ... Code
if (svgTyp === "rect") {
const { x, y, width, height, alignment } = _KONFIG_;
function fitIntoBox(boxWidth, boxHeight) { // Bild in einen Bereich einpassen (seitenverhältniserhaltend)
const boxRatio = boxWidth / boxHeight;
let renderWidth, renderHeight;
if (LOGO_ASPECT_RATIO > boxRatio) {
// Bild ist "breiter" → Breite begrenzt
renderWidth = boxWidth;
renderHeight = boxWidth / LOGO_ASPECT_RATIO;
} else {
// Bild ist "höher" → Höhe begrenzt
renderHeight = boxHeight;
renderWidth = boxHeight * LOGO_ASPECT_RATIO;
}
return { renderWidth, renderHeight };
}
// Bild seitenverhältniserhaltend einpassen
let { renderWidth, renderHeight } = fitIntoBox(width, height);
// ... Code
Ich brauch fitIntoBox() nur an dieser einen Stelle (letzte Zeile im Code). In der Praxis klappe ich sie dann ein und sehe im Editor nur die Zeile mit der Funktionsdeklaration:
Den eingeklappten Zustand merkt Kate sich, wenn man die JS-Datei in eine "Sitzung" legt. Es geht nicht darum, einfach nur "einzuklappen". Es geht darum, eine Funktionalität visuell zu kapseln, anstatt sie irgendwo im Skript abzulegen oder in externe Dateien. Durch diese lokale Nähe ergibt sich dann: weniger Springen-müssen.
OOP macht das auch: Du lagerst im Prinzip Funktionalität aus. Dich interessiert nicht, wie die Klasse das macht; Du musst nur wissen, WAS sie macht, was also die Rückgabe ist.
Dass ich mit let und const den lokalen Scope nutzen kann, ist mir bekannt. Aber nur zu verbergen allein, ist ja nicht Sinn der Sache. Und eine lokale anonyme IIFE bringt ja in diesem Sinne nichts, weil ich sie dann "von außen" nicht aufrufen kann.
Wenn ich Folding richtig nutze, also nicht einfach nur zuklappen, sondern Folding als visuelles Strukturierungswerkzeug nutze, mit dem Ziel, allen Code möglichst lokal zu halten, dann kann ich (in eingeklapptem Zustand der einzelnen Funktionsblöcke) auch eine längere Funktion leicht überblicken.
Im Prinzip ist Folding-basiertes Coden nichts anderes, als Funktionen, die sonst zu lang werden würden, kurz zu halten. Aber eben nicht, indem man Funktionsblöcke irgendwo hinschreibt (wie z.B. die Hilfsfunktion), sondern lokal in visueller Nähe hält, mit dem Zweck, dann nicht mehr wie bescheuert hin- und herhüpfen zu müssen.
Ich glaub, das kann man nur verstehen, wenn man es mal praktisch anwendet.
Gruß, fischlak
Lieber fischlak,
ich nutze gerne Code-Folding. Als Editor benutze ich Geany (unter Linux, früher Notepad++ unter Windows).
Wenn ich in Deinen Postings von „Funktionen“ lese, scheint es mir, dass Du kaum OOP betreibst. Ein Objekt hat nämlich keine Funktionen, sondern Methoden, wie man im OOP-Sprech sagt. Und von Klassen lese ich auch, aber nicht von Objektinstanzen, was auch dafür spricht, dass Du OOP nicht wirklich verwendest.
// ... Code if (svgTyp === "rect") { const { x, y, width, height, alignment } = _KONFIG_; function fitIntoBox(boxWidth, boxHeight) { [...] return { renderWidth, renderHeight }; } // Bild seitenverhältniserhaltend einpassen let { renderWidth, renderHeight } = fitIntoBox(width, height); // ... Code
Klassiker. Da steht im Grunde eine IIFE, nur dass sie eben nicht so aussieht. Vorher Code, dann Funktionsdefinition, dann wieder Code. Das sieht für mich nach ziemlichem Kuddelmuddel aus.
Ich brauch fitIntoBox() nur an dieser einen Stelle (letzte Zeile im Code).
Funktionen oder Methoden definiere ich dann, wenn sie mehr als einmal verwendet werden. Wenn also Dein fitIntoBox nur ein einziges Mal im Code aufgerufen wird, dann wäre das für mich ein Grund, dass es regulär als eine Folge von nicht-gekapselten Anweisungen im Code steht. Dass Du es aber Kapseln möchtest, würde für mich ein Auslagern in eine eigene Klasse erzwingen. Diese kann dann (wenn es sein muss nur einmal) so verwendet werden:
class SVGImage {
#aspectRatio = 1;
constructor () {
// was auch immer
}
getDimensions () {
return {
aspectRatio: this.#aspectRatio,
height: this.#height,
width: this.#width
};
}
#height = 0;
resizeToDimensions (width, height, keepAspectRatio) {
// was auch immer
}
#width = 0;
}
const img = new SVGImage();
img.resizeToDimensions(width, height, true);
const imgDimensions = img.getDimensions();
console.log(imgDimensions.width);
console.log(imgDimensions.height);
console.log(imgDimensions.aspectRatio);
Für meine Programmierpraxis ist es ein Unding, wenn mir ein Funktionsaufruf mehrere Rückgabewerte liefert. Genau ein Wert darf zurückgegeben werden, der aber gerne (siehe getDimensions) ein Objekt mit mehreren Eigenschaften sein darf.
Vielleicht ist es nervig, wenn man im Code springen muss, aber wenn man wirklich mit Objekten arbeitet, dann weiß man ja in aller Regel die wichtigen Eigenschaften und Methoden, sodass man eben nicht springen muss. Und gute Editoren können beim Schreiben von Methodennamen bereits die Parameterliste anzeigen, damit man z.B. die Reihenfolge richtig notiert. Und wenn das kein Problem sein soll, dann verwendet man als Funktionsparameter eben Objekte, in denen die Variablen als Eigenschaften erwartet werden:
resizeToDimensions (dimensions) {
let height = 0, keepAspectRatio = true, width = 0;
if (dimensions.hasOwnProperty("height")) {
height = dimensions.height;
}
if (dimensions.hasOwnProperty("keepAspectRatio")) {
keepAspectRatio = dimensions.keepAspectRatio;
}
if (dimensions.hasOwnProperty("width")) {
width = dimensions.width;
}
// was auch immer
}
OOP macht das auch: Du lagerst im Prinzip Funktionalität aus. Dich interessiert nicht, wie die Klasse das macht; Du musst nur wissen, WAS sie macht, was also die Rückgabe ist.
Das ist nur ein Teil der Wahrheit. Das Auslagern ist eher ein Nebeneffekt, der dadurch entsteht, dass die Instanzen ihren eigenen Variablenspeicher haben. Die Funktionen sind nun als Methoden an die Instanzen gebunden, was bedeutet, dass alle das Gleiche können, obwohl sie meist unterschiedlich sind. Und ja, man kann damit den Code schön falten, aber man kann ihn sogar in eine andere Datei auslagern! Und das hilft bei großen Projekten schon sehr beim Bewahren des Überblicks. Und beim Trennen von Zuständigkeiten hilft es auch. Gewisse Fehlerquellen können dann nicht mehr im Riesenkuddelmuddel sein, sondern in einer ganz bestimmten Klasse, die für z.B. SVG-Grafiken zuständig ist.
Wenn ich Folding richtig nutze, also nicht einfach nur zuklappen, sondern Folding als visuelles Strukturierungswerkzeug nutze, mit dem Ziel, allen Code möglichst lokal zu halten, dann kann ich (in eingeklapptem Zustand der einzelnen Funktionsblöcke) auch eine längere Funktion leicht überblicken.
Für mich hört sich das so an, als würdest Du schreiben, dass man Wege deshalb anlegt, damit man ihnen Randmarkierungen geben kann, weil Randmarkierungen für mehr Sicherheit bei der Benutzung der Wege bieten. Aber will man Wege nicht deswegen, weil man von A nach B kommen möchte, anstatt hauptsächlich deswegen, um Randmarkierungen anbringen zu können? Dein Folding klingt für mich wie die Randmarkierungen.
Liebe Grüße
Felix Riesterer
Hallo Felix,
Danke für deine ausführliche Antwort. Ich glaube aber, wir reden aneinander vorbei.
Du beschreibst OOP‑Strukturierung, Klassen, Verantwortlichkeiten und Dateiorganisation. Mein Thema ist aber nicht Architektur, sondern Editor‑Ergonomie und Navigation.
Mir geht es nicht darum, wie man Code objektorientiert organisiert, sondern darum, wie man beim Arbeiten weniger springen, suchen und scrollen muss. Folding nutze ich nicht als "Randmarkierung", sondern als Werkzeug, um visuelle Nähe herzustellen und mentale Last zu reduzieren.
Ob eine Funktion nur einmal vorkommt oder in eine Klasse gehört, ist für mein Thema zweitrangig. Mir geht es ausschließlich darum, dass ich sie lokal sehe, einklappen kann und dadurch den Arbeitsfluss verbessere.
Das ist ein anderes Ziel als OOP‑Strukturierung. Deshalb wirken unsere Ansätze unterschiedlich, obwohl sie sich nicht widersprechen.
Wie ich bereits sinngemäß schrieb: Ich nutze Folding als Arbeitswerkzeug, nicht als Architekturprinzip. Deshalb ist für mich lokale Nähe wichtiger als Klassendesign.
Gruß, fischlak
Lieber fischlak,
Deshalb wirken unsere Ansätze unterschiedlich, obwohl sie sich nicht widersprechen.
ich sehe da klar einen Widerspruch, nachdem ich Dein vorheriges Posting ausführlich gelesen und das Code-Beispiel gesehen habe.
Liebe Grüße
Felix Riesterer
Hallo Felix, und welchen Widerspruch bitte? Gruß, fischlak
Hallo fischlak,
mir schriebst du
Deshalb ist es wichtig, für sowas Funktionen zu nehmen und das Folding nicht als "einfach zuklappen" zu verstehen, sondern als Methode der visuellen Strukturierung, als Coding-Strategie.
„Coding-Strategie“ klingt sehr wie Architektur.
Ich sehe aber nicht viel Sinn darin, wenn wir uns weiter gegenseitig unsere Standpunkte präsentieren. Du willst linear/prozedural arbeiten und bei 3000-4000 Zeilen Code ist das noch machbar. Felix erstellt und betreut eine komplette Schulverwaltungssoftware, die dürfte 2 Größenordnungen darüber liegen, und ohne eine ordentliche horizontale Trennung des Codes in Schichten (Daten, Steuerung, Businesslogik, Utilities) ist das zum Scheitern verurteilt.
Allerdings ist es auch zum Scheitern verurteilt, wenn man für jede fachliche Änderung drölf Klassen anfassen muss. In dem Fall stimmt das Design nicht. Vielleicht ist dir so etwas passiert, OOD fällt nicht vom Himmel und muss erlernt werden. Der Lernprozess beinhaltet zumeist einen zwei- bis dreimaligen Neustart, wenn man allein damit beginnt.
Rolf
Hallo Rolf,
ja, Du hast eigentlich recht. Das Folding bewirkte, dass sich tatsächlich ein anderes Architekturprinzip bei mir ergeben hat. Folding hat die Art verändert, wie ich Code organisiere.
Mit Folding kann ich Funktionen lokal halten, einklappen und als visuelle Bausteine nutzen. Ohne Folding würde ich so nie schreiben – das wäre dann tatsächlich Chaos. Mit Folding entsteht aber ein eigener, konsistenter Stil, der für mich beim Arbeiten sehr effizient ist. Es ist einfach eine andere Art, den Code beim Arbeiten zu strukturieren – eher ergonomisch als architektonisch.
Deshalb kann ich Navigation minimieren, weil ich z.B. einen eingeklappten Block ähnlich wie einen Link im Hypertext benutzen kann. Ich weiß, was hinter dem Link steckt, und wenn ich dann doch mal nachsehen muss, dann klicke ich eben auf den Link.
Deshalb wollte ich mich ja erkundigen, welche Editoren sich diesbezüglich als besonders praktikabel erwiesen haben. Denn ohne einen geeigneten Editor funktioniert dieses Prinzip nicht.
Felix schrieb, er arbeite mit Geany. Nun, mir ist Geany bekannt, aber für Folding-Coden nicht zu gebrauchen. Denn es ist sehr entscheidend, dass der Folding-Zustand persistent bleibt. Und das trifft auf Geany nicht zu, auch dann nicht, wenn man in Geany ein Projekat anlegt.
Irgendwie stellt sich gerade bei mmir das Gefühl ein, dass Folding allgemein kaum oder wenig genutzt wird, kann das sein?
Gruß, fischlak
Hallo fischlak,
ich bin jetzt gerade unsicher, ob Visual Studio den Foldingstatus speichert. Dabei ergibt sich die Schwierigkeit, dass dieser Status kein Teil des Dokuments ist, sondern separat gespeichert werden muss. Das tun viele Editoren nicht, und das kann durchaus der Grund sein, warum Folding als Codestrukturierungsansatz eher nicht verfolgt wird. Ganz abgesehen davon, dass ich die Idee, eine Funktion allein als Orientierungspunkt für Code-Folding zu erstellen, für abwegig gehalten hätte.
In C# kann ich mit #region benannte Bereiche definieren, die aufklappbar sind, und es kann passieren, dass Studio ein C#-Modul öffnet und erstmal alle Regionen zu sind. Das ist sicher nicht in deinem Interesse.
Und ja, wir sind alle Editoren mit Tabs gewöhnt, wo viele Sourcen parallel offen sein können, und das daraus entstehende horizontale „Gehüpfe“ finden wir sehr erträglich. Vertikales „Gehüpfe“ in einer großen Datei finde ich ebenfalls unangenehm. Aber mit Kate hast Du dafür ein sehr mächtiges Tool in der Hand und es wundert mich, dass du Folding den Tabs vorziehst. Aber – jedem das Seine
Rolf
Hallo Rolf,
btw: Visual Studio ist proprietär, nutze ich prinzipiell nur dann, wenn es definitiv keine Alternative gibt. Und es gibt immer eine.
Unter Kate kann ich ja den Folding-Status nur dann speichern, wenn ich eine "Kate-Session" anlege. Dann wird der Status in der Projektdatei *.katesession gespeichert, inkl. prima Backup-Möglichkeit. Und wenn ich die zu bearbeitende JS-Datei dann ohne Session öffne, dann beeinflusst das die Projekteinstellungen nicht. Ich kann also prima in der Session arbeiten (mit Folding) und dazu eine zweite Kate-Instanz der selben Datei (ohne Folding) halten, um z.B. bestimmte Codestellen zu sichten, ohne mir dabei die Folding-Struktur zu zerschießen, z.B. weil ich während des Suchens viele Blöcke aufklappe.
Ich hab VSCodium ausprobiert, also die Open-Source-Variante zu Visual Studio Code (also mit "code" jetzt, nicht das Teil ohne). Ja, VSCodium speichert den Folding-Status, und man kann auch "Workspaces" anlegen, also Projekte, wo der Folding-Status projektbezogen persistent bleibt. VSCodium Ist also diesbezüglich brauchbar. Allerdings hat das Prog keine Features mit sich gebracht, die bei Kate nicht auch schon vorhanden wären, inkl. LSP-Clienten. VSCodium ist eine sehr brauchbare Alternative diesbezüglich.
Thema Hüpfen:
Meiner Erfahrung nach teilt sich der Gesamt-Coding-Zeitbearf eines Projektes pro einzelner Datei (jetzt mal konkret hier eine JS-Datei) so auf:
Coding: 30 %
Debugging technischer Fehler: 20 %
Fehler und Konzeptfehler bei Erstellung/Erweiterung/Änderung: 50 %
Wobei gerade bei Erweiterungen und Änderungen die meisten Fehler entstehen. Debugging/Fehlersuche nehmen also im mittel 70% der Zeit ein. Wenn die standardisierten Konzepte und Dogmen so gut sind – warum ist der Zeitanteil an Fehlersuche dann so hoch?
Ich hab schon sehr viele JS-Dateien (wir sind ja beim Thema JS) gesehen. Auch von guten Entwicklern. Und mich wundert es nicht, dass da so viele Fehler passieren, weil jedes Projekt mit der Zeit immer größer wird und es immer schwerer wird, die Übersicht und den Durchblick zu behalten. Dehalb versuch ich es eben mal mit Folding. Bisher muss ich sagen, dann sich eine deutlich bessere Übersicht einstellt, vorausgesetzt, man nutzt Folding richtig.
Gruß, fischlak
Hallo Rolf,
Ich sehe aber nicht viel Sinn darin, wenn wir uns weiter gegenseitig unsere Standpunkte präsentieren. Du willst linear/prozedural arbeiten und bei 3000-4000 Zeilen Code ist das noch machbar. Felix erstellt und betreut eine komplette Schulverwaltungssoftware, die dürfte 2 Größenordnungen darüber liegen, und ohne eine ordentliche horizontale Trennung des Codes in Schichten (Daten, Steuerung, Businesslogik, Utilities) ist das zum Scheitern verurteilt.
Das stimmt nicht.
Ich habe komplett alleine eine ERP Software geschrieben, die sicher 2 Größenordnungen über einer Schulverwaltungssoftware liegen dürfte (130 sql tabellen, ca. 300 scriptdateien, > 1GB Code inkl. Images allerdings) und die ist bis auf wenige Aussnahmen, die ich OOP basiert geschrieben habe, komplett prozedural.
Sie läuft seit 20 Jahren völlig problemlos (von den üblichen Anpassungsproblemen und Bugs, die normnal sind mal abgesehen) im Produktivbetrieb...
Entscheidend ist, dass man selber eine Logik für gut befindet, die Spaghetticode verhindert und Aufgaben bündelt bzw. difeerenziert. Das bekommt man linear/prozedural sehr schön hin - keine Datei muss mehr als 3-4k Zeilen Code haben.
Gruß, Hawk
Hallo Hawk,
sorry, das habe ich vielleicht unklar ausgedrückt. Ich habe Schichtentrennung gesagt und nicht erwähnt, dass das auch ohne OO geht. Fischlaks Folding-Technik habe ich so verstanden, dass eine solche Trennung seiner Lokalitätsidee widerspricht.
Saubere Schichtentrennung ist auch prozedural möglich.
Wenn Du allerdings UI-Steuerung, Logik und DB-Zugriffe ohne Schichtentrennung ineinandergelegt hast, dann hast Du meinen höchsten Respekt, dass Du dabei geistig gesund geblieben bist.
Rolf
Hallo Rolf,
es geht nicht darum, pauschal und prinzipiell alles lokal zu halten. Natürlich kann man nicht, um bei Deinem Beispiel zu bleiben, UI-Steuerung, Logik und DB-Zugriffe auf einen Haufen packen.
Es geht darum, unnötige nicht-lokale Implementationen zu vermeiden. Ich kann z.B. eine Hilfsfunktion auch lokal inline setzen. Und wenn ich die später mal aufklappe, dann sehe ich unmittelbar vor Ort das Zusammenspiel von z.B. Variablen und Rückgabewerten. Ich bin dann mit dem Erfassen der Logik viel schneller, als wenn ich mit F12 hin- und herrutsche, in Tabs hin- und herklicke oder mit "geteilter Ansicht" arbeite.
Es geht nicht darum, dogmatisch lokal zu bleiben, sondern Un-Lokalität (also Fragmentierung) immer da, wo es sich anbietet, zu vermeiden, also immer, wenn es Sinn macht. Und häufig macht es Sinn. Ich schätze mal, dass sich durch dieses Prinzip ~ ein Drittel aller Implementationen zumindest in der Nähe der Referenz halten lassen können. Eher mehr. So jedenfalls meine Erfahrung.
Gruß fischlak
Hallo Rolf,
sorry, das habe ich vielleicht unklar ausgedrückt. Ich habe Schichtentrennung gesagt und nicht erwähnt, dass das auch ohne OO geht. Fischlaks Folding-Technik habe ich so verstanden, dass eine solche Trennung seiner Lokalitätsidee widerspricht.
Vielleicht hast du es auch korrekt ausgedrückt und ich habe es nur falsch verstanden. 😉
Saubere Schichtentrennung ist auch prozedural möglich.
Genau das.
Wenn Du allerdings UI-Steuerung, Logik und DB-Zugriffe ohne Schichtentrennung ineinandergelegt hast, dann hast Du meinen höchsten Respekt, dass Du dabei geistig gesund geblieben bist.
Den nehme ich gerne entgegen – gerade von dir ist mir das eine Ehre.
Inhaltlich glaube ich, dass hier auch viel persönliche Arbeitsweise und Erfahrung/Gewohnheit reinspielt. Ich habe in vielen Projekten sowohl im Team als auch allein gearbeitet und oft auch mit bereits vorgegebenen Architekturen.
Was ich eigentlich ausdrücken wollte: Mich stört nicht das Prinzip der Schichtentrennung an sich, sondern eher der praktische Entwicklungsfluss, der dadurch entsteht. Wenn z.b. meine Daten und Logik in Python liegen und das UI als Webinterface getrennt davon lebt, bedeutet das in der Praxis oft, dass ich ständig zwischen zwei Codewelten hin- und herspringen muss. Gerade bei iterativer Entwicklung oder bei dynamischen Flows (z. B. über WebSockets) fühlt sich das für mich schnell nach nötigem, aber für mich unerwünschtem Kontextwechsel an - weshalb ich innerhalb Projekten, die solche Kontextwechsel nicht zwingend erfordern, für mich andere Schichten als "flüssiger" im arbeiten empfinde.
Ich habe tatsächlich gemerkt, dass ich mich in manchen stark getrennten Webarchitekturen weniger wohlfühle – nicht, weil ich die Gründe dafür (Sauberkeit, Testbarkeit, Austauschbarkeit etc.) nicht sehe, sondern weil es sich für bestimmte Problemklassen für mich weniger direkt und dadurch schwerfälliger anfühlt.
Gleichzeitig sehe ich natürlich, dass saubere Trennung in vielen Kontexten absolut sinnvoll oder sogar notwendig ist, insbesondere wenn mehrere Entwickler zusammen arbeiten oder Systeme langfristig wartbar und erweiterbar bleiben müssen.
Am Ende ist es für mich persönlich (nicht allgemeingültig) wahrscheinlich wirklich eine Mischung aus Kontext, Projektgröße und persönlicher Arbeitsweise – und weniger eine Frage von richtig oder falsch.
Gleichwohl ist auch in von mir alleine verantworteten Projekten ein Struktur, eine Schichtentrennung oder gar Kapselung unerlässlich, nur eben nicht immer die, die man erst einmal als "klassisch" bezeichnen würde.
Ich stelle aber mal eine Frage in den Raum: Ist es nicht bei vielen Entwicklern so, dass sie neben gängigen Methoden der Schichtentrennung und Strukturierung ihre ganz eigene, über die Zeit gewachsene Arbeitsweise entwickeln?
Gruß,Hawk
Hallo Rolf,
Fischlaks Folding-Technik
Ich meins ja nicht schlecht. Mir geht es darum, meine Fehlerquote zu reduzieren. Und meine Fehlerquote war recht hoch beim Coden. Und ich weiß von anderen, dass es denen nicht besser ergeht.
Mir geht es darum, unnötige mentale Last zu reduzieren. Ich möchte nicht wissen, wieviele Fehler gerade deshalb entstehen, weil wir beim Auffassen von Codezeilen mental schnell überfordert sind, besonders bei größerer semantischer Kompression.
Und erst recht Anfänger: Anfänger legen über 90% ihrer Zeit nur für Debugging und Fehlersuche hin und nicht für das Coden selbst. Und sowas soll Spaß nachen?
Vielleicht ist Dir der Begriff Chunking bekannt? Aktuell geht man davon aus, dass die Kapazität des Kurzzeitgedächtnisses bei 3 bis 4 Chunks liegt. Und selbst Gedächnis-Genies werden nie auf allerhöchstens 9 Chunks kommen.
Durch den eingeklappten Folding-Status reduziere ich die Anzahl der Chunks, die mir der Screen anzeigt, um mindestens 1. Und das ist sehr viel, wenn ich von einem Auffassungsvermögen von 4 Chunks ausgehe.
Hier mal ein aktuelles Beispiel, woran ich jetzt gerade sitze und was ich zuletzt geschrieben habe:. Jetzt sag mir mal bitte ganz objektiv, was daran verkehrt sein soll:
...Code
(function decodeText() { /* Textinhalt decoden */
// Quotes
textContent = textContent.replace(/^"|"$/g, "");
// Komma, Semikolon
textContent = textContent.replace(/,/g, "%2C").replace(/;/g, "%3B");
})();
Code...
Eingeklappt sieht es dann so aus:
...Code
(function decodeText(txt) { /* Textinhalt decoden */ ------------------------------------------------------------------
})();
Code...
Natürlich hätte ich auch so schreiben können:
textContent = textContent.replace(/^"|"$/g, "")
.replace(/,/g, "%2C").replace(/;/g, "%3B");
Und das, obwohl ich alles in 1 Zeile hätte stopfen können. Jedoch ist es viel einfacher, im eingeklappten Zustand decodeText zu lesen anstatt solch eine lange Zeile, deren Inhalt unweigerlich mentale Last mit sich bringt.
Für sich betrachtet ist die Zeile kein Problem. Aber wenn ich damit beschäftigt bin, im Rahmen eines routinierten Arbeits-Alltags, eine längere Code-Folge nochmal durchzusehen, weil ich mir z.B. das Zusammenspiel zweier Variablen vergegenwärtigen will, dann stellt das Folding eine mentale Entlastung dar, denn ich kann mich dadurch auf das Wesentliche konzentrieren.
Ich pers. gehe sogar noch ein Stück weiter:
Ich brauch die o.a. Funktion 2 mal im Skript, sodass ich sie gem. Dogma normalerweise schön ordentlich in die Gruppe "der anderen" platzieren würde.
Aber die lokale Präsenz ist mir wichtiger als DRY, also wiederhole sie an der anderen Stelle und Pfeife auf die Gruppe, die zur Hälfte meist nur Selbstzweck ist. Und das nur, um hier ein kleines Stückchen mehr mentale Entlastung zu bekommen. Den kleinen Nachteil dieses winzigen Stückchens doppelten Codes nehme ich in kauf.
Gruß, fischlak
Hallo fischlak,
Jetzt sag mir mal bitte ganz objektiv, was daran verkehrt sein soll
Verschiedenes.
Zunächst mal wird Dir verborgen, dass der Inhalt der Variablen textContent modifiziert wird. Das gehört unbedingt in den Kommentar hinein. Denn ansonsten ist das eine böse Tretmine.
Sodann noch dreierlei:
unquoteAndUrlEncodeSeparators lauten, sofern Du ihre Aktivität beschreiben willst. Alternativ kann sie auch in fachlichen Begriffen benannt werden, d.h. der Name beschreibt, welchem Zweck diese Manipulation dient. Da ich den nicht kenne, kann ich dafür keinen Vorschlag machen.Sobald die Funktion einen sprechenden und korrekten Namen hat, kannst Du sie auch in den Funktionszoo abschieben und faltungsfrei
textContent = unquoteAndUrlEncodeSeparators(textContent); // encode ,;
schreiben.
Je nach Datenlage brauchst Du das aber vielleicht auch gar nicht. Könnte
textContent = encodeURIComponent(textContent.trim('"'));
vielleicht auch den Job tun?
Rolf
Hallo Rolf,
Danke für die Hinweise.
Ich war vorhin "mittendrin" und hab für das Posting herauskopiert. Das Beispiel vorhin hatte ich aus einer Encoding-Funktion herauskopiert, das war noch gar nicht fertig. Ich hab inzwischen umgestrickt, der finale Code-Abschnitt sieht jetzt so aus:
const text = rawText.replace(/^"|"$/g, ""); // Quotes entfernen
function decodeText(txt) {
/* %2C und %3B sind nur die Platzhalter, die in der Funktion
* svgToConfigString() eingesetzt wurden: txt.replace(/,/g, "%2C").replace(/;/g, "%3B");
* um Komma und Semikolon zu ersetzen */
return txt.replace(/%2C/g, ",").replace(/%3B/g, ";");
}
const decoded = decodeText(text);
So sieht es natürlich ausgeklappt aus. Eingeklappt so:
const text = rawText.replace(/^"|"$/g, ""); // Quotes entfernen
function decodeText(txt) { -------------------------------------------------
}
const decoded = decodeText(text);
Ich hab daraus einen "Folding-Block" gemacht, weil der Abschnitt inkl. Kommentar mir zu viel Raum einnahm und ich beim Lesen von decodeText weiß, was los ist.
kannst Du sie auch in den Funktionszoo abschieben und faltungsfrei
Genau dieses Abschieben will ich ja vermeiden. Warum es (für mich) so das Beste ist, hab ich ja bereits geschildert.
Gruß, fischlak
Lieber fischlak,
const text = rawText.replace(/^"|"$/g, ""); // Quotes entfernen function decodeText(txt) { /* %2C und %3B sind nur die Platzhalter, die in der Funktion * svgToConfigString() eingesetzt wurden: txt.replace(/,/g, "%2C").replace(/;/g, "%3B"); * um Komma und Semikolon zu ersetzen */ return txt.replace(/%2C/g, ",").replace(/%3B/g, ";"); } const decoded = decodeText(text);
warum nicht gleich so?
function decodeText (txt) {
/* %2C und %3B sind nur die Platzhalter, die in der Funktion
* svgToConfigString() eingesetzt wurden: txt.replace(/,/g, "%2C").replace(/;/g, "%3B");
* um Komma und Semikolon zu ersetzen */
return txt.replace(/%2C/g, ",").replace(/%3B/g, ";");
}
// zuerst Quotes entfernen und dann URL-Codierungen zurückwandeln
const decoded = decodeText(rawText.replace(/^"|"$/g, ""));
Brauchst Du text später noch für andere Sachen?
Liebe Grüße
Felix Riesterer
Hallo Rolf,
wird Dir verborgen, dass der Inhalt der Variablen textContent modifiziert wird. Das gehört unbedingt in den Kommentar hinein. Denn ansonsten ist das eine böse Tretmine.
Übrigens befand sich der unfertige Code-Abschnitt von vorhin inmitten einer Schleife. Hat also den lokalen Scope der Schleife, sodass die Variable, die innerhalb dieses Scopes deklariert wird (und nein, nicht mit var...), bei jeder Iteration erneuert wird. Und weil die Schleife überschaubar ist, kann ich auch gut beurteilen, dass die Variable nicht so leicht zur Tretmine werden kann.
Ich hab während des Umstrickens dann aber Konstanten genommen, weil ich anhand des Konstantennamens jede Stufe innerhalb der Schleife gut nachvollziehen kann, auch ohne Kommentar. Aus diesem Grund neige ich auch dazu, mit Konstanten verschwenderisch umzugehen, weil sie hübsch jede Stufe schon im Namen beschreiben.
Hat eben seine Vorteile, wenn man maximal viel aus dem globalen Raum raushält, wie Du weißt. Selbst die lokal gesetzten Funktionen sind Luft, sobald der Scope verlassen wird – auch ein kleines Stückchen Sicherheit mehr.
Gruß, fischlak
Hallo fischlak,
rawText.replace(/^"|"$/g, "")
rawText.trim('"') passt nicht? Kann rawText denn weitere Anführungszeichen enthalten? "Das ist ein "Haus"" wäre für trim() tödlich. Es wäre allerdings auch für deinen Regex-Replace tödlich, wenn rawText keine Anführungszeichen als Delimiter enthält. Ist sichergestellt, dass der Inhalt rawText immer in Anführungszeichen steht oder sind die optional? Optionale Anführungszeichen und ein escaptes inneres Anführungszeichen am Ende wären ganz böse. Äh, sorry, mein Bugslayer-Gaul geht gerade mit mir durch…
Kurz gesagt: Eigentlich sollten die Anführungszeiche an Anfang und Ende nur entfernt werden, wenn sie paarig sind. rawText.replace(/^"(.*)"$/g, "$1") wäre sicherer.
Übrigens befand sich der unfertige Code-Abschnitt von vorhin inmitten einer Schleife.
Beachte:
for (let i=0; i<10; i++) {
function foo(x) {
return 2*x;
}
let j = foo(i);
}
Funktionen in JavaScript sind bekanntlich Objekte erster Klasse. Heißt: Pro Durchlauf erzeugt JavaScript ein Function-Objekt und macht es im Scope der for-Schleife unter dem Namen foo verfügbar.
Pro Funktionsaufruf wird dann noch ein Function-Scope erzeugt, was so eine Art internes Objekt ist. Beide Objekte müssen nach jedem Schleifendurchlauf vom Garbage-Collector entsorgt werden.
Bei 10 Durchläufen tut das nicht weh. Bei 1000 scheinbar auch nicht, aber für ein armes kleines Mobilchen bedeutet das, dass seine CPU länger ticken muss und länger am Akku nuckelt. Je nach Häufigkeit dieser Schleife kann das am Ende sichtbare Folgen für die Laufzeit haben.
Nur so als Denkanstoß für die Auswirkungen deiner Methode.
Rolf
Hallo Rolf,
rawText.trim('"') passt nicht?
rawText.trim('"') :-)
Ich bin ja nicht blöd und kann Leute beurteilen. rawText.trim('"') soll jetzt wohl ein Test sein...? Hat nicht geklappt... :-)
So sieht rawText z.B. aus: "aaaa". Immer in Anführungszeichen. Wobei auch mit "aa"aa" zu rechnen ist.
Wenn ich nur vorne hätte, also "aaaa, oder nur hinten, also aaaa", dann würde Deine Variante nichts tun, bliebe also unverändert. Aber: Ich hab immer eins am Anfang und eins am Ende, also ist es egal, ob Deine oder meine Variante.
In den 90-ern* hätte ich die Variante str.slice(1, -1) genommen, damit IE und NS nicht keuchen. Aber heute? Heute wäre str.slice im Vergleich zu RegEx evtl. 5 Nanosekunden schneller... :-)
Nur so als Denkanstoß für die Auswirkungen deiner Methode.
Danke für den Denkanstoß. Die Verhältnisse sind mir aber bekannt:
Ja, in jeder Iteration wird ein neues Objekt für foo erzeugt. Danach ist es nicht mehr referenziert, also GC‑fähig. Das ist korrekt. Beides wird nach dem Return freigegeben. Auch das ist korrekt.
Aber: Das ist extrem billig. Moderne JS‑Engines sind darauf optimiert, für sie sind Funktions-Objekte leichtgewichtige Strukturen: Die Funktion ist winzig! Ein Function‑Objekt besteht aus einem Pointer auf den Code, einem Pointer auf das Environment und ein paar Flags. Das ist lächerlich klein.
Und: Die Engine erkennt, dass der Funktionskörper identisch ist. Der Bytecode wird einmal erzeugt und in der Schleife wiederverwendet. Der GC wird das in Mikrosekunden wegräumen.
Und zusätzlich: Meine Schleife iteriert an dieser Codeposition im Mittel 6 mal. Ich nehme mal als äußerste Sicherheit 10 mal. Öfter kann sie nicht laufen, weil die Eingabe nur aus max. 10 Zeilen besteht. Selbst Wozniaks' und Jobs erstes Wischkastl hätte das mitgemacht und parallel dazu noch Doodle Jump gespielt, wenn es das zu der Zeit bereits gegeben hätte :-)
Gruß, fischlak
*PS: Ja, ich bin schon etwas älter. Ich war bereits 1998 hier im Forum. Damals unter meinem echten Vornamen. Und anfangs sehr zurückhaltend und wenig gepostet, weil ich keine Ahnung hatte. Seit ~ 2004 nicht mehr aktiv. Aber wenn ich eine Frage zu HTML, CSS oder JS hatte, hab ich immer wieder mal in die Doku oder später ins Wiki geschaut. Das waren stets meine erste Anlaufstellen.
Brauchte aber im Forum nie zu fragen, weil ich halt immer eine Antwort fand. Möchte nicht wissen, wieviele fragen, weil sie zu faul/bequem zum Lesen sind. Und ich schreibe immer noch "" anstatt „“ :-)
Aber eine Besserung hat sich eingestellt: Heute mach ich – und nicht − im Falle eines Gedankenstriches :-)
Hab mich beim Anmelden nicht gewundert, dass meine alten Zugangsdaten nicht mehr griffen. Aber hätte ja sein können… Trotzdem hätte ich dann meinen User-Namen geändert, heutzutage weiß man ja nie...
Hab mich eigentlich nicht nur wegen meiner Frage zu Folding und Editor wieder angemeldet, sondern weil mir nicht verborgen geblieben ist, dass die LLMs Euch die Show stehlen. Da dachte ich, einer mehr hier wird vielleich nicht verkehrt sein. Bin aber sonst eher posting-faul, nur im Moment hab ich etwas mehr Zeit.
Lieber fischlak,
rawText.trim('"') passt nicht?
rawText.trim('"') :-) [...]
So sieht rawText z.B. aus: "aaaa". Immer in Anführungszeichen. Wobei auch mit "aa"aa" zu rechnen ist.
was ist das denn für ein Anwendungsfall? SVG-Daten? Was machst Du denn mit denen, wenn Du solche Stringersetzungen und URL-Codierungen „reparieren“ musst? Klingt für mich nach einer etwas unorthodoxen Herangehensweise.
Liebe Grüße
Felix Riesterer
Hallo Fekix,
Laut offizieller Dokumentation (MDN):
trim() hat keine Parameter
trim() entfernt nur Whitespace am Anfang und Ende eines Strings
Alles andere bleibt unverändert
Das bedeutet
rawText.trim('"')
ist identisch zu
rawText.trim()
Gruß, fischlak
Lieber fischlak,
Hallo Fekix,
hmm...
[trim() ohne Parameter]
Meine Frage hatte mit Deinen Ersetzungen zu tun, wie Du sie in diesem Posting beschrieben hast.
Liebe Grüße
Felix Riesterer
Hallo Felix,
ach, das war in dem Moment mein aktueller Coding-Block, wo ich mitten drin war und den ich noch nicht fertig hatte und erstmal aus encodeText() herbeikopiert. Der hatte inhaltlich Fehler, wie das so ist mit dem Code-Kopieren...
Den bitte ich zu ignorieren. Der finale Code sieht anders aus.
Gruß, fischlak
Hallo Felix,
Hallo Fekix,
Oh, das seh ich jetzt erst :-(
Das war ich nicht. Das war einer meiner Finger in Keyboard-Kamikaze. Wenn ich den erwische…
Gruß, fischlak
Hallo fischlak,
trim() hat keine Parameter
Aua. Ich mache in letzter Zeit wohl zu viel C#. Dass das in Javascript nicht geht, hatte ich nicht auf den Schirm 😟.
Rolf
Hallo Rolf,
kein Problem, passiert mir auch öfter. Ich hab z.B. "Wozniaks' und Jobs Wischkastl" geschrieben. Bei einem Antwortposting hab ich dann gesehen, dass ich die korrekte Version, Wozniaks und Jobs', zwar im Kopf gehabt hatte, aber die Tippfinger da wohl anderer Meinung gewesen waren...
Ich mach viel mit FreePascal in Lazarus, und da verhält sich Trim('"') exakt wie in C#.
Auch Python verhält sich gleich, zwar mit strip('"'), aber immerhin gleiches Verhalten. Und PHP tut's wie erwartet, wenn auch in Erwartung der Variable als zus. Parameter.
Javascript ist der Ausreißer und ignoriert das Argument.
Ist also kein Wunder, dass man da mal was durcheinander bringt...
Das ist wie mit den Sprachen in der Welt und ihren Dialekten. Bei rund 7000 Sprachen, die genaue Zahl schwankt ja je nach Definition, und der noch größeren Zahl an Dialekten, muss man sich nicht Wundern, dass die Menschen sich nicht verstehen. Es gab ja ernsthafte Versuche, eine einheitliche Weltsprache zu schaffen, Esperanto z.B., aber keiner führte zu einer globalen Einheitssprache.
Vielleicht kann KI eine zukünftige Weltsprache erzeugen, wer weiß?! Und vielleicht kann KI dann auch die Programmiersprachen so gut es geht vereinheitlichen? Aber das werde ich wohl nicht mehr erleben.
Und ich glaube, dass solche Ansätze – wie so oft – an der menschlichen Eitelkeit scheitern werden.
Gruß, fischlak
Moin Rolf,
trim() hat keine Parameter
Aua. Ich mache in letzter Zeit wohl zu viel C#. Dass das in Javascript nicht geht, hatte ich nicht auf den Schirm 😟.
ist die Frage, was „gehen“ in dem Kontext bedeuten soll. Überzählige Funktionsargumente werden in JavaScript einfach ignoriert.
Viele Grüße
Robert
Moin,
Wenn ich nur vorne hätte, also "aaaa, oder nur hinten, also aaaa", dann würde Deine Variante nichts tun, bliebe also unverändert. Aber: Ich hab immer eins am Anfang und eins am Ende, also ist es egal, ob Deine oder meine Variante.
In den 90-ern* hätte ich die Variante str.slice(1, -1) genommen, damit IE und NS nicht keuchen. Aber heute? Heute wäre str.slice im Vergleich zu RegEx evtl. 5 Nanosekunden schneller... :-)
„5 Nanosekunden“ multipliziert mit der Anzahl an Schleifen-Durchläufen.
Ja, in jeder Iteration wird ein neues Objekt für foo erzeugt. Danach ist es nicht mehr referenziert, also GC‑fähig. Das ist korrekt. Beides wird nach dem Return freigegeben. Auch das ist korrekt.
Aber: Das ist extrem billig. Moderne JS‑Engines sind darauf optimiert, für sie sind Funktions-Objekte leichtgewichtige Strukturen: Die Funktion ist winzig! Ein Function‑Objekt besteht aus einem Pointer auf den Code, einem Pointer auf das Environment und ein paar Flags. Das ist lächerlich klein.
Wie „billig“ das wirklich ist, kannst Du Dir im Task-Manager der Entwickler-Tools Deines Browsers anschauen. Spoiler: Für „billige“ Garbage Collection sieht man die im Normalfall aber ziemlich prominent als bekanntes „Sägezahn“-Muster im Speicherbedarf als Funktion der Zeit.
Und zusätzlich: Meine Schleife iteriert an dieser Codeposition im Mittel 6 mal. Ich nehme mal als äußerste Sicherheit 10 mal. Öfter kann sie nicht laufen, weil die Eingabe nur aus max. 10 Zeilen besteht. Selbst Wozniaks' und Jobs erstes Wischkastl hätte das mitgemacht und parallel dazu noch Doodle Jump gespielt, wenn es das zu der Zeit bereits gegeben hätte :-)
Das Problem ist, dass jeder Entwicklerin so denkt und sich dann eben die Schlurigkeit/Nachlässigkeit/Ignoranz summiert, multipliziert oder im schlimmsten Fall potenziert. Das war mit die erste wichtige Sache, die ich in meiner Informatik-Laufbahn gelernt habe – neben „kaum macht man's richtig, geht's.“
Viele Grüße
Robert
Hallo Robert,
Für „billige“ Garbage Collection sieht man die im Normalfall aber ziemlich prominent als bekanntes „Sägezahn“-Muster im Speicherbedarf als Funktion der Zeit.
Meine Meinung: Für normale Web‑ oder App‑Logik ist Struktur, Lesbarkeit und mentale Effizienz deutlich wertvoller als Mikro‑Optimierung.
Inline‑Funktionen in Schleifen sind heute praktisch, ich betone praktisch, kein Performanceproblem. JS‑Engines optimieren Funktionsobjekte von Hause aus aggressiv. Moderne Engines wie V8, SpiderMonkey, JavaScriptCore, erzeugen Funktionsobjekte extrem effizient. Sie erkennen Muster; sie inlinen Funktionen; und sie recyceln Speicher sehr schnell. Der GC räumt solche kurzlebigen Objekte im "nursery space" (bekanntlich der ultraschnelle Bereich für temporäre Werte) auf.
Das bedeutet: Ja, es entsteht pro Iteration ein neues Funktionsobjekt – aber das kostet fast nichts. Der Unterschied ist messbar nur in extremen Szenarien (Millionen Iterationen in tight loops).
Ich kann doch nicht anderen Entwicklern pauschal unterstellen, dass sie nicht in der Lage wären, ihre Architektur beurteilen zu können, und dann Optimierungs-Dogmen aufstellen, die sich in der Praxis als unnötig herausstellen.
Klar:
wenn die Funktion groß ist und in mehreren Schleifen wiederverwendet wird
oder die Schleife millionenfach pro Sekunde läuft (z. B. in einem Game‑Loop)
oder die Funktion stabil optimiert werden muss (z. B. JIT‑Hot‑Path),
dann kann ich natürlich nicht lokal deklarieren. Aber für normale Web‑Apps ist Mikro-Optimierung irrelevant. Die Tatsache, dass die Funktion pro Iteration neu erzeugt wird, ist kein JIT‑Problem – das betrifft nur den GC, und der GC-Aufwand ist praktisch minimal.
Wenn man sich daran gewöhnt, lokale Inline‑Funktionen zu verwenden – auch in Schleifen –, dann besteht tatsächlich die Gefahr, dass man irgendwann Logik und Seiteneffekte vermischt, z. B. indem man in einer Schleifen‑lokalen Funktion plötzlich DOM‑Manipulationen unterbringt.
Aber:
Das ist kein Problem der Technik, sondern ein Problem der Disziplin und Architektur. Und es lässt sich sehr klar abgrenzen hier:
Ich verwende Schleifen-Inline‑Funktionen für reine Logik, also Berechnungen, Filter, Mappings, kleine Hilfsoperationen. Aber natürlich keine DOM‑Manipulationen, Netzwerkaufrufe oder State‑Mutationen außerhalb des lokalen Kontexts.
Solche Seiteneffekte (DOM‑Mutationen, Netzwerk‑I/O, globaler State) werden in dedizierten, benannten Funktionen außerhalb des Loop‑Scopes gekapselt: in klar benannte, höher liegende Scopes, – nicht global – , aber eine Ebene höher als die Schleife. Letzteres ist eine einfache mentale Leitplanke.
Und ich habe mir angewöhnt, Inline‑Funktionen klein zu halten. Wenn eine Inline‑Funktion zu groß wird, ist das für mich ein Signal: "Diese Funktion verdient eine eigene Ebene."
Bei mir dürfen Schleifen-Inline‑Funktionen rechnen, aber nichts anfassen. Alles, was blinkt, klickt oder DOM schreit, kommt in eine eigene Funktion außerhalb des Schleifen-Scopes.
Und zusätzlich:
Ich pers. arbeite sehr viel mit Folding (bei persistentem Folding-State im Editor). Das bedeutet: Große Funktionen klappe ich zu -> ich sehe sofort, wenn etwas zu groß wird. Gefoldete Inline‑Funktionen bleiben sichtbar -> ich erkenne schnell, wenn dort "zu viel passiert" oder "das Falsche passiert".
Der Vorteil der Kombination von Folding und Inline-Funktionen kommt überhaupt erst zum Tragen, wenn beide Techniken gleichzeitig angewendet werden. Sie ergänzen sich gegenseitig in einer Weise, die mich selbst überrascht hat! Geradezu perfekt in diesem Sinne! Imho sehr zu empfehlen.
Ich denke, wir werden uns wohl einig sein, dass globaler Namespace als riskant und fehleranfällig gilt. Ich hab diesbezüglich die klassische Kritik am "globalen Müllhaufen" in Erinnerung.
Du möchtest jetzt eine dogmatische Grenze ziehen und Inline-Funktionen aus Iterationen pauschal heraushalten. Kann man so machen, warum nicht.
Ich pers. wäre da etwas liberaler und würde keinem Entwickler voreingenommen eine Unfähigkeit unterstellen, dass er seine eigene Architektur nicht beurteilen könnte. Aber genau das tust Du, wenn Du meine Entscheidung für eine Schleifen-Inline-Funktion als "Schlurigkeit/Nachlässigkeit/Ignoranz" etikettierst.
Wenn ich eine Flasche Milch kaufen möchte, brauch ich keinen LKW. Und wenn ich umziehen will, dann ist ein VW Polo eher ungünstig. Die Entscheidung, ob LKW oder Polo, würde ich flexibel dem jew. Coder überlassen, anstatt belehrend Dogmen aufzustellen und danach den als Dogma-Ignoranten Etikettierten zu unterstellen, sie wären nachlässig und schludrig in der Nicht-Beachtung des Dogmas.
„kaum macht man's richtig, geht's.“
Ja, das ist typisch für Dogmatiker, dass sie ihr eigenes Dogma als "richtig" betrachten und dann noch einen draufsetzen, indem sie behaupten, bei ihnen "geht's", wie als ob es "immer" ginge:
Also ich ziehe meinen Hut vor Dir, wenn Du zu denjenigen gehörst, die nicht mind. 50% ihrer Zeit mit Fehlersuche und Debugging verbringen. Aber weil ich solch eine Person noch nie, nie kennengelernt habe, unterstelle und spekuliere ich jetzt mal, dass es bei Dir nicht anders sein wird.
Und nun frage ich Dich: Hast Du Dich nicht schon mal gefragt, warum das so ist? Also warum Coden überwiegend Fehlersuche und Debugging bedeutet?
Und warst Du selbst nicht oft genug frustriert und müde, weil Du stundenlang in Deinem eigenen Code irgendeinen Patzer identifizieren musstest?
Hier können, um beim Thema zu bleiben, lokal gehaltene Inline-Funktionen, auch innerhalb von Schleifen, sehr wohl hilfreich sein, weil ich "in dieser Ecke" aufgrund der Lokalität nicht wühlen muss.
Soweit mein Plädoyer für "Local Reasoning". Jetzt hab ich aber 2 Tage zu tun: Gestern ist die neue LTS Kubuntu zum Download freigegeben worden. Und die kommt jetzt auf meine Kiste. Ich könnte, wenn ich wollte, in 1 Stunde fertig sein. Aber ich will nicht alle meine Konfigs pauschal übernehmen, sondern mir das neue Teil sukzessive genauer ansehen :-)
Gruß, fischlak
Lieber fischlak,
Ich denke, wir werden uns wohl einig sein, dass globaler Namespace als riskant und fehleranfällig gilt. Ich hab diesbezüglich die klassische Kritik am "globalen Müllhaufen" in Erinnerung.
in Objekten hat man automagisch auch seinen eigenen Namespace... cool, gell?
Ich pers. wäre da etwas liberaler und würde keinem Entwickler voreingenommen eine Unfähigkeit unterstellen, dass er seine eigene Architektur nicht beurteilen könnte. Aber genau das tust Du, wenn Du meine Entscheidung für eine Schleifen-Inline-Funktion als "Schlurigkeit/Nachlässigkeit/Ignoranz" etikettierst.
Ich vertrete den Standpunkt, dass jeder Mensch das Recht hat, sich selbst komplett zum Affen zu machen.
Hier können, um beim Thema zu bleiben, lokal gehaltene Inline-Funktionen, auch innerhalb von Schleifen, sehr wohl hilfreich sein, weil ich "in dieser Ecke" aufgrund der Lokalität nicht wühlen muss.
Warum dann nicht gleich ganz auf Array.forEach() und solche Sachen setzen? Dann kapselst Du Variablen und kannst in Deinem Editor schön zusammenfalten! Klappt bei Objekten sehr schön:
const o = { a: 1, b: 2, c: 3};
Object.keys(o).forEach(property => {
console.log("Eigenschaft", property);
console.log("Wert", o[property]);
});
Liebe Grüße
Felix Riesterer
Hallo Felix,
in Objekten hat man automagisch auch seinen eigenen Namespace... cool, gell?
Da könnte ich ja genauso schreiben: "In Inline-Funktionen hat man automagisch auch seinen eigenen Namespace... cool, gell?"...
Du bringst ein klassisches OOP‑Argument: "Wenn du alles in Objekte packst, hast du automatisch Namespaces, also ist globaler Namespace kein Problem."
Das ist die typische Denkrichtung, wenn jemand sehr objektorientiert sozialisiert ist:
Was Du offensichtlich nicht sehen willst: Objekte lösen das eigentliche Problem nicht!
Objekte verhindern globale Namenskollisionen, aber sie lösen nicht:
schlechte Struktur
weite Sprünge im Code
fehlende Nähe zwischen Logik und Verwendung
mentale Last durch verteilte Definitionen
Overhead durch künstliche Objekt‑Architektur
das Problem, dass man für jede Kleinigkeit ein Objekt erfinden muss
Mit anderen Worten: Objekte lösen das Problem des globalen Namespaces, aber nicht das Problem der schlechten Lesbarkeit.
Und mein Punkt ist ja genau: Struktur, Nähe, Folding, lokale Kapselung.
Du versuchst, die allgemeine Kritik am globalen Namespace mit einem OOP‑Argument zu neutralisieren: "Wenn du OOP machst, hast du das Problem nicht." Das ordne ich als ein Paradigmen‑Reflex ein: Du denkst in Klassen, Instanzen, Methoden, Modulen. Ich denke in lokaler Kapselung, Folding, Nähe, mentaler Ergonomie.
Wir reden über zwei verschiedene Ebenen: Du: Paradigma. Ich: Ergonomie und Struktur im Editor.
Sorry, aber Deine Aussage geht am Thema vorbei. Ich habe über lokale Kapselung vs. globaler Namespace gesprochen. Du antwortest mit Objekt‑Namespaces. Das ist, als würde ich sagen:
"Ich mag kleine Werkzeuge, die ich direkt am Arbeitsplatz habe."
Und Du erwiderst:
"Du kannst auch einen Werkzeugwagen im Nebenraum haben."
Beides stimmt – aber es beantwortet nicht mein Argument.
Ich vertrete den Standpunkt, dass jeder Mensch das Recht hat, sich selbst komplett zum Affen zu machen.
Ja, so läuft es oft: Wenn die Argumente fehlen, dann kommen die persönlichen Angriffe...
Warum dann nicht gleich ganz auf Array.forEach() und solche Sachen setzen? Dann kapselst Du Variablen und kannst in Deinem Editor schön zusammenfalten! Klappt bei Objekten sehr schön:
Jetzt wechselst Du das Thema (ohne dass es Dir bewusst ist?). Du antwortest nicht auf mein Argument – Du zeigst mir nur ein Beispiel, das Deinen Stil bestätigt.
Dein Beispiel zeigt einfach Iteration:
Object.keys(o).forEach(property => {
console.log("Eigenschaft", property);
console.log("Wert", o[property]);
});
Das ist ein Beispiel für:
Iteration
Nutzung von forEach
Zugriff auf Objekt‑Properties
Aber es zeigt keinen Ersatz für lokale Inline‑Funktionen, keine lokale Kapselung, keine Nähe von Logik und Verwendung. Es ist einfach nur ein Loop.
Dein Beispiel löst das besprochene Problem nicht. Wenn ich sage:
"Ich will lokale Inline‑Funktionen, weil ich nicht im Code wühlen will."
Und Du sagst:
"Nimm doch Objekte."
Das ist, als würde ich sagen: "Ich mag Schubladen direkt am Schreibtisch."
Und Du sagst: "Dann geh doch zum Werkzeugschrank.“
Beides sind Ordnungssysteme – aber sie lösen verschiedene Probleme.
Ja, Objekte sind super, wenn man Königreiche bauen will! Aber ich brauche manchmal nur einen kleinen Gartenzaun... :-)
Gruß, fischlak
PS: Jetzt hast Du mich tatsächlich noch davon abgebracht, endlich die neue LTS zu installieren :-)
Hallo Felix,
mal ein Gedanke zum "VisualStudio Code", weil Du in einem Posting VisualStudio erwähntest, deshalb möchte ich mal was dazu sagen.
Dieser Editor ist ja in VisualStudio integriert. Ich selbst hab die OpenCource-Version VSCodium installiert. VisualStudio wird wohl (ich weiß es nicht, aber ich gehe jetzt davon aus) genau diesen Editor integriert haben.
Nun zum Punkt:
VSCodium hat eine Funktionalität "Peek". Also z.B. rechte Maustaste -> Peek -> Peek Definition. Dann klappt an Ort und Stelle, also ohne dass VSCodium die Scrollpos verändert, die Funktions-Definition in einem Inline-Frame auf. Die Definition kann man dann aber nicht nur sichten, sondern auch bearbeiten. Und: Man kann den Frame sogar größer/kleiner ziehen, also breiter/enger und höher/tiefer. Das ist schon perfekt!
Frage: Relativiert sich denn jetzt nicht meine Taktik des "Folding + Lokalität"? Nein, meine Taktik relativiert sich nicht – sie wird sogar bestätigt! Eben durch die Existenz dieser Funktionalität Peek.
Peek ist ein Navigationswerkzeug. "Folding + Lokalität" ist eine Strukturierungs-Strategie.
Peek löst ein anderes Problem:
Peek zeig mir schnell, was da steht, ohne dass ich wegscrollen muss.
"Folding + Lokalität" strukturiert den Code so, dass ich gar nicht erst suchen muss.
Peek ist wie eine Taschenlampe. "Folding + Lokalität" ist wie ein gut sortierter Werkzeugkasten. Beides ergänzt sich, aber nur eines davon ist ein echtes Strukturierungs-Konzept.
Peek zeigt die Definition – aber sie bleibt räumlich woanders.
Peek ist super, aber:
Die Funktion liegt trotzdem in einer anderen Datei
oder weiter oben im Code
oder weit weg vom Kontext, in dem ich sie brauche
Peek überbrückt Distanz, aber es beseitigt sie nicht.
Eine lokale Inline‑Funktion dagegen:
ist direkt im Kontext
ist foldbar
ist sichtbar, wenn ich sie brauche
ist unsichtbar, wenn ich sie nicht brauche
Peek ist ein Krückstock (im positiven Sinne...). Lokalität ist ein gutes Skelett.
Peek ist reaktiv – Lokalität ist proaktiv.
Peek hilft sehr, wenn ich suchen muss. Lokalität sorgt dafür, dass ich gar nicht erst suchen muss. Und das ist ein fundamentaler Unterschied:
Peek = "Ich muss nachschauen."
Lokalität = "Ich weiß es schon, weil es direkt hier ist."
Peek ist ein Editor‑Feature – Lokalität ist ein Architekturkonzept, das durch Folding-Stil noch doppelt sinnvoll wird.
Peek löst nicht das Problem der mentalen Nähe. Wenn ich im Folding-Stil arbeite, dann bin ich darauf trainiert:
Alles, was zusammengehört, ist zusammen
Ich sehe die Struktur auf einen Blick
Ich muss nicht springen und nicht peeken
Peek zeigt mir zwar die Definition, aber:
Ich sehe nicht die gesamte Struktur
Ich überblicke nicht die anderen lokalen Hilfsfunktionen
Ich sehe nicht die semantische Nähe
Peek ist ein Fenster. Lokalität ist ein Raum.
Fazit:
Peek ist ein Komfort‑Feature. Lokalität in Kombination mit Folding ist ein brauchbares Architektur‑Konzept, das auszuprobieren sich lohnen könnte.
Peek hilft mir, wenn ich nicht lokal arbeiten kann. Lokalität sorgt dafür, dass ich Peek seltener brauche.
Die Tatsache der Existenz und der Implementation der Funktionaltät "Peek" innerhalb des Editors entlarvt (als "Heilmittel") das Problem als solches. Ein Problem, das meine angesprochene Taktik "Lokalität + Folding" gar nicht erst in solchem Umfang entstehen lässt.
Gruß, fischlak
Hallo fischlak,
mal ein Gedanke zum "VisualStudio Code", weil Du in einem Posting VisualStudio erwähntest, deshalb möchte ich mal was dazu sagen.
Dieser Editor ist ja in VisualStudio integriert. Ich selbst hab die OpenCource-Version VSCodium installiert. VisualStudio wird wohl (ich weiß es nicht, aber ich gehe jetzt davon aus) genau diesen Editor integriert haben.
Vorsicht: Mit Visual Studio und Visual Studio Code verhält es sich wie mit Java und JavaScript.
Viele Grüße
Julius
Hallo Julius,
erstmal Danke für Deinen Hinweis :-)
Zu Visual Studio konnte ich nichts sagen, weil ich das Teil nicht kenne. Deshalb hatte ich spekuliert, dass Visual Studio genau diesen Editor integriert haben sollte.
Jetzt nach Deinem Hinweis hab ich mal recherchiert. Auch wenn die Namen fast identisch sind (von den Namen hab ich mich ja verführen lassen...), gibt es keine direkte Integration im Sinne von „VS Code läuft innerhalb von Visual Studio“.
Visual Studio hat also einen nativen Editor, dessen Unterbau komplett anders ist als der von VS Code. Hab ich nicht gewusst, jetzt weiß ich es.
Laut meinen Recherchen hat der native Editor dieser IDE ebenfalls das Peek-Feature. Und darauf kam es mir ja an; wegen dieses Features hab ich Visual Studio ja erwähnt. Ändert also nichts.
Aber Danke für den Hinweis, ich kenne mich nicht so aus mit Microsoft-Produkten; komme aus der Linux-Ecke und bin gerade damit beschäftigt, das neue Kubuntu-LTS einzurichten :-)
Gruß, fischlak
Vorweg, ich möchte dir den Spaß am Folding nicht ausreden. Selbst wenn ich wollte, könnte ich es bei deiner Begeisterung vermutlich sowieso nicht.
Was du zum Folding erklärst ist nicht falsch. Ich frage mich nur warum du das so brauchst. Eine gescheit benannte Funktion sagt dir was sie tut. Mit einem kurzen Kommentar drüber (nicht Wiederholung des Funktionsnamens) erst recht.
Wie brauchst du semantische Nähe und Lokalität? (außer um Folding zu rechtfertigen 😉 ) Zusammengehörendes packe ich in eine passende Struktur von Dateien. Vieles, gerade wie die erwähnten encode oder decode Funktionen haben keine semantische Nähe zu genau einem Codeteil, sondern sind allgemein gültig und an mehreren Stellen nützlich. Willst du sowas wirklich so oft an Ort und Stelle sehen?
Findest du das Geschachtel von Funktionen tatsächlich übersichtlich? Für mich ist das eher gedankliche Bremse statt Beschleunigung.
Vieles überall wo nötig zu wiederholen ist für dich Struktur?
Was machst du wenn du eine Funktionalität brauchst die schon woanders ist, findest du die dann um sie zu kopieren? Wenn du was korrigieren oder erweitern musst, weißt du dann wo überall das sonst noch anzupassen ist?
Mit all diesen Fragen die ich mir stelle, möchte ich den ganzen Thread über schon immer wieder anmerken, falls du mal was wirklich größeres machst und daran verzweifelst dass du dich nicht mehr auskennst was wie wo…, dass bei Erweiterungen oder Korrekturen nicht nur eine sondern viele Codestellen finden musst und ähnliches, traue dich umzudenken.
Hallo encoder,
die Fragen, die Du stellst ("Was machst du, wenn du...?"), sind aus Deinem Paradigma formuliert. In meinem Paradigma sind sie teilweise schon beantwortet.
"Wiederholung überall?": Ich wiederhole nicht blind, ich kapsele lokal, wo Wiederverwendung (oder potenzielle künftige Wiederverwendbarkeit) keinen Mehrwert bringt.
"Was, wenn du was korrigieren musst?": Ich bin nicht gegen Wiederverwendung – wie sollte das denn funktionieren? Ich bin aber gegen dogmatische Zentralisierung.
"Geschachtelte Funktionen als Bremse?": Für Dich: ja, weil Du nicht so arbeitest wie ich. Für mich: nein, weil ich in Chunks und Folding-Einheiten denke.
Findest du das Geschachtel von Funktionen tatsächlich übersichtlich?
Ich kann Dich gut verstehen. Denn wenn ich mein gefoldetes Skript mal mit einem anderen Editor öffne, also einem Editor, der mir die Folding-Struktur nicht anzeigt, dann sehe ich ein riesengroßes Chaos voller verschachtelter Unübersichtlichkeiten. Unmöglich, da noch klarzukommen. Und genau DAS hast Du in Deinem gedanklichen Visier! Du berücksichtigst nicht, dass bei einer Sichtung mit persistentem Folding sich eine ganz andere visuelle Struktur ergibt, weil Du es noch nie gesehen hast und nicht gewöhnt bist.
Du siehst Chaos, weil Du die Folding-Struktur nicht berücksichtigst.
Ungefaltet sieht mein Code so aus:
verschachtelte Funktionen
viele IIFEs
lokale Blöcke
Inline‑Hilfsfunktionen "mitten drin""
viele Ebenen
scheinbares Durcheinander
Gefaltet:
klare Chunks
sprechende Blocknamen
kompakte Übersicht
semantische Nähe
visuelle Ruhe
viel weniger Scrollen
bessere Orientierung
Du siehst nur die erste Version, also "ungefoldet", weil Du aus der Perspektive Deines Paradigmas betrachtest. Deshalb wirkt mein Stil auf Dich chaotisch.
Natürlich kann ich bei wiederverwertbarem Code keine Lokalität herstellen.
In meinem aktuellen Projekt schätze ich den Anteil wiederverwertbaren Codes auf um die 60% bis 70%. Einen Teil dieser wiederverwertbaren Funktionen kann ich zwar "in der Nähe" halten, aber sie sind nicht mehr "visuell lokal".
D.h. bei etwa 50 % allen Codes kann ich keine lokale Nähe herstellen. Btw: Genau in solchen Fällen kann das Peek-Feature (VSCodium u.a.) die visuelle Distanz zumindest einigermaßen entschärfen.
Aber die anderen 50% erhöhen durch ihre lokale Nähe die Lesbarkeit. Und 30% bis 40 % sind tatsächlich visuell lokal, sodass sich beim Sichten der Zusammenhänge innerhalb dieser lokalen Funktionen weniger mentale Last ergibt.
An vielen Stellen habe ich Codezeilen, die hintereinanderweg geschrieben sind und im Zusammenhang einmalig sind. Es ist ja nicht so, dass ein komplettes Skript ausschließlich aus wiederverwertbarem Code besteht, wo ich die extern gehaltenen Bausteine nun wiederverwende. Es bleiben genügend Abschnitte übrig mit individuell an das aktuelle Projekt zugeschnittenen Codezeilen.
Ein Beispiel: Wenn ich während des Codens einen semantisch zusammenhängenden Block erkenne, also einen Code-Abschnitt voller hinereinanderweg geschriebener einmalig verwendeter Code-Zeilen, die aber einen semantischen Zusammenhang bilden, dann mach ich eine IIFE daraus, sodass der Block zu einer Funktion wird, dann also ohne eine explizite Referenz ausgeführt wird, gebe dieser IIFE einen sprechenden Namen und klappe sie dann ein.
Auf diese Weise kann ich meinen Code visuell verkleinern, ohne jedoch die Übersicht zu verlieren, sondern im Gegenteil: Ich reduziere Chunks, scrolle weniger, weiß aber trotzdem, was im Code passiert. Das mach ich sogar inline in Schleifen. Und nur aus einem einzigen Grund: Um bessere Übersicht zu bekommen.
Sowas geht nicht immer – aber es geht oft.
Die meisten Entwickler strukturieren Code nach Paradigmen:
OOP -> Methoden oben
FP -> pure functions oben
"Best Practices" -> alles schön sortiert in Module
Ich versuche, Code nach mentaler Ergonomie zu strukturieren:
Nähe
Chunk‑Größe
visuelle Ruhe
lokale Semantik
Das ist ein anderes Optimierungsziel. Ich optimiere nicht für Paradigmen. Ich versuche, für kognitive Effizienz zu optimieren.
Mein Stil ist so ungewöhnlich, weil fast niemand so bewusst über "visuelle Strukturierung" nachdenkt. Ich versuche, visuelle Komplexität und Kontextwechsel zu reduzieren, indem ich semantische Nähe erhöhe. Also eine Art "UX‑Design für Code".
Mein Stil ist nicht Mainstream – aber er funktioniert. Und das ist der entscheidende Punkt. Wenn ein Stil konsistent ist, Fehler vermeidet, Übersicht schafft, mentale Last reduziert, produktiv macht, – dann ist es doch OK. Egal, ob er "üblich" ist oder nicht.
Ja, mein Ansatz, Code als "mentales UX-Design" zu betrachten, ist ungewöhnlich. Ich versuche im Grunde "Spatial Locality" für die menschliche Aufmerksamkeit. Dass ich Inline-Funktionen, IIFEs und Folding als Werkzeuge nutze, um die "Sichtweite" künstlich zu begrenzen (und damit die mentale Last zu senken), ist natürlich ein Argument gegen das Dogma der absoluten Zentralisierung.
Und dass mein Konzept "UX-Design für Code", innerhalb einer Entwickler-Community formuliert, eine Debatte auslösen würde, wundert mich nicht. Während klassisches Software-Design meistens technische Metriken optimiert (Wiederverwendbarkeit, Entkoppelung, Testbarkeit), versuche ich, die Schnittstelle zwischen Code und Bewusstsein zu optimieren.
Gruß, fischlak
Lieber fischlak,
Während klassisches Software-Design meistens technische Metriken optimiert (Wiederverwendbarkeit, Entkoppelung, Testbarkeit), versuche ich, die Schnittstelle zwischen Code und Bewusstsein zu optimieren.
zeig doch mal ein „fertiges“ Projekt, bei dem man sich das in allem Glanz anschauen kann! Bisher hast Du nur Ausschnitte aus einem aktuellen Projekt gezeigt, der noch nicht einmal selbst fertig war.
Liebe Grüße
Felix Riesterer
Hallo Felix,
in meinem aktuellen Projekt habe ich gerade mal etwa 1/3 der Strecke zurückgelegt. Das taugt nicht für eine Demo.
Eigentlich ist die Nummer mit Folding, Peek und übermäßiger Inline-Lokalisierung nur ein Versuch, die Unzulänglichkeit moderner Code-Editoren zu kompensieren.
Viel besser wäre eine geeignete Projektdatei. Weil wir hier in der Ecke Javascript sind, möchte ich mal als Beispiel einen groben Umriss für solch eine JS-Projektdatei geben.
Ich bin Deinem Wunsch entsprochen und hab mir mal die Mühe gemacht und ein Beispiel erstellt. Die Projektdatei könnte wie Hypertext strukturiert sein. Das Beispiel zeigt einen funktionierenden Prototypen einer eigenen Meta‑Sprache, die den Zweck haben soll, den Bedarf nach solchen Tricks wie Folding und Peek gar nicht erst aufkommen zu lassen. Nehmen wir für unseren minimalen Prototypen folgende JS-Funktion:
function foo(x, y){
return x + y;
}
Ein Browser, mit geeignetem Parser, könnte den Quelltext als DOM anzeigen, z. B.:
<function> als collapsible Block
<params> als Liste
<compute> als Baum
<operator> als Symbol
Das wäre sogar visuell besser als jeder Editor heute.
Beispiel‑Darstellung (konzeptionell):
Function foo
├── Params
│ ├── x
│ └── y
└── Return
└── Compute
├── left: x
├── operator: +
└── right: y
Wenn Du das jetzt ausprobieren möchtest, dann lege bitte 3 Dateien an:
example.htjs
<function name="foo">
<params>
<param>x</param>
<param>y</param>
</params>
<body>
<return>
<compute>
<left>x</left>
<operator>+</operator>
<right>y</right>
</compute>
</return>
</body>
</function>
Letzteres ist natürlich kein gültiges HTML, sondern eine semantische Beschreibung einer Funktion mit XML-Bordmitteln.
die Datei einliest
die XML‑Struktur parst
daraus echten JavaScript‑Code generiert:
htjs-parser.js
export function parseHTJS(htjsString) {
const parser = new DOMParser();
const xml = parser.parseFromString(htjsString, "text/xml");
const fn = xml.querySelector("function");
const name = fn.getAttribute("name");
const params = [...fn.querySelectorAll("params > param")]
.map(p => p.textContent.trim())
.join(", ");
const compute = fn.querySelector("compute");
const left = compute.querySelector("left").textContent.trim();
const op = compute.querySelector("operator").textContent.trim();
const right = compute.querySelector("right").textContent.trim();
return `
window.foo = function ${name}(${params}) {
return ${left} ${op} ${right};
}
`.trim();
}
Letzteres ist ein echter Transpiler – nur sehr klein.
demo.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<script type="module">
import { parseHTJS } from './htjs-parser.js';
const htjs = await fetch('./example.htjs').then(r => r.text());
const jsCode = parseHTJS(htjs);
console.log("Generierter JS-Code:");
console.log(jsCode);
// Dynamisch ausführen
eval(jsCode);
console.log("foo(3, 4) =", foo(3, 4));
</script>
</body>
</html>
Wenn du die Dateien anlegst und die demo.html im Browser öffnest, passiert:
Die HTJS‑Datei wird geladen
Der Parser erzeugt echten JavaScript‑Code
Der Code wird evaluiert
Die Funktion foo existiert und funktioniert
Dann siehst Du im Bereich Entwicklertools in der Konsole das Ergebnis.
Natürlich siehst Du im Browserfenster selbst keinen Code, weil der Browser keinen Parser für die verwendeten Tags hat. Soll ja nur eine Minimal-Demo sein, die das grundsätzliche Konzept auf der Ebene eines Konzept-Prototyps veranschaulicht.
WENN Browser sowas KÖNNTEN, dann würden sie den Javascript-Code genauso anzeigen, wie es aktuelle Code-Editoren tun. Inkl. CSS für Syntax-Highlighting.
Und dann müsste es eine Browser-Funktionalität "Bearbeiten" geben und der Browser im Bearbeitungsmodus natürlich lokale Schreibrechte haben. So wird der Browser zum Editor... :-)
Und DANN könnte man natürlich Features einbauen, wie:
STRG + Klick auf eine Funktions-Referenz = Funktion samt Inhalt klappt in einem Inline-Frame zur Sichtung und Bearbeitung auf (wie Peek). Das ist exakt AST‑Navigation, semantische Referenzauflösung, Inline‑Expansion.
STRG + Klick funktioniert bei ALLEN Referenzen. Das ist sogar noch einfacher:
<call ref="foo"> -> springe zu <function name="foo">
<var ref="x"> -> springe zur Deklaration
<import ref="module"> -> öffne Modul
Das ist Hypertext, nicht "Code".
Platzierung der Funktions-Definition ist egal – ob am Anfang oder am Ende... Platzierung der Definition egal, denn: Hypertext ist nicht linear! Nur Textdateien sind linear. Mit Hypertext ist man bereits jenseits von Textdateien.
STRG + Klick auch Datei-übergreifend wirksam. Das ist "Cross‑File AST" und "Cross‑Module Hyperlinks", also semantische Navigation.
Das wäre eine neue Art, Code zu repräsentieren. Browser könnten das sofort, wenn sie HTJS verstünden. Diese Idee ist eigentlich ziemlich mächtig, weil sie das Grundproblem löst, das ich seit Postings beschreibe: Textdateien sind ein schlechtes Format für Code.
Vielleicht verstehst Du jetzt, was ich meine...
Jetzt mach ich mich aber wieder an die Konfiguration meines neuen LTS ran, sonst wird das nie fertig.
Gruß, fischlak
Hallo Felix!
PS: Mit "window.foo = function" hab ich die Funktion explizit global gemacht. Nur ne kleine getrickste Abkürzung – reicht ja für die Demo.
Ich hätte auch anders tricksen können mit (0, eval)(jsCode)
Oder eine saubere Variante:
const script = document.createElement("script");
script.textContent = jsCode;
document.body.appendChild(script);
Damit sollte der generierte Code wie ein echtes JS‑Script ausgeführt werden.
Aber wie gesagt – soll ja nur eine konzeptionelle Darstellung sein, kein fertiges Ding.
Gruß, fischlak
Hallo Felix,
der logische nächste Schritt wäre:
eine vollständige HTJS‑Grammatik entwerfen
einen richtigen AST‑Compiler bauen
ein Browser‑UI‑Konzept für HTJS entwickeln
oder sogar ein Proof‑of‑Concept‑Projekt starten
Habt ihr für sowas die Zeit und die Ressourcen? Alleine lässt sich sowas kaum realisieren. Aber als Team sehr wohl...
Und niemald ist Project Manager, sondern alle zusammen... :-) Wir sind ja nicht blöd...
Gruß, fischlak
Mit OOP hab ich nicht die besten Erfahrungen gemacht, denn ich arbeite alleine.
Ich hab gute Erfahrungen gemacht und meine Hausnummer ist größer als 7 - der Zusammenhang ist ähnlich 😁 Soll heißen OOP hat nichts mit der Anzahl Personen zu tun.
OOP kann sehr bei der Strukturierung von Code helfen. Man sieht direkt wo eine Funktion oder Methode zu finden ist, nämlich in der Klasse mit der sie aufgerufen wird.
Folding hat Fans und Gegner. Ich persönlich nutze es nicht.
Entweder Code ist da, dann will ich ihn auch sehen. Wenn er nicht sichtbar sein muss weil man ihn durch einen sprechenden Funktionsnamen ersetzen kann, kommt der Inhalt woanders hin.
Statt in einer einzigen Datei hin und her zu springen, springe ich lieber durch verschiedene Tabs. Da bleibt der Cursor jeweils da stehen wo ich ihn haben will. Aber das sind sehr persönliche Vorlieben, jeder wie er mag.
Codezeilen zählen tu ich nicht. Gesplittet wird dann wenn es nötig ist und das lässt sich absolut nicht an eine Zahl binden.
Es gibt Funktionen die mit 200 Zeilen noch perfekt sind, weil alles darin zusammengehört und man der Reihe nach sieht was passiert. Im Linux-Code gibt es welche mit noch viel mehr Zeilen, switch mit vielen case oder was auch immer. Warum sollte man das auseinander reißen? Andrerseits lagere ich selbst nur 4 Zeilen dann aus, wenn sich dadurch ein sprechender Aufruf ergibt, der mir an dieser Stelle lieber ist als der tatsächliche Code.
Bzgl. Konventionen denke ich, am besten hält man sich an etwas offizielles.
Ich habe kein Problem damit, gegen die Konventionen zu verstoßen wenn es der Übersichtlichkeit dient. Das Argument "wir sollten das nicht [so] sondern [in diesem speziellen Fall unübersichtlicher] schreiben weil es in der Konvention steht" halte ich für ungenügend.
Hallo encoder,
genau das meinte ich eigentlich: es geht sehr um persönliche Arbeitsweisen. Bei mir ist es so, dass Folding nicht nur "ausblenden" bedeutet, sondern dass sich dadurch ein anderer Arbeitsfluss ergeben hat. Ich nutze Funktionen lokal, klappe sie ein und habe dadurch eine visuelle Struktur, die für mich sehr übersichtlich ist. Ohne Folding würde ich so nie schreiben, aber mit Folding entsteht ein konsistenter Stil, der für mich gut funktioniert.
Tabs und Dateisplitting nutze ich ebenfalls, weil ja nicht jede Funktionalität in lokaler Nähe gehalten werden kann. Ohne Tabs und Dateisplitting würde ich vorne und hinten nicht klarkommen. Am Ende geht's ja darum, dass man beim Arbeiten gut klarkommt.
Gruß, fischlak
Lieber fischlak,
aber mit Folding entsteht ein konsistenter Stil, der für mich gut funktioniert.
Stil ist etwas völlig anderes als Struktur!
Stil hat z.B. mit der Anzahl Leerzeichen bei Einrückungen zu tun, oder ob man vor einer mehrzeiligen Anweisung eine Leerzeile notiert. Ob man die geschweiften Klammern grundsätzlich in eigenen Zeilen schreibt, oder nicht:
function foo ()
{
// Code
}
function bar () {
// code
}
Ob man Code in eine Funktion packt, oder nicht, hat mit Struktur zu tun. Diese Struktur ist für die Funktionsweise des Algorithmus von wesentlicher Bedeutung! Das hat nichts mit Stil oder Ästhetik zu tun. Und beim Programmieren möchte man seinen Code so strukturieren, dass seine Funktionalität beweisbar ist. Im Gegensatz zu KI-Assistenten möchtest Du ja Deinen Code debuggen können, wenn er nicht exakt das tut, was Du eigentlich haben möchtest. Und da kommt es sehr darauf an, ob Du die Struktur des Codes nachvollziehen kannst, oder nicht. Und das ist völlig unabhängig davon, wer nach welchen Stilvorlieben diesen Code geschrieben hat!
Liebe Grüße
Felix Riesterer
Hallo Felix,
Und beim Programmieren möchte man seinen Code so strukturieren, dass seine Funktionalität beweisbar ist.
Viel Glück dabei. In den 4 Semestern, die ich mir damals Informatik angetan habe, kam auch "Theoretische Informatik" vor, inclusive Algorithmusbeweisen. Das geht für sehr kleine Module und bedeutet für jede Schleife eine vollständige Induktion. Juhuuu!
Du möchtest, dass die Funktionalität testbar ist. Vermutlich hast Du das gemeint, aber ein Unit-Test ist kein Programmbeweis.
Für Unittests brauchst du richtigerweise die Möglichkeit, den Code in unabhängige Einheiten aufzuteilen, deren Funktionsweise Du sauber spezifizieren kannst und deren Spezifikation Du mit Unit-Tests nachweisen kannst. OOP und Dependency Injection helfen hierbei massiv. Ob fischlak das mit seiner Technik hinbekommt, wäre erstmal nachzuweisen.
Unittest-fähigkeit bedeutet auch, dass für die Softwareschichten, die nicht im Bodensatz der Logikstruktur herumkriechen, die von ihnen genutzten tieferen Schichten simuliert werden können. Das kann man Mock, Stub, Fake, Test-Double, Spy oder sonstwie nennen, Hauptsache ist, dass der Ersatz die für den Unittest nötigen Verhaltensweisen zeigt. Oder wie es bei NSubstitute (eine .net Library) so schön heißt:
Mock, stub, fake, spy, test double? Strict or loose? Nah, just substitute for the type you need!
Das Substituieren des DOM ist dabei eine besondere Herausforderung. Bisher habe ich es vermieden, Unittests für UI-nahen Code zu schreiben…
Rolf
@@Rolf B
Das Substituieren des DOM ist dabei eine besondere Herausforderung. Bisher habe ich es vermieden, Unittests für UI-nahen Code zu schreiben…
Da kann man eine ganz andere Art von Tests schreiben.
Das will ich mal wieder rauskramen für einen Techtalk. Wäre auch was für die Unconference gewesen, aber bis Sonnabend wird das wohl nichts mehr. Außerdem hab ich ja schon was anderes.
🖖 Live long and prosper
PS: Hurra, ich muss kein Zeichen mehr escapen! 😉
Hallo Gunnar,
Da kann man eine ganz andere Art von Tests schreiben.
Was Du da zeigst, ist nicht TDD, sondern Validierung.
Nicht, dass das überflüssig wäre. Aber TDD bezieht sich auf den fachlichen Inhalt.
Rolf
@@Rolf B
Was Du da zeigst, ist nicht TDD, sondern Validierung.
Hm, ja. Ich hab da nicht alles gezeigt.
Bei einem Projekt hatte ich das Framework aber tatsächlich als TDD eingesetzt und mir einige Tests und andere Tests geschrieben um sicherzustellen, dass das DOM genauso ist, wie es die Applikation erwartet. Hatte für mich gut funktioniert. Ein roter Rahmen irgendwo (tauchte während der Entwicklung öfter auf) und ich wusste, dass das nicht funktionieren kann und dass der Fehler nicht in der Scriptlogik, sondern in der DOM-Struktur zu finden ist.
🖖 Live long and prosper
Hallo Felix,
so so, Du kennst das Wort "Stil" also ausschließlich in der Bedeutung von:
Einrückungen
Klammern
Leerzeichen
Formatierung
Aber Du kennst wohl nicht:
visuellen Stil
ergonomischen Stil
strukturellen Stil
strukturierenden Stil
Arbeitsstil
Navigationsstil
Mit scheint, Du meinst mit Stil nur Syntax‑Kosmetik!?
Du ziehst mich auf die Erste-Klasse-Grundschule-Ebene von Klammern und Leerzeichen, weil Du nicht siehst, dass ich über visuelle Strukturierung rede.
Das ist sicherlich kein böser Wille, für mich ist das, mit Verlaub, Begriffsblindheit.
Mit "Stil" meine ich hier nicht Formatierung oder Einrückungen, sondern die Art, wie ich den Code beim Arbeiten visuell strukturiere.
Folding ist für mich kein kosmetisches Feature, sondern ein Werkzeug, um Funktionen (oder semantisch zusammenhängende Blöcke) lokal zu halten, sie einklappbar zu machen und den Arbeitsfluss zu verbessern. Dadurch entsteht beim Arbeiten tatsächlich ein anderer Organisationsstil – nicht im Sinne von Syntax, sondern im Sinne von Navigation und visueller Struktur.
Das ist also eine andere Bedeutung von "Stil" als die, die du meinst.
Gruß, fischlak
Hallo fischlak und Felix,
ich bitte, das Thema ruhen zu lassen. Es beginnt soeben zu eskalieren und das ist die Sache nicht wert.
Rolf
Hallo encoder,
Ich hab gute Erfahrungen gemacht und meine Hausnummer ist größer als 7 - der Zusammenhang ist ähnlich 😁 Soll heißen OOP hat nichts mit der Anzahl Personen zu tun.
OOP kann sehr bei der Strukturierung von Code helfen. Man sieht direkt wo eine Funktion oder Methode zu finden ist, nämlich in der Klasse mit der sie aufgerufen wird.
Ich hab ganz andere Erfahrungen gemacht. Wenn ich alleine arbeite, erreiche ich mit OOP nur noch mehr Fragmentierung. Für Solo-Entwickler (gerade auch in JavaScript-Projekten) kann ein prozeduraler/funktionaler/modularer Ansatz deutlich effizienter sein. OOP entfaltet seine Stärken erst, wenn Teams an komplexen Systemen arbeiten, bei denen Kapselung wichtiger ist als Code-Schlankheit.
Die Tatsache, dass OOP den Code unnötig aufbläht, ist in der Softwareentwicklung doch gut dokumentiert! Studien und Expertenanalysen deuten darauf hin, dass OOP-Code im Vergleich zu rein prozeduralen Ansätzen etwa 17 % bis 38 % umfangreicher ist:
0–20 % mehr Code bei pragmatischer, einfacher OOP und 20–80 % mehr Code bei klassischer stark abstrahierter OOP.
Dieser "Aufbläheffekt" entsteht vor allem durch strukturellen Overhead und die Art der Abstraktion. OOP erfordert zusätzliche Definitionen für Klassen, Interfaces, Konstruktoren und Zugriffsmethoden. Allein die Definition von Klassen fügt oft eine zusätzliche "Einrückungsebene" hinzu, was die Lesbarkeit bei kleineren Skripten erschweren kann.
Anstatt Daten direkt zu verarbeiten, werden sie in Objekten gekapselt. Dies führt zu mehr Funktionsaufrufen (oder von mir aus Methodenaufrufen – 2 Namen für de facto den gleichen Effekt) und so gut wie immer zu einer fragmentierteren Struktur, was neben der größeren Unübersichtlichkeit des Codes bei leistungskritischen Anwendungen durchus spürbar sein kann. Aber zu der stärkeren Fragmentierung hab ich ja nun genug geschieben.
Man sagt auch "Bananen-Gorilla-Dschungel"-Problem dazu: Wie Joe Armstrong (Erfinder von Erlang) treffend formulierte: "Du wolltest eine Banane, aber was du bekamst, war ein Gorilla, der die Banane hält, und den gesamten Dschungel dazu".
Die aktuelle Forschung, hier mal ein Beispiel:
legt nahe, dass es kein "besseres" Paradigma gibt, sondern die Wahl von der Projektgröße abhängt. Bei kleinen/mittleren Projekten ist prozedural oft effizienter, schneller zu schreiben und leichter zu überblicken. Bei großen/komplexen Systemen überwiegen die Vorteile der Kapselung und Wiederverwendbarkeit von OOP.
Welcher Programmierer verbraucht nicht deutlich mehr als die Hälfte seiner Zeit an Fehlersuche und Debugging? Und ich rede hier nicht von Anfängern, sondern duraus von Fortgeschrittenen. Aus dieser Nummer wird Dich keine OOP dieser Welt herausziehen!
Aber so weit wollte ich gar nicht gehen. Ich wollte mich eigentlich über Erfahrungen bezüglich der Folding-Implementation heutiger Editoren austauschen und keine Grundsatzdiskussion Prozedual vs. OOP anreißen.
Gruß, fischlak
Lieber fischlak,
Die aktuelle Forschung, hier mal ein Beispiel:
das Beispiel hat ganz speziell Microservices als Vorgabe und vergleicht auf dieser Basis. Da ich von Microservices zu wenig verstehe, und auch nicht sehe, was dieser Diskussionszweig mit Deinem ursprünglichen Ansatz mit Folding passenden Code zu schreiben zu tun hat, kann ich mit dieser Studie leider nichts anfangen.
Ist es von Bedeutung, dass die Autoren der Studie allesamt von einem Institut für Business-Management kommen? Würde mich mal interessieren, inwiefern die praktische Coder sind und nicht nur vergleichen, was andere so darüber geschrieben haben.
Liebe Grüße
Felix Riesterer
Hallo Felix,
und auch nicht sehe
darf ich Dich mal daran erinnern, was Du geschrieben hast:
Dass Du es aber Kapseln möchtest, würde für mich ein Auslagern in eine eigene Klasse erzwingen.
Eine einmalig verwendete Hilfsfunktion (ich hatte sie als solche benannt und als Code-Beispiel gepostet) zwingend in eine eigene Klasse stecken...?
Für meine Programmierpraxis ist es ein Unding, wenn mir ein Funktionsaufruf mehrere Rückgabewerte liefert.
Also JavaScript unterstützt Rückgabe von Objekten, von Arrays, Destructuring, Named returns. Gerade bei "Breite/Höhe, x/y, min/max" ist es völlig normal, zwei Werte zurückzugeben. Denn in der Praxis ist das Standard. Und um jetzt auf mein konkretes Beispiel einzugehen, formal technisch: Nein, das sind nicht zwei getrennte Rückgabewerte! Es ist EIN Rückgabewert, nämlich ein Objekt mit zwei Properties:
{ renderWidth, renderHeight }
Das ist ein einziges Objekt. Formal wirkt es , wegen Destructuring, wie zwei Rückgabewerte. Technisch präziser formuliert, gibt die Funktion ein Objekt mit zwei Werten zurück, obwohl man im Alltag wohl "die Funktion gibt zwei Werte zurück" zu sagen zu pflegen scheint. Zwei echte getrennte Rückgabewerte gibt es nicht, auch wenn in der Praxis von "mehreren Rückgabewerten" gesprochen werden kann, ist und bleibt es 1 Objekt.
dann weiß man ja in aller Regel die wichtigen Eigenschaften und Methoden, sodass man eben nicht springen muss.
Jeder, der Codet, springt ständig, sucht ständig, verliert ständig Kontext, muss ständig nachsehen. Genau aus diesen Gründen existieren ja LSP, IntelliSense, Go‑to‑Definition, Peek Definition, Folding, Breadcrumbs, Minimap, Outline View. Wenn "man ja alles weiß", dann bräuchte es das alles nicht. Und dann würde auch nicht deutlich über 50% der Entwicklungszeit auf Debugging und Fehlersuche fallen.
Wenn also Dein fitIntoBox nur ein einziges Mal im Code aufgerufen wird, dann wäre das für mich ein Grund, dass es regulär als eine Folge von nicht-gekapselten Anweisungen im Code steht.
Das bedeutet ja im Umkehrschluss: Alle Codezeilen, weil sie ja jeweils nur ein einziges mal im Code vorkommen, stehen dann hintereinander weg meterlang in Reih und Glied…
Lieber Felix, Deine Antworten sprechen für sich...
Gruß, fischlak
Hallo fischlak,
Aber so weit wollte ich gar nicht gehen. Ich wollte mich eigentlich über Erfahrungen bezüglich der Folding-Implementation heutiger Editoren austauschen und keine Grundsatzdiskussion Prozedual vs. OOP anreißen.
Das hast Du aber getan. Weil Du deine Methode damit verteidigst, dass OOP nichts taugt. Okay - genauer gesagt: für Dich nichts taugt. Aber hier bringst Du einen OO-Hammer nach dem anderen.
Für Solo-Entwickler (...) kann ein prozeduraler/funktionaler/modularer Ansatz deutlich effizienter sein (als OOP).
OOP-Code (ist) im Vergleich zu rein prozeduralen Ansätzen etwa 17 % bis 38 % umfangreicher
Ja. Beides ist richtig. Und zumeist ist die OO-Variante auch etwas langsamer.
Hingegen ist
Allein die Definition von Klassen fügt oft eine zusätzliche "Einrückungsebene" hinzu, was die Lesbarkeit bei kleineren Skripten erschweren kann.
ein schwaches Argument. Programmierst Du auf dem Smartphone oder rückst Du mit achtstelligen Tabs ein, dass Dich ein bis zwei Einrückungsstufen stören? Im übrigen bescheren Dir deine Folding-Funktionen ebenfalls weitere Einrückung.
Anstatt Daten direkt zu verarbeiten, werden sie in Objekten gekapselt.
Was definitiv ein Vorteil ist. Zusammengehörige Daten liegen beisammen, und der Code, der für sie zuständig ist, auch. Ohne diese Kapselung musst Du den Code, der eine bestimmte Variable ändert, im ganzen Programm suchen. Darüber hinaus haben Setter den Vorteil, dass Du darin einen Breakpoint setzen oder Log-Aufrufe einbauen und damit den Ablauf beim Debuggen gut tracen kannst. JA, das erscheint langsamer. Ich hatte in den 90er Jahren, als man unsere Abteilung mit SmallTalk beglückt hat, dazu heiße Diskussionen, weil ich es damals auch nicht einsehen wollte. Mittlerweile bin ich kuriert (von Smalltalk und von der Abneigung gegen Getter und Setter).
"Du wolltest eine Banane, aber was du bekamst, war ein Gorilla, der die Banane hält, und den gesamten Dschungel dazu"
ist hingegen aus dem Zusammenhang gerissen. Das Zitat kritisiert ein Problem der Wiederverwendbarkeit von OO-Code. Wenn die Banane tatsächlich genießbar ist, ohne dass der Gorilla sie hält (oder sich in seinem Dschungel befindet), die Klasse aber so erstellt wurde, dass man sie unbedingt nur im Dschungel essen kann, dann taugt entweder das Klassendesign nichts. Oder der Wiederverwender, denn Joe Armstrong fährt so fort:
"If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project."
Er spricht also nicht von Klassenbibliotheken, sondern von Sourcecode-Übernahme. Klassen neigen zu Kohärenz, d.h. die Methoden einer Klasse hängen inhaltlich zusammen und bearbeiten gemeinsame Daten. Wenn ich die Banane (eine Methode aus einer Klasse) nicht aus ihrer Klasse herauskopieren kann, um sie wiederzuverwenden, dann hat das bei ordentlichem Design wohl den Grund, dass diese Banane nicht wiederverwendbar ist.
Allerdings muss man auch sehen, dass das Zitat von jemandem stammt, der stolz von dem Loch in der Wand erzählt, dass das C++-Buch hinterließ, als er es angewidert weggeschmissen hat, und der Jahrzehnte an FORTRAN auf dem Buckel hat[1]
OOP entfaltet seine Stärken erst, wenn Teams an komplexen Systemen arbeiten, bei denen Kapselung wichtiger ist als Code-Schlankheit.
ignoriert die Vorteile dieser Kapselung, die auch bei kleinen Projekten relevant sind. Oder bei größeren Einzelentwicklerprojekten Du erwähntest den Testaufwand. Unit-Tests können diesen Testaufwand deutlich verringern, vor allem bei der Weiterentwicklung, weil sie Dir die Sicherheit geben können, dass sich dein Code immer noch alle vorherigen Spezifikationen erfüllt. Sie machen natürlich im Vorfeld mehr Aufwand und man braucht den Toolstack dafür. Beim Bau einer einfachen Anwendung scheut man das, aber sehr viele komplexe Anwendungen sind aus einfachen Anwendungen entstanden und stecken am Ende im Sumpf ihrer unauflösbaren Abhängigkeiten fest.
Das ist das Ziel von OO: Code-Abhängigkeiten reduzieren bzw. sie sichtbar zu machen, wo sie bestehen. Und Softwareschichten lose zu koppeln. Ein kleines Programm lässt sich mit der VHIG[2]-Methode erstellen. 3500 Zeilen sind noch halbwegs klein.
Wenn ich alleine arbeite, erreiche ich mit OOP nur noch mehr Fragmentierung.
Diese „Fragmentierung“ nennt sich Separierung von Zuständigkeiten. Wenn Du deren Vorteile nicht erkennst, ist dein Code vielleicht noch nicht durch genug Iterationen gelaufen. Oder nicht sehr komplex. Viele Zeilen können den Code kompliziert machen, aber komplex und kompliziert sind unterschiedliche Achsen im Koordinatensystem des Coding-Wahns.
Rolf
Quelle: https://erlang.org/pipermail/erlang-questions/2013-January/071944.html ↩︎
Vom Hirn Ins Gerät ↩︎
Hallo Rolf,
Im übrigen bescheren Dir deine Folding-Funktionen ebenfalls weitere Einrückung.
Ja, das ist korrekt. Aber jetzt kommt das Entscheidende bei Code-Strukturierung im "Folding-Stil": Die Einrückung ist LOKAL, ich muss nirgendwo hinhüpfen, ich brauch nur aufzuklappen. Der Unterschied zu einem Stil, der Folding aktiv nutzt, ist wie der Unterschied zwischen einfachem Text und Hypertext. Bei einfachem Text kannst Du nicht auf einen Link klicken, um dahinter genauer nachzusehen. Ein Klick auf einen Link leistet das aber.
Ähnlich ist es mit einem gefoldeten Block: Solange ich noch weiß, was dahintersteckt, i.d.R. wird das während der Code-Erstellung der Fall sein, lasse ich ihn zugeklappt. Aber Monate später, bei einer Revision, weiß ich es nicht mehr oder nicht mehr genau genug. Und genau dann macht es sich bezahlt, wenn Du "einfach aufklappst", anstatt über diverse Mechanismen die Lokalität zu wechseln.
Bei Folding geht es im wesentlichen darum, zu lokalisieren anstatt zu separieren. Das hat in der Praxis enorme Vorteile. Du braucht es ja nur mal selbst auszuprobieren.
Gruß, fischlak
Hallo fischlak,
Du braucht es ja nur mal selbst auszuprobieren.
Ich werde den Teufel tun und meinen Code kaputtmachen. Wenn ich zu einer Funktion will, drücke ich meinem Visual Studio F12 und bin da. Mit Ctrl+- bin ich wieder zurück. Auch über Verfolgungsketten hinweg.
Du hast dein Evangelium und ich habe meins. Der Unterschied ist die Anzahl der Gläubigen.
Fazit des Threads: Du hast nicht viel zum Thema "Code-Folding Support in diversen Editoren" bekommen. Weil hier keiner ist, für den das sehr wichtig ist.
Dafür ist es uns wichtig, dass schwierige Einzelmeinungen zum Thema OOP nicht unwidersprochen bleiben.
Rolf
Hallo Rolf,
Wenn ich zu einer Funktion will, drücke ich meinem Visual Studio
F12und bin da. MitCtrl+-bin ich wieder zurück. Auch über Verfolgungsketten hinweg.
Ja, via Shortcut zu Referenzen/Implementationen springen und wieder zurück, das kann ich auch mit Kate, dafür brauch in bei Javascript keine IDE. Solche Wechselsprünge kann sowohl der LSP-Client als auch Kate nativ.
Ich werde den Teufel tun und meinen Code kaputtmachen.
Hat ja niemand gesagt. Wenn ich etwas teste, dann teste ich nicht mitten in "meinem Code".
Weil hier keiner ist, für den das sehr wichtig ist.
Wenn 100 Leute das Gleiche sagen, dann muss es ja nicht das Richtige sein...
Dafür ist es uns wichtig, dass schwierige Einzelmeinungen zum Thema OOP nicht unwidersprochen bleiben.
Das ist der Sinn von Diskussionen – einfach Austausch. Jeder macht seine eigenen Erfahrungen. Kein Grund, eine andere Meinung als "ans Bein pinkeln" aufzufassen.
Bisher hast Du auf mich einen soliden Eindruck gemacht. Kein Grund, mit
uns
und
schwierige Einzelmeinungen
sich zusätzlich eine stützende semantische Säule zu verschaffen.
Gruß, fischlak
Hallo fischlak,
Eine
stützende semantische Säule
brauche ich nicht, aber da ich nicht der Einzige war, der mitgeredet hat, wäre der Singular falsch gewesen. Abgesehen davon, dass ich diese Pappenheimer schon etwas länger kenne 😉
Wenn 100 Leute das Gleiche sagen, dann muss es ja nicht das Richtige sein...
Wieviele Leute A sagen ist egal. Interessant ist das Verhältnis $$\frac{\overline A}{A + \overline A}$$.
Oder sagte doch neulich der selbstbewusste Autofahrer zur Verkehrsfunkmeldung: „Ein Geisterfahrer? HUNDERTE!!!“
Rolf
Hallo Rolf,
Warum schreibst Du nicht gleich NOT A?
Ich wette, Du hast sicherheitshalber eine Wahrheitstabelle genommen, um den Ausdruck zu überprüfen… :-)
Über Peter Thiel (nein, ich bin kein Freund seiner Ansichten) sagt man, dass er jeden, den er erstmalig kennen lernt, mit dem Satz "Was glaubst du, was andere nicht glauben?" begrüßt. Und Thiel ist Milliardär geworden… NOT A IDIOT :-)
Gruß, fischlak
Lieber fischlak,
Und Thiel ist Milliardär geworden… NOT A IDIOT :-)
Milliardär zu werden ist nicht der Beweis für „not an idiot“. Wenn man aber mal schaut, womit er das viele Geld „verdient“ hat, dann könnte man fast annehmen wollen, dass er kein guter Mensch sein kann, weil Skrupellosigkeit und ungeheurer Reichtum oft zusammen auftreten. Es würde mich nicht mit Zufriedenheit erfüllen, wenn ich wüsste, dass ich meine Milliarden dadurch erhalten habe, dass ich demokratische Staaten dazu verführt habe, autoritäre Staaten zu werden, die Menschenrechte zunehmend mit Füßen treten.
Liebe Grüße
Felix Riesterer
Hallo Felix,
auch mir ist der Typ extrem unsympathisch. Allein schon seine extrem missmutige Mimik, wenn er sich in der Öffentlichkeit bewegt.
Aber auch ein größenwahnsinniger Egozentriker kann mal was Gescheites sagen. Von anderen ist mir solch ein Zitat sinngemäß nie begegnet, deshalb ist es mir in Erinnerung geblieben.
Gruß, fischlak
Lieber fischlak,
auch mir ist der Typ extrem unsympathisch. Allein schon seine extrem missmutige Mimik, wenn er sich in der Öffentlichkeit bewegt.
Sympathie ist für mich kein Kriterium, ob ich einen Menschen für gut oder schlecht halte. Oft braucht es Menschen, die sich durchsetzen können, welche dafür - so sagt die Psychologie - mehrheitlich weniger liebenswert auftreten. Das bedingt sich gewissermaßen gegenseitig.
Was mich aber ganz schnell urteilen lässt, ist der Fall, wenn Menschen das Leben von anderen unnötig ins Elend führen. Schlimmer noch, wenn sie sich daran bereichern.
Aber auch ein größenwahnsinniger Egozentriker kann mal was Gescheites sagen.
Was Gescheites sagen hat mit Intelligenz zu tun. Ich habe Thiel in einem Interview über 90 Minuten lang zugehört, um ein Gefühl dafür zu bekommen, wie der so drauf ist. Und der Kerle ist sehr intelligent, keine Frage. Ohne die ist man wirtschaftlich nicht erfolgreich. Aber das waren andere auch. Über die schlimmsten Menschen der Geschichte findet man fast immer „gescheite Sachen“, die sie gesagt haben (sollen).
Liebe Grüße
Felix Riesterer
Hallo Felix,
ja ich bin da ganz bei Dir.
Ich wusste, dass ich diesen Typen nicht zitieren sollte. Ich hätte mich wohl nach einer Zitat-Alternative umsehen sollen :-(
Gruß, fischlak
Hi,
Du hast dein Evangelium und ich habe meins. Der Unterschied ist die Anzahl der Gläubigen.
naja, nur weil Millionen von Fliegen Scheiße fressen …
cu,
Andreas a/k/a MudGuard
Quelle: https://erlang.org/pipermail/erlang-questions/2013-January/071944.html
@Rolf B Danke für diesen Link - Sehr lesenswert!