Ist das sauberer Programmierstil?!

[Vitus]

Hallo zusammen,

ich habe in einem Tutorial etwas in der Art entdeckt:

Delphi-Quellcode:

procedure TTestKlasse.nurEinTest();
  function test(): integer;
  begin
    result := 5;
  end;
begin
  test;
end;

Dieses Einbetten einer Routine in eine andere sieht für mich ziemlich krank aus...
Ist das normal?!? Nutzt das jemand? Macht es Sinn? (damit meine ich nicht diese unsinnige Prozedur ;) )

Würde mich mal interessieren... :roll:

[MisterNiceGuy]

Würd mich auch mal interessieren. Krank sieht das zwar nicht aus, aber unübersichtilich schon!

Ich nehm mal an, dass die Funktion nur auf diese eine Prozedur anwendbar ist oder?

[negaH]

Wenn man vor und hinter der "nested" Prozedure eine Leerzeile einfügt, dann IST das ein sauberer Programmierstil.
Das ist absolut nicht krank, sondern sogar eine sehr gute Methode um prozedurale Techniken stärker zu modularisieren. Überführt man das NICHT-kranke PROGRAM/LIBRARY Konzept auf das NICHT-kranke UNIT Konzept, auf das NICHT-kranke INTERFACE/IMPLEMENTATION Konzept dann ist der nächste logische Modularisierungs-Schritt der Schritt zum NICHT-kranken PROCEDURE/nested Procedure Konzept.

Gruß Hagen

[Robert Marquardt]

Das ist echtes und sinnvolles Pascal.
Indem man Codeteile in sinnvolle Teilfunktionen zerlegt, bekommt man flexibleren und besser wartbaren Code.
Je kleiner die Funktion desto leichter laesst sich ihre Korrektheit ueberpruefen.
Eine sinnvolle Zerlegung vermeidet Copy & Paste-Sourcen, die eine haeufige Quelle von Fehlern sind.
Indem man sinnvoll strukturiert kann man auch Fehlern im Ansatz leichter auf die Spur kommen.

[Bernhard Geyer]

Wird von mir genutzt.

Sinn: Eine größere Aufgabe wird in mehrere Blöcke/Einzelfunktionen zerlegt. Diese Allgemein zur Verfügung zu Stellen ist aufgrund der absoluten nur für diese Funktion Verwendbarkeit nicht gegeben.

[Supergrobie]

Hallo!

Ich mache das so wenn ich Schleifen innerhalb einer Funktion oder Prozedur mehrfach benötige und diese Definitiv nicht außerhalb brauche. :duck:

Wenn man sich an eine "anständige" :drunken: Einrückung hält, finde ich das vollkommen OK.

Stevie

[BKempf]

Das nutze ich regelmaessig bis in eine Ebene von ca. 4 Schachtelungen.
Ist einfach praktisch, um Methoden ihre eigenen kleinen Hilfsfunktionen mitzugeben, die verfuegbar bleiben, wenn die Methoden im Source umhergeschoben werden. Ausserdem unterstuetzt es die Kapselung.

[dizzy]

Ist richtig, die eingebettete Funktion (oder Prozedur) ist nur der "Mutter"-Funktion oder Prozedur bekannt. Ich habe das z.B. mal in meinem Parser genutzt. Ein praktischer Nutzen: Die "Kind"-Funktionen kennen die Variablen der "Mutter"-Funktion - und die sind damit also quasi in dieser "Mutter"-Funktion Semi-Global. Man muss also nicht so viel Parameterübergabe machen, wenn klar ist, dass die eingebetteten Funktionen nicht auch einzeln verwendet werden sollen/müssen.

Sieht nicht wirklich hübsch aus, kann aber sehr praktisch sein, und ist meiner Meinung nach auch in Sachen "Stil" völlig okay.

gruss,
dizzy

[Robert Marquardt]

Hinsichtlich des Codestils bevorzuge ich:
- Weglassen der leeren runden Klammern
- Integer statt integer
- Result statt result
- NurEinTest statt nurEinTest
- Test statt test
- eine Leerzeile vor und hinter der lokalen Funktion

[Robert Marquardt]

Zitat:

Zitat von BKempf

Das nutze ich regelmaessig bis in eine Ebene von ca. 4 Schachtelungen.

Das geht an die Grenze der Lesbarkeit. Das sind bereits 8 Zeichen Einrueckung.
Nicht viele Programmierer koennen dieser Tiefe folgen, besonders wenn Bezug auf globalere Variablen genommen wird.
Der Bezug auf globalere Variablen sollte vermieden werden. Parameter sind verstaendlicher und erlauben
tief verschachtelte Funktionen ohne Aenderung nach aussen in der Verschachteung zu ziehen.

Refactoring aka "alles umschreiben" ist eine haeufige Taetigkeit. Die Source sollte daher leicht zu aendern sein.

[dizzy]

Zitat:

Zitat von Robert Marquardt

Parameter sind verstaendlicher und erlauben
tief verschachtelte Funktionen ohne Aenderung nach aussen in der verschachteung zu ziehen.

Sie sind aber letztlich auch langsamer, oder?

[Robert Marquardt]

Zitat:

Zitat von dizzy

Sie sind aber letztlich auch langsamer, oder?

Ja, aber man schreibt den Code nicht gleich auf Performance.
Erst muss er korrekt laufen, dann kann man ihn beschleunigen.
Erst sollte man die algorithmischen Moeglichkeiten zu Ende optimieren,
bevor man auf Instruktionsebene optimiert.

[dizzy]

Gelesen und für gut befunden :)

[Robert Marquardt]

Ja im :warn:-Modus bin ich gut :tongue:

[Phoenix]

Das ganze hat noch einen Vorteil:

Sollte die nested Procedure doch irgendwann einmal woanders benötigt werden, so kann diese recht einfach aus der Funktion/Prozedur entfernt und sozusagen Standalone eingesetzt werden.

Das lässt sich hinterher leichter warten.

[negaH]

Zitat:

Das geht an die Grenze der Lesbarkeit. Das sind bereits 8 Zeichen Einrueckung.
Nicht viele Programmierer koennen dieser Tiefe folgen, besonders wenn Bezug auf globalere Variablen genommen wird.

Irrelevant. Der Sinn ist es doch diese Teil-Aufgaben selber als "Black-Boxes" zu verifizieren. Somit würde sich sogar eine 16 fach nested Funktion immer noch lohnen falls man ihre Funktionalität aus sich selber heraus verifizieren kann. Statt also eine Monster Funktion im Gesammten zu verifizieren, würde man mit nested Funktionen Stück für Stück verifizieren. Sobald eine solche nested Funktion verifiziert wurde, kann man sie aus dem Kopf streichen und einfach überlesen.
Somit erhöht die Modularisierung, egal ob nested Funktion oder Objectmethoden oder Units oder externe DLL's, immer auch die Wartbarkeit und Lesbarkeit. Der EINZIGSTE relevante Unterschied zwischen nested Funktionen und anderen Methoden der Modularisierung besteht in ihere Gültigkeit=Scope. Nun nested Funktionen sind globale für die Übergeordneten Scopes, aber Lokale innerhalb des übergeordenten Scopes. Sie können also auf anderer Modularisierungsebene, zB. Objecten, Units, Program, Library nicht merhfach benutzt werden.
Somit ist auch die logische Frage geklärt WANN man zu nested Funktionen greifen sollte.

Das Konzept der nested Funktionen ist also absolut sauberer Programmierstil.

@Performance:
Da der Delphi Optimierer immer lokal zu einer Procedure optimieren kann, also NICHT Procedure-übergreifend, sind durch die Vereinfachungen komplexer Proceduren mit Hilfe von nested Prozeduren sogar erhebliche Performance-Steigerungen zu erwarten. Statt also EINE Prozedure mit 100 zu optimierenden Variablen zu optimieren kann der Compiler bei nested Funktionen viel kleine und voneinander unabhänig abgeschlossenen Optimierungen vornehmen. Dadurch ist eine höher Performance des erzeugten Gesamtcodes zu erwarten.
WICHTIG! ist dabei nur eines, die nested Funktionen sollte NICHT allzuofft auf Variablen der übergeordneten Funktion zugreifen. Statt also nested Funktionen ohne Parameter zu benutzen, ist es besser eben auch den nested Funktion so wie mit jeder anderen Procedure/Methode usw. die releaventen Daten als Paramter zu übergeben. Benutzt eine nested Funktion KEINERLEI Zugriffe auf übergeordete Lokale Stack Variablen, so kann der Optimieren einen zusätzlichen Stackframe wegoptimieren. Dadurch wird nochmals die Gesamtperformance gesteigert.


Gruß Hagen

[dizzy]

[OT] Ich find es immer wieder interessant, dass die wirklich interessanten kleinen netten Infos meist so am Rande mitten in einem Thread eingebettet kommen :mrgreen: [/OT]

[neolithos]

So sieht der Zugriff aus

Bsp

Delphi-Quellcode:

procedure FuncTop(a : integer);
var b : Integer;
    s : single;

  procedure FuncBetween(c : Integer);
  var d : Integer;
    procedure FuncBottom(e : Integer);
    var f : Integer;
    begin
      f := 6;
      Print(a, b, c, d, e, f);
    end;
  begin
    d := 4;
    FuncBottom(5);
  end;
begin
  b := 2;
  s := 1.3 / b;
  if s < b then
     FuncBetween(3);
end;

Zugriff auf b in FuncBottom

Code:

mov eax, [ebp+8] // Hole Zeiger auf Stackframe von FuncBetween
mov eax, [eax+8] // Hole Zeiger auf Stackframe von FuncTop
mov eax, [eax-4] // Hole Inhalt der Variable b

Deswege sollte den Zugriff auf häufig genutzte Variable via Parameter realisieren -> const var. Stellen eine wesentlich schnellere Alternative dar.

[Vitus]

Ich halte es einfach für fraglich ob dem OOP Konzept damit genüge getan wird...

Thema Copy & Paste Code: Das ist doch eigentlich gerade der Nachteil dieser "nested" Rutine!
Wenn ich nun nämlich feststelle dass diese genestete Funktion auch an anderen Stellen prima einsetzbar ist, dann fängt das copy & gepaste doch an!!

Ich würde in so einem Fall eher eine eigene private Funktion innerhalb der Klasse schreiben. Die kann ich innerhalb der Klasse auch innerhalb von anderen Prozeduren und Funktionen nutzen.

Ich sage nichts gegen die zerstückelung des Codes in Möglichst kleine Einheiten! Ich glaube anders kann man größere Projekte gar nicht bewältigen. Aber das da oben halte ich für ungünstig...


achja - um Einrückung und Groß-Kleinschreibung ging es mir eigentlich gar nicht *g* Das war nur schnell hingetippt - mir ging es wirklich nur um diese Funktion.

[SirThornberry]

Ich verwende das eigentlich nur wenn ich eine procedure oder funktion außerhalb einer klasse hab (bsp.: GetAlphaBlendColor) und darin hab ich dann eine nested-funktion die mir den Geblendeten wert zweier Farbbytes zurückgibt. Die nested-funktion außerhalb zu defnieren würde das ganze viel unübersichtlicher machen weil diese funktion als standalone keinen sinn macht. Wenn man dann irgendwann mal diese unit wieder öffnet und die funktion als standalone darin wäre müsste man erst suchen wofür diese benötigt wird, da sie aber in einer anderen funktion drin ist wird die unit gleich viel übersichtlicher weil nicht haufen einzelnen funktionen darin rumliegen die eventuell als standalone 0 sinn machen

[Vitus]

Mich würde dann mal interessieren ob ihr dann auch sowas zustande bringt:

Delphi-Quellcode:

procedure TTestKlasse.nurEinTest();

  function test(): Integer;

  TTest = Record
    x     : Integer;
    y     : Integer;
  end;

  begin
    machMitDemRecordIrgendwas;
    result := 5;
  end;

begin
  test;
end;

Übrigens interessant zu sehen wieviele Meinungen es zu einem so "unwichtgen" Thema gibt :spin2:

[negaH]

Zitat:

Ich halte es einfach für fraglich ob dem OOP Konzept damit genüge getan wird...

Wer redet hier von Object Orientierter Programmierung ??
Nested Funktionen sind ein reines Hilfsmittel der prozeduralen Programierung, und OOP nutz eine spezielle Form der prozeduralen Programmierung um zusätzlich neue Möglichkeiten zu erreichen.

Zitat:

Thema Copy & Paste Code: Das ist doch eigentlich gerade der Nachteil dieser "nested" Rutine!

Eine Nested Funktion wird erstmal primär IMMER mit deren übergeordneter Funktion zusammen kopiert. Beides, die übergeordnete Funktion UND die nested Funktionen bilden EINE Einheit. Aus konzeptioneller macht es also keinen Sinn die nested Funktion separat zu kopieren, da sie logisch gesehen OHNE die übergeordnete Funktion keinen Sinn macht. Sogesehen macht es gerade beim Copy&Paste sinn mit nested Funktionen zu arbeiten, da man durch das Kopieren des äußersten Scopes die notwendigen nested Funktionen MIT-Kopiert, statt sie zu vergessen.

Zitat:

Wenn ich nun nämlich feststelle dass diese genestete Funktion auch an anderen Stellen prima einsetzbar ist, dann fängt das copy & gepaste doch an!!

Eben exakt in diesem Moment hast du den Sinn der nested Funktionen NICHT verstanden, und die nested Funktion statt der günstigeren normalen Funktion benutzt. Erstmal bestreitet ja keinr hier das man bei Mehrfachbenutzung der gleichen Funktionalität eben KEINE nested Funktion nehmen sollte. Aber gerade für Erstentwicklungen bei denen man NICHT abschätzen kann ob eine hochspezielisierte Funktion tatsächlich mehrmalig benutzt wird, machen nested Funktion Sinn. Denn im späteren Verlauf ist es ein Leichtes aus der nested Funktion eine globale zu machen, OHNE das man am wichtigen Source was ändern müsste.
Somit, verkehrt sich deine Argumentation in das exakte Gegenteil, und alles spricht FÜR nested Funktionen.

Zitat:

Ich würde in so einem Fall eher eine eigene private Funktion innerhalb der Klasse schreiben. Die kann ich innerhalb der Klasse auch innerhalb von anderen Prozeduren und Funktionen nutzen.

Wer sagt denn hier was darüber das man überhaupt mit Objekten arbeitet ?
Wie soll einer eine nested Funktion in ein Objekt als private Methode deklarieren wenn er garkein Objekt dafür hat ?
Davon abgesehen: wenn in einer Objectmethode eine nested Funktion benutzt wird dann hat das eben den Grund die Sichtbarkeit der nested Funktion noch viel stärker einzuschränken als dies mit einer privaten Methode möglich wäre !

Zitat:

Ich sage nichts gegen die zerstückelung des Codes in Möglichst kleine Einheiten! Ich glaube anders kann man größere Projekte gar nicht bewältigen. Aber das da oben halte ich für ungünstig...

Worin besteht für dich der Unterschied zwischen kleinen und großen Projekten, in Bezug auf die Regeln der Modularisierung der Sourcen ??

Es gibt da keinen Unterschied in diesem Punkt. Der einzigste Unterschied bestünde in der Anzahl der Module/Schnittstellen und deren Komplexität, ABER NICHT in der Art und Weise wie man den Source schreibt. Die Nested Funktion ist also ein Hilfsmittel der Programmiersprache und dient nicht im speziellen der Lösung eines Programmierzieles im allgemeinen !!

Gruß hagen

[negaH]

Zitat:

Übrigens interessant zu sehen wieviele Meinungen es zu einem so "unwichtgen" Thema gibt

es gibt eigentlich nur 2 Meinungen, diejenigen die es als unsauber empfinden und diejenigen die es konzeptionell als richtig emfinden.
Unwichtig ist dieses gerade deswegen überhaupt nicht, da nur EINE Meinung richtiger als die andere sein MUSS !

Desweiteren ist eben auch der Punkt der PASCAL/Delphi konformen Schreibweise der Bezeichner, den Einrückungen und den Leerzeilen ein gleichbedeutender Punkt wie die neseted Funktionen. Grundsätzlich sind nämlich alle diese Punkte eine Frage nach dem besten Programmierstil und haben erst sekundär Auswirkung auf die erreichbare Funktionalität in den resultierenden Anwendungen.

Gruß Hagen

[Vitus]

hmmm ich versuche einfach immer mit Objekten zu arbeiten.

Im obigen Beispiel ist die Prozedur in der Klasse TTestKlasse - in so einem Fall habe ich bisher immer so gearbeitet dass ich die Funktion test in der Klasse als private deklariert hätte. Das Ergebnis wäre das gleiche, nur das der Code, in meinen Augen - und das ist lediglich meine subjektive Meinung - etwas übersichtlicher ist.
Und wenn man dieses nested Spielchen wirklich bis zu 4 Ebenen fortsetzt, wird es schon schwierig 3 Einrückungen von 4 zu unterscheiden ;)

Zitat:

Worin besteht für dich der Unterschied zwischen kleinen und großen Projekten, in Bezug auf die Regeln der Modularisierung der Sourcen ??

Wenn ich schnell mal ein Programm brauche um.... keine Ahnung... in einem Text alle "Vitus" in "Sutiv" zu verwandeln, dann ist mir der Stil ziemlich wurscht. Das Programm brauche ich einmal und danach kommt es in die Tonne. Das wäre ein kleines Projekt. Gut - in diesem Fall braucht keiner eine solch eingebettete Funktion, aber Du weißt schon was ich meine ;)

[Vitus]

ooooh - ich denke da besteht schon ein großer Unterschied!

Ich halte es für fraglich ob nested Funktion den OOP Konventionen entsprechen, hinsichtlich von Kapselung und Lesbarkeit.
Wer eine Leerzeile nicht schreibt, oder einen Kommentar wegläßt, der ändert ja am Programmteil des Sources nichts!

[negaH]

Hi Vitus,

ich glaube es ist schwer dir das Konzept als solches näher zu bringen.

Zitat:

Im obigen Beispiel ist die Prozedur in der Klasse TTestKlasse - in so einem Fall habe ich bisher immer so gearbeitet dass ich die Funktion test in der Klasse als private deklariert hätte. Das Ergebnis wäre das gleiche, nur das der Code, in meinen Augen - und das ist lediglich meine subjektive Meinung - etwas übersichtlicher ist.
Und wenn man dieses nested Spielchen wirklich bis zu 4 Ebenen fortsetzt, wird es schon schwierig 3 Einrückungen von 4 zu unterscheiden

Eben nicht. Es interessiert NICHT wieoft und wie tief man Verschachtelt, sondern es IST ein Hilfsmittel die Aufgaben des Programmes struktriert zu modularisieren.
Besteht in einer Klasse die NOTWENDIGKEIT das eine Funktionalität MEHRFACH an verschiedenen Stelle benutzt werden soll so ist eine nested Funktion eine schlechte Wahl.
Besteht dagegen die Notwendigkeit innerhalb nur EINER Methode einige identische Aufgaben klarer zu strukturieren dann ist die nested Funktion erstmalig die beste Wahl.
Übersichtlichkeit entsteht dann dadurch das sich der Programmierer IM Source auf lokal begrenzte Quellcode Zeilen beschränken kann. Er wird nun nachvollziehen woll was eine Procedure im einzelnen macht. Wird mit nested Funktionen gearbeitet so ist es ohne Probleme möglich sich auf Teillösungen von Teilproblemen zu konzentieren. Sind diese verstanden geht der Programmierer strukturell in seine Analyse exakt eine Ebene höher in der Verschachtelung der nested Funktionen. Somit ZWINGEN nested Funktion, so wie die Objekte, die Units usw. dem Programmierer eine strukturelle Sichweise des Problemes auf. DIES nenne ich eben PASCAL !! statt C, BASIC usw.

Zitat:

Zitat:

Worin besteht für dich der Unterschied zwischen kleinen und großen Projekten, in Bezug auf die Regeln der Modularisierung der Sourcen ??

Wenn ich schnell mal ein Programm brauche um.... keine Ahnung... in einem Text alle "Vitus" in "Sutiv" zu verwandeln, dann ist mir der Stil ziemlich wurscht. Das Programm brauche ich einmal und danach kommt es in die Tonne. Das wäre ein kleines Projekt. Gut - in diesem Fall braucht keiner eine solch eingebettete Funktion, aber Du weißt schon was ich meine

Siehst du, und ich mache bei KEINEM Source einen Unterschied in MEINEM Stil, WARUM auch ??
Denn statt mir einen schlechten Stil für kleine Projekte und einen guten Stil für große Projekte anzueigenen, arbeite ich bei JEDEM Projekt mit immer dem gleichem Still. Der Stil bestimmt also wie man ohne Probleme ein kleines Projekt exakt gleichgut warten, aufbauen und weitergeben kann, wie ein großes Projekt.


Gruß hagen

[Vitus]

püüüh nunja.. alles klar...

was aber kleine & große Projekte angeht:
Wann brauche ich jemals wieder einen Algorithmus der aus dem String "Vitus" "Sutiv" macht?!? Warum sollte ich in so einem Programm Zeilenlang Kommentare schreiben und ja auf Leerzeilen und Groß- Kleinschreibung achten, obwohl ich weiß dass es nach einer erfolgreichen Anwendung in der Versenkung verschwindet?!?

Sobald ich einen Code entwickel den ich später mal wieder gebrauchen kann, arbeite ich immer strukturiert...


Thema eingenistete Funktionen is für mich abgeschlossen, auch wenn ich Deine Meinung immer noch nicht teile *fg*
Ich bleib bei meinen Klassen, und arbeite, sobald es zuviele werden, einfach mit mehr units :mrgreen:

Gruß
Vitus

[neolithos]

Zitat:

Zitat von Vitus

was aber kleine & große Projekte angeht:
Wann brauche ich jemals wieder einen Algorithmus der aus dem String "Vitus" "Sutiv" macht?!? Warum...

Erstaunlicher weise meist schneller als einem Lieb ist! Jedenfalls ist es mir schon oft so gegangen. Deshalb bin ich froh das ich es genauso wie Hagen mache und jedes fast Project gleich behandle.

Große Projecte erhalten nur noch eine Txt-Abschnitt in dem Struktur und Konzepz erklärt, weil dies meist schlecht bei mehren 10000-ten von Code-Zeilen erkennbar ist.

Zitat:

Zitat von Vitus

Thema eingenistete Funktionen is für mich abgeschlossen, auch wenn ich Deine Meinung immer noch nicht teile *fg*
Ich bleib bei meinen Klassen, und arbeite, sobald es zuviele werden, einfach mit mehr units :mrgreen:

Gruß
Vitus

Du tust mir Leid.

Noch ein Beispiel für eine Sinnvolle Anw.

Delphi-Quellcode:

procedure T???.SortMyList;

  function AscSort(p1, p2 : PData)
  begin
    Result := CmpTxt(p1^.sName, p2^.sName);
  end;

  function DescSort(p1, p2 : PData)
  begin
    Result := not CmpTxt(p1^.sName, p2^.sName);
  end;

begin
  case fOrientation of
       orAsc: lstData.Sort(@AscSort);
       orDesc: lstData.Sort(@DescSort);  
  end;
end;

[negaH]

Die Programmier-Stil-Frage ist auch eine Frage nach der Disziplin des Programmierers. Damit meine ich nicht nur die Disziplin aus Prinzip, sowie ein Krümelkacker aus Trotz es immer gleich macht. Sondern eher die Erkenntnis das der Source eines Programmierers SEINE Disziplin erkennenlässt die er dazu benutzt um sein DENKEN als Arbeit zu organisieren. Programmieren ist eine Arbeit des Hirnes, das Denken. Ein guter und sauberer Programierstil erleichtert also das Denken, eg. die Arbeit des Programmierers.

Deshalb ist die Frage nach dem besten Programmierstil eine sehr wichtige Frage für uns alle.
Nun, jeder strukturierte Programmierstil ist somit die objektive Wirkung der rein subjektiven Arbeit. Über die Analyse eines Programierstil kann man demzufolge auch die subjektive Qualität der Arbeit des Programmieres objektiv einschätzen.

D.h. ein guter Programierstil kann nur dadurch entstehen das sich der Programmierer seines DENK-Prozesses als Arbeit BEWUSST ist. Über den Stil versucht er eine objektive Lösung zu finden darüber nachzudenken wie er demnächst effektiver Denken kann.

Hört sich vielleicht ein bischen abgehoben und kompliziert an, aber wenn man mal darüber nachdenkt ist es absolut logisch.

Da sich am Anfang die meisten Programmierer nur auf die Problemlösung konzentieren, also die Erzeugung eines Programmcodes der ein Problem lösst, wird der wichtige Punkt WIE man seine DENK Arbeit am besten PLANT übersehen.
Erst mit längerer Erfahrung wird ein Programmierer anfangen sich darüber Gedanken zu machen wie er überhaupt denken muß um ein Problem zu durchdenken. Ein gleichbleibender und logisch strukturierter Programierstil ist dafür Voraussetzung.

Demzufolge ist es einem solchen Programmierer egal WAS er für Probleme lösst, Hauptsache für ihn wird es WIE er ein Problem lösst.

Gruß Hagen