Kleinteilige Funktionen

[braunbär]

Erst wenn ich in die Verlegenheit komme, dass ich an einen speziellen Programmteil etwas ändern muss. Je nach Projekt ändern sich aber 40% - 75% einer Software jahrelang nicht. Warum soll ich mich dann damit beschäftigen?

Wenn du nichts ändern musst, brauchst du dir den übergeordneten Code auch nicht anschauen.

Tut mir leid dass du doch so sehr engstirnig eingestellt bist. Ich habe aber auf Arbeit anderes zu tun als über jede Zeile Code nachzusinnen nur weil der entsprechende Entwickler es nicht schafft den Code teamfähig zu gestalten.

Das hat nichts mit "engstirnig" zu tun. In einem normalen Programm von mir wird so eine Zeile entsprechend kommentiert. Aber nachdem der Einzeiler standalone da steht, denke ich, dass es jedem auch nur mäßig begabten Programmierer möglich ist, auf einen Blick zu sehen, was der kurze Codeschnipsel macht. Das musst du ja auch können, wenn du genau in diesem Bereich etwas ändern musst und deshalb deine Funktion ändern willst. Dann wirst du über dieser Funktion auch nicht 1/4 Stunde lang grübeln.

Ich komme nicht in die Verlegenheit ein Programm pflegen zu müssen ohne das passende Werkzeug.

Ich habe mir schon öfters auf eine kurze Reise auf meinem Notebook, auf dem ich normalerweise keine IDE installiert habe, weil ich sie praktisch nie brauche, Quellcode mitgenommen, um ihn zwischendurch zu studieren.

Das tut mir leid.

Das braucht dir nicht leid zu tun. Wenn ich damit ein Problem hätte, hätte ich eine IDE auf dem Notebook installiert.

[m.fuchs]

Je nach Projekt ändern sich aber 40% - 75% einer Software jahrelang nicht. Warum soll ich mich dann damit beschäftigen?

Wenn du nichts ändern musst, brauchst du dir den übergeordneten Code auch nicht anschauen.

Was für ein Unfug. Hast du schon irgendwann mal ein großes Projekt mit verschieden Schichten bearbeitet?

Nehmen wir mal einen Onlinegame an. Wir haben dort eine Kundenverwaltung die bei einer Rücklastschrift den Zugang eines Benutzers sperrt. Dafür bedient sie sich einer Funktion mit Namen LockAccount. Ich bekomme nun den Auftrag das System zu veränden. Es soll bei dreimaligen Auftreten von beleidigenden Worten im In-Game-Chat der Account ebenfalls gesperrt werden. Dann nutze ich dafür auch die Funktion LockAccount. Ich muss sie aber nur nutzen, nicht hineinsehen.
Schon habe ich eine Änderung die die übergeordnete Schicht betrifft, aber nicht die untergeordnete.

Aber nachdem der Einzeiler standalone da steht, denke ich, dass es jedem auch nur mäßig begabten Programmierer möglich ist, auf einen Blick zu sehen, was der kurze Codeschnipsel macht. Das musst du ja auch können, wenn du genau in diesem Bereich etwas ändern musst und deshalb deine Funktion ändern willst. Dann wirst du über dieser Funktion auch nicht 1/4 Stunde lang grübeln.

Es geht nicht darum was eine Zeile Code macht sondern um den Zusammenhang im Programm. Es gibt keinen Grund sich die Implementierung anzusehen, im Gegenteil sie lenkt nur ab. Du schaust dir doch auch nicht den Quellcode von GTK und Win32 an um das OnClick eines TButton zu bearbeiten.

[braunbär]

Was für ein Unfug. Hast du schon irgendwann mal ein großes Projekt mit verschieden Schichten bearbeitet?

Nein. Das längste Programm, das ich je geschrieben habe, war 24 Zeilen lang

Dann nutze ich dafür auch die Funktion LockAccount. Ich muss sie aber nur nutzen, nicht hineinsehen.

Das hat doch mit unserer Diskussion nichts zu tun. Dein LockAccount ist sicher kein Ein- oder Zweizeiler, und nur um die Ebene geht es bei dieser Diskussion. Dass es sinnvoll ist, abgeschlossene, komplexere Funktionen in Unterprogramme zu gliedern, ist doch völlig unstrittig.

Es geht nicht darum was eine Zeile Code macht sondern um den Zusammenhang im Programm

Eine Zeile, die hier als BEISPIEL für Sprachsyntax ohne weiteren Zusammenhang gepostet wird, steht in keinem "Zusammenhang im Programm", weil es das größere Programm zu der Zeile HIER nicht gibt.

Es gibt keinen Grund sich die Implementierung anzusehen,

Wenn du in einem Diskussionsthread über Sprachsyntax "keinen Grund sich die Implementierung anzusehen" findest, dann weiß ich wirklich nicht, worüber wir diskutieren.

[m.fuchs]

Langsam habe ich das Gefühl du willst nur trollen.

Dann nutze ich dafür auch die Funktion LockAccount. Ich muss sie aber nur nutzen, nicht hineinsehen.

Das hat doch mit unserer Diskussion nichts zu tun. Dein LockAccount ist sicher kein Ein- oder Zweizeiler, und nur um die Ebene geht es bei dieser Diskussion.

Warum sollen es keine zwei Zeilen sein? Eine Zeile um das Datenbankstatement zusammenzubauen und eine Zeile um es abzusenden. Fertig.

Es geht nicht darum was eine Zeile Code macht sondern um den Zusammenhang im Programm

Eine Zeile, die hier als BEISPIEL für Sprachsyntax ohne weiteren Zusammenhang gepostet wird, steht in keinem "Zusammenhang im Programm", weil es das größere Programm zu der Zeile HIER nicht gibt.

Es gibt keinen Grund sich die Implementierung anzusehen,

Wenn du in einem Diskussionsthread über Sprachsyntax "keinen Grund sich die Implementierung anzusehen" findest, dann weiß ich wirklich nicht, worüber wir diskutieren.

Ach so, dann sag doch gleich dass es dir nur um völlig theoretische Diskussion geht. Und um eine Sprache die nur dazu dient ab und zu einen Zweizeiler zu zeigen, aber niemals ein tatsächliches Projekt. Ich kann mir aber nicht vorstellen dass dieses Ziel von mse verfolgt wird. Er hat mit Sicherheit Größeres mit seiner Sprache vor.

[Socke]

Langsam habe ich das Gefühl du willst nur trollen.

Dann nutze ich dafür auch die Funktion LockAccount. Ich muss sie aber nur nutzen, nicht hineinsehen.

Das hat doch mit unserer Diskussion nichts zu tun. Dein LockAccount ist sicher kein Ein- oder Zweizeiler, und nur um die Ebene geht es bei dieser Diskussion.

Warum sollen es keine zwei Zeilen sein? Eine Zeile um das Datenbankstatement zusammenzubauen und eine Zeile um es abzusenden. Fertig.

Man könnte auch sagen: jede semantisch eigenständige Aufgabe soll als eigene Funktion/Prozedur/Methode implementiert werden?

[m.fuchs]

Man könnte auch sagen: jede semantisch eigenständige Aufgabe soll als eigene Funktion/Prozedur/Methode implementiert werden?

Genau, das entspricht dann dem Single-Responsibility-Prinzip.

[braunbär]

Man könnte auch sagen: jede semantisch eigenständige Aufgabe soll als eigene Funktion/Prozedur/Methode implementiert werden?

Genau, das entspricht dann dem Single-Responsibility-Prinzip.

Prinzipiell ist dagegen nichts einzuwenden - bloß, dass "semantisch eigenständige Aufgabe" in Wirklichkeit ein extrem schwammiger Begriff ist.
Weil letztlich hat jedes einzelne Statement eines Programms aus irgend einem Blickwinkel heraus eine "semantisch eigenständige Aufgabe". Aber das Aufspalten in "semantisch eigenständige Aufgaben" sollte man eben nicht übertreiben.

Ach so, dann sag doch gleich dass es dir nur um völlig theoretische Diskussion geht.

Eine Diskussion über Sprachfeatures IST eine Diskussion über Theorie. Genauso übrigens wie eine Diskussion über Prozedurgrössen.

Und um eine Sprache die nur dazu dient ab und zu einen Zweizeiler zu zeigen, aber niemals ein tatsächliches Projekt.

Was ist denn das für eine erbärmliche Demagogie! Sprachen dienen dazu, Projekte zu erstellen, nicht dazu, sie zu zeigen. Und wenn ich in dieser Diskussion zu so einer Frage ein Beispiel bringe, dann werde ich kein 20000-Zeilen-Projekt posten.

[m.fuchs]

Und um eine Sprache die nur dazu dient ab und zu einen Zweizeiler zu zeigen, aber niemals ein tatsächliches Projekt.

Was ist denn das für eine erbärmliche Demagogie! Sprachen dienen dazu, Projekte zu erstellen, nicht dazu, sie zu zeigen. Und wenn ich in dieser Diskussion zu so einer Frage ein Beispiel bringe, dann werde ich kein 20000-Zeilen-Projekt posten.

Ich glaube du solltest Fremdworte erstmal googeln bevor du sie benutzt. Abgesehen davon was willst du eigentlich? Du hast rumgejammert dass ich nicht exakt auf deine zwei Zeilen eingehe sondern einen Praxisbezug herum konstruiere. Also scheint es dir ja nur um diesen Zweizeiler zu gehen. Jetzt sagst du wieder es geht um die Praxis aber möchtest das Drumherum nicht anerkennen. Entscheide dich mal.

[pluto]

Mal eine kleine Frage zwischendurch: Wisst ihr eigentlich noch um was es hier seit ein paar Tagen geht? In diesen Thread?

Es geht darum, in weit man Code in eigenen Funktionen auslagern soll oder nicht.

Der eine meinte, es wird zu unübersichtlich, der andere Sagt dazu: Genau aus diesem Grund gibt es eine Doku mit Zusammenfassung.
Ich sage: Keiner List eine Doku. Wer list schon ein Handbuch zu einem Programm durch?

Ein Code muss so geschrieben sein, dass man ohne viel Nachzudenken ihn versteht. Da helfen immer kleine Kommentare. Jedoch auch wieder: Weniger ist mehr, also bitte keine Romane in den Code schreiben.

[braunbär]

Ich glaube du solltest Fremdworte erstmal googeln bevor du sie benutzt.

Anscheinend verstehst du das Wort nicht, da kann ich aber nichts dafür. Die Unterstellung, aus meiner Sicht würden Programmiersprachen dazu dienen, ab und zu einen Zweizeiler zu zeigen, aber niemals ein tatsächliches Projekt, ist reinste Demagogie: Du verzerrst ganz bewusst meine Aussagen mit der Absicht, sie zu diskreditieren.

Du hast rumgejammert

Nein, ich habe auch nicht den geringsten Grund zu jammern. Ich habe dir widersprochen. Widerspruch als jammern zu bezeichnen, ist übrigens wieder demagogisch.

dass ich nicht exakt auf deine zwei Zeilen eingehe sondern einen Praxisbezug herum konstruiere.

Das Beispiel habe ich in einem Thread gebracht, in dem es um Sprachfeatures und Pascal-Syntax ging, nicht um "Auslagern in Prozeduren". Das war in dem Thread überhaupt nicht das Thema. Wenn du über Syntax redest, ist ein "darum herum konstruierter Praxisbezug" irrelevant.

Und für eine Diskussion des syntaktischen Konstrukts ist im übrigen auch völlig irrelevant, ob diese zwei Zeilen Teil eines größeren Unterprogramms sind oder, ganz deinen Vorstellungen entsprechend, in eine separate Funktion ausgelagert werden. Dein Einwurf war an der Stelle eigentlich völlig off topic.

Der eine meinte, es wird zu unübersichtlich,

Genau, darum geht es. Wenn man das Auslagern übertreibt, wird es unübersichtlich.
Wenn man einen Zeitungsartikel liest, dann erwartet man, dass der in vernünftige Absätze gegliedert ist. Wenn aber JEDER Satz ein eigener Absatz ist, dann konterkariert das das Ziel, durch sinnvolle Absatzbildung den Text zu strukturieren.

Der Code muss so geschrieben sein, dass man ohne viel Nachzudenken ihn versteht. Da helfen immer kleine Kommentare. Jedoch auch wieder: Weniger ist mehr, also bitte keine Romane in den Code schreiben.

Dem würde ich fast ohne Einschränkungen zustimmen. Die Einschränkung bezieht sich auf das kleine Wort "man": Ein Programmierer, der die Sprache kennt, sollte den Code ohne Problem lesen und verstehen können. Code muss aber m.E. nicht so geschrieben sein, dass meine Freundin, die von Pascal keine Ahnung hat, glaubt, zu verstehen, was da passiert.

[m.fuchs]

Sprachen dienen dazu, Projekte zu erstellen, nicht dazu, sie zu zeigen.

Hier geht es um den Prxaisbezug.

Wenn du über Syntax redest, ist ein "darum herum konstruierter Praxisbezug" irrelevant.

Und jetzt wieder geht es dir nur um einen abstrakten Syntax.

Und so geht es hin und her. Schade dass man mit dir so nicht diskutieren kann. Thematisch wäre es ja schon interessant.
An dieser Stelle bin ich dann mal raus.

[braunbär]

Sprachen dienen dazu, Projekte zu erstellen, nicht dazu, sie zu zeigen.

Hier geht es um den Prxaisbezug.

Und was hat das mit deiner Unterstellung zu tun?

Und jetzt wieder geht es dir nur um einen abstrakten Syntax.

Im ursprünglichen Thread wurde über Sprachfeatures und Syntax diskutiert. Da ging es tatsächlich um Sprachfeatures und "abstrakte" Syntax.
In diesem Thread geht es um "kleinteilige Funktionen", und auch zu diesem Thema habe ich meine Meinung klar bekundet. Da geht es NICHT um "abstrakte Syntax".
Dass du meine Posts in einem anderen Thread, der in einem völlig anderen Kontext steht, im Kontext dieses Threads zu diskreditieren versuchst, ist eine unlautere Diskussionsweise, gegen die ich mich zur Wehr gesetzt habe und zur Wehr setze.

[pluto]

dass meine Freundin, die von Pascal keine Ahnung hat, glaubt, zu verstehen, was da passiert.

Schaden würde es aber auch nicht, ein Code so zu schreiben, dass jemand der keine Ahnung davon hat, auch in etwa versteht was da passiert.
Aber das ist zweierlei: Einmal muss man de Code verstehen und einmal muss man wirklich so denken wie ein Computer Denkt(Das hört sich doof an, ist aber so. Ein Computer Denkt nämlich gar nicht....)

Um Ein Beispiel zu bringen: Nur weil ich die Tastatur verstehe, kann ich nicht unbedingt auch den PC bedienen.
(Welche Serie? Welche Folge?)

Thematisch wäre es ja schon interessant.
An dieser Stelle bin ich dann mal raus.

Ich glaube, ihr redet einfach aneinander vorbei. Darum kommt ihr nicht auf ein Gemeinsamen Nenner.

[braunbär]

Schaden würde es aber auch nicht, ein Code so zu schreiben, dass jemand der keine Ahnung davon hat, auch in etwa versteht was da passiert.

Auch das stimmt sicher in den meisten Fällen, aber es geht halt nicht immer, oder manchmal nur um den Preis von unbeholfenem Code (weil die bessere Variante für einen ohne entsprechende Kenntnisse der Programmiersprache eben nicht durchschaubar ist). Deshalb würde ich das nicht generell als Anforderung für guten Code postulieren.

[pluto]

Auch das stimmt sicher in den meisten Fällen, aber es geht halt nicht immer, oder manchmal nur um den Preis von unbeholfenem Code

Davon kann man hier im Forum viel Code finden, der nicht Formatiert ist oder Strukturiert ist.