Programmierstil - Grundsatzfrage

[asc]

Gregor schrieb:

Das Betonen des selbsterklaerenden Codes, der keine Kommentare benoetigt ist aus meiner Sicht eine unendlich arrogante Einstellung eines Programmierneulings, der noch nie mit Code einer anderen Person umgehen musste.

Ich glaube nicht das ich mit 15 Jahren Berufserfahrung ein Neuling bin, glaube aber durchaus das man selbsterklärenden Code schreiben kann. Ausnahmen hierzu sind komplexe Algorithmen oder stark optimierter Code.

[NaAHörMal]

Vergiss die Suche hier über das Programmierforum.

Die Leute hier arbeiten alle und es gibt keine (~) Freelancer, die mitlesen.
Begib dich auf eine etablierte, dafür gedachte Plattform, wenn du tatsächlich einen suchen musst (XING beispielsweise).

Ansonsten schau wer die menschlich besser gefällt und nimm ihn einfach. Wenn beide entsprechend Berufserfahrung haben, dann werden sie wohl schon in der Lage sein, akzeptablen Code zu produzieren.

[Ohne Xing erfolgreich]

NaAHörMal schrieb:

Vergiss die Suche hier über das Programmierforum.

Die Leute hier arbeiten alle und es gibt keine (~) Freelancer, die mitlesen.
Begib dich auf eine etablierte, dafür gedachte Plattform, wenn du tatsächlich einen suchen musst (XING beispielsweise).

Du meinst, wer heute bei XING nicht ist, hat kein Recht nen Auftrag zu bekommen?
Tolle Wurst, sicher muss, wenn es nach dir geht jeder auch einen Account bei Facebook, Google und Twitter haben.

@Guest99

Wer von den beiden hat denn die Funktionen mit Vor- und Nachbedingungen versehen?

Wenn wir schon bei folgenden Themen sind:

- Fehlersicherheit
- Wiederverwendbarkeit
- Leichte Einarbeitung späterer fremder Programmierer

Dann gehören diese Angaben nämlich an die Funktionsköpfe.

[TyRoXx]

NaAHörMal schrieb:

Ansonsten schau wer die menschlich besser gefällt und nimm ihn einfach. Wenn beide entsprechend Berufserfahrung haben, dann werden sie wohl schon in der Lage sein, akzeptablen Code zu produzieren.

Das hängt von der Definition von akzeptabel ab. Die Fähigkeiten eines Programmierers korrelieren eher schwach mit der Berufsdauer in Jahren. Erfahrung ist noch einmal ein ganz anderes Thema.

Der Code selbst ist nicht das einzige Qualitätskriterium. Je mehr unterspezifierte, halbgare Protokolle für das Projekt erfunden worden sind, desto schwerer ist das ganze zu verstehen. Je mehr unnötige Annahmen gemacht worden sind, desto unportabler wird es. Man kann am Code auch nicht erkennen, was getestet wurde oder ob die Vorgaben überhaupt erfüllt sind.

Wenn das Projekt so unwichtig ist, dass man von vornheren plant es mittendrin an den billigsten Stundenten weiterzureichen, sollte man es vielleicht sein lassen. Auf keinen Fall sollte ein nicht-Programmierer den zukünftigen Entwickler auswählen. Das geht zwangsläufig daneben, weil es ja nur um persönliche Sympathie gehen kann.

Wenn du dich mit einem Software-Entwickler unterhältst, arbeitet er immer mit den modernsten Konventionen, selbstverständlich ist die Testabdeckung perfekt und es entsteht laufend aktuelle Dokumentation, die der billigste Student im Schlaf verstehen kann. Tatsächlich programmiert der dann so, als wäre er die letzten 20 Jahren eingefroren gewesen, Tests wurden aus Zeitmangel weggelassen, "funktioniert aber alles", und die Dokumentation ist zum Teil 100% redundant (Code-Kommentare) oder besteht aus inkonsistenten, nicht mehr aktuellen und ungeordneten Halbsätzen.

[Gregor]

asc schrieb:

Gregor schrieb:

Das Betonen des selbsterklaerenden Codes, der keine Kommentare benoetigt ist aus meiner Sicht eine unendlich arrogante Einstellung eines Programmierneulings, der noch nie mit Code einer anderen Person umgehen musste.

Ich glaube nicht das ich mit 15 Jahren Berufserfahrung ein Neuling bin, glaube aber durchaus das man selbsterklärenden Code schreiben kann. Ausnahmen hierzu sind komplexe Algorithmen oder stark optimierter Code.

Ok, es gibt natuerlich jede Menge trivialen Code, den man sofort versteht. Aber man sollte sich auch immer bewusst sein, dass das "selbsterklaerend" eben sehr subjektiv ist. Man selbst versteht, was man gerade macht. Was ein anderer versteht, haengt davon ab, ob er die gleichen Assoziationen wie man selbst hat. ...und vielleicht hat man in ein paar Jahren auch ganz andere Assoziationen. Jenseits davon muessen bestimmte Dokumentationen oder Kommentare trotzdem rein: Moegliche Wertebereiche von Parametern, Ausnahmefaelle, manchmal muss auch ein noch so aussagekraeftiger Variablenname genauer erlaetert werden und so weiter.

Die Aussage, dass der eigene Code selbsterklaerend sei zieht aus meiner Sicht nicht als generelles Argument, warum man nichts kommentiert.

Wenn es sich um rein trivialen Code handelt, dann wuerde ich an Stelle des Threaderstellers einfach irgendeinen der beiden nehmen.

[asc]

Gregor schrieb:

Aber man sollte sich auch immer bewusst sein, dass das "selbsterklaerend" eben sehr subjektiv ist. Man selbst versteht, was man gerade macht. Was ein anderer versteht, haengt davon ab, ob er die gleichen Assoziationen wie man selbst hat.

Stimmt, aber dies führt auch zu recht peinlichen Situationen. So wollte mein aktueller Chef schon mehrmals das ich verwendete STL-Funktionen kommentiere, was ich wiederum Ablehne mit der Begründung das es genau dafür Referenzen gibt.

Die Probleme sind auch nicht mit einer seperaten Dokumentation zwangsweise besser, weil auch die lässt sich anders interpretieren als sie ursprünglich gedacht war.

Aber einmal das andere Extrem: Ich habe in meiner letzten Firma auch nicht jede Funktion beschrieben, und bekam dafür einen Rüffel vom Programmiervorgesetzten. Dann druckte ich den Altcode und meine Überarbeitung aus, ging zum Chef und wollte von diesem (der kein Programmierer ist) wissen, ob er meinen Code lesen konnte. Dieser wollte zuerst abblocken, lies sich dann (etwas genervt) darauf ein und staunte danach nicht schlecht das er als Außenstehender den Ablauf in Grundzügen verstanden hatte - was ihm wiederum mit dem Altcode nicht gelang.

Führte übrigend dazu das man mich weitermachen lies (ich kommentiere, aber halt wesentlich seltener - Ausnahme bei mir ist im aktuellen Code der Header, weil wir hier mit Doxygen arbeiten (Da versuche ich wenigstend zu jeder Funktion einen kurzen Satz zu schreiben und die Parameter kurz zu erklären - auch wenn das bei Vielen unnötig ist; Hier geht es aber um die extrahierte Dokumentation).

Gregor schrieb:

Die Aussage, dass der eigene Code selbsterklaerend sei zieht aus meiner Sicht nicht als generelles Argument, warum man nichts kommentiert.

Das nicht, aber es gibt tatsächlich Code der so gut (oder teilweise weitaus besser wenn ich mir teile der Dokumentation ansehe, deren Kommentare aus Erfahrung nur selten aktualisiert werden) ist das man es nicht braucht. Und das gilt nicht nur für trivialen Code, man kann teilweise auch komplexen Code selbsterklärend schreiben.

Und ich halte selbstdokumentieren Code immer noch für besser als eine Dokumentation die nur rudimentär gepflegt wird. Ich habe noch kein Projekt erlebt, egal bei welchen Arbeitgeber, wo die Dokumentation immer den aktuellen Stand entsprach. Das kann schlimmer als garkeine Dokumentation sein.

[NaHörMal]

Ohne Xing erfolgreich schrieb:

Du meinst, wer heute bei XING nicht ist, hat kein Recht nen Auftrag zu bekommen?
Tolle Wurst, sicher muss, wenn es nach dir geht jeder auch einen Account bei Facebook, Google und Twitter haben.

Was ist denn das für eine lächerliche Steigerung der Tatsache, dass ich XING als ein Beispiel für eine Plattform, auf der er sich nach Programmieren umsehen könnte, genannt habe?!

Das Internet ist offensichtlich ein in Frage kommender Ort für ihn und da sind Plattformen wie XING nun mal beliebt und auch effizient.
Dass er hier im Forum tausend mal schlechtere Chancen hat jemanden zu finden kann wohl kaum jemand leugnen.

@Thematik
Da kommen einfach etliche Faktoren mit rein, die uns unbekannt sind. Wenn dem TE die Programmierer spontan nicht gefallen (was leicht so rüberkommt, durch die Art und Weise wie sie uns hier beschrieben werden), dann sollte er sich anderweitig umschauen.

Aber ich denke, wer dafür verantwortlich ist, Programmierer für Projekte einzustellen, sollte schon auch gewisse Methoden haben, um dabei zu einem sinnvollen Ergebnis zu kommen.

Die ursprüngliche Frage ist ja beantwortet, viel Erfolg

[NaHörMal]

Der hier sollte es eigentlich werden :

[hustbaer]

Ich bin grundsätzlich ganz klar für "kleine Funktionen".
Dass dabei gar nicht dokumentiert wird ist vermutlich schlecht, weil es die Einarbeitungszeit natürlich deutlich erhöht.

Grosse Funktionen sind für mich ein absolutes no-go. (Grosse Klassen ebenso.)

Was OK ist, ist das öffentliche Interface schlank zu halten. Also dass ein Modul jeweils nur wenige Funktionen anbietet die dann im restlichen Programm verwendet werden dürfen. Wenn ein Modul z.B. den Download von Files über HTTP implementieren soll, dann ist es nicht nötig (bzw. schadet es sogar) wenn es gleichzeitig noch alle kleinen Hilfsfunktionen öffentlich macht die dazu nötig sind.

Das lässt sich aber auch alles ohne riesige Funktionsmonster machen. Dazu gibt's ja die Möglichkeit Funktionen lokal zu definieren, anonyme Namespaces bzw. auch Detail Namespaces.

Aber ich drifte in Bereiche ab die mit der Fragestellung nix mehr zu tun haben.

So ohne weitere Informationen würde ich den "kleine Funktionen" Programmierer vorziehen. Obwohl das natürlich auch nur ein Schuss ins Blaue ist, ohne Beispielcode von den beiden Kandidaten zu sehen würde ich das nicht entscheiden wollen.

[Jockelx]

asc schrieb:

Gregor schrieb:

Das Betonen des selbsterklaerenden Codes, der keine Kommentare benoetigt ist aus meiner Sicht eine unendlich arrogante Einstellung eines Programmierneulings, der noch nie mit Code einer anderen Person umgehen musste.

Ich glaube nicht das ich mit 15 Jahren Berufserfahrung ein Neuling bin, glaube aber durchaus das man selbsterklärenden Code schreiben kann. Ausnahmen hierzu sind komplexe Algorithmen oder stark optimierter Code.

Deckt sich absolut mit meiner Erfahrung.
Vielleicht hast auch du, Gregor, auch nicht sooo viel Erfahrung, dass du dich durch Code mit Kommentaren wie

//Dies ist der Konstruktor der Klasse Blah. Er erzeugt ein Blah Objekt
  Blah();
  // Oder
  // Diese Schleife zählt von 0 bis 9
   for(int i= 0; i < 10; ++i)

durchwühlen musstest.
Das ist kein Scherz, sondern sind echte Beispiele.
In meinem momentanen Projekt fühle ich mich jedenfalls wohl, denn wenn da mal ein Kommentar steht, dann lese ich den auch, weil er auf irgendwas wichtiges oder unerwartetes aufmerksam macht.

[TyRoXx]

Es gibt da auch noch die redundanten "Dokumentations"-Kommentare, die sehr viele Entwickler ohne einen einzigen Gedanken produzieren.

////////////////////////////////////////////////////////////////////////
//class. A container
////////////////////////////////////////////////////////////////////////
class Container
{
public:

	////////////////////////////////////////////////////////////////////
	// constructor
	////////////////////////////////////////////////////////////////////
	Container()
	{
		//initialize children
		m_nChildren = 0;
	}

	////////////////////////////////////////////////////////////////////
	// destructor
	////////////////////////////////////////////////////////////////////
	~Container()
	{
		//set children to zero
		m_nChildren = 0;
	}

	////////////////////////////////////////////////////////////////////
	// Returns the children of the class.
	////////////////////////////////////////////////////////////////////
	int GetChildren() const
	{
		return m_nChildren;
	}

	////////////////////////////////////////////////////////////////////
	// Updates the children interaction mappings.
	// returns: void
	////////////////////////////////////////////////////////////////////
	void UpdateChildrenInteractionMappings();

private:

	int m_nChildren; //children
};

[asc]

Jockelx schrieb:

In meinem momentanen Projekt fühle ich mich jedenfalls wohl, denn wenn da mal ein Kommentar steht, dann lese ich den auch, weil er auf irgendwas wichtiges oder unerwartetes aufmerksam macht.

Das halte ich auch für sinnvoll. Dokumentation dort wo es wirklich nötig ist.
Problem ist nur das unterschiedliche Personen unterschiedliche Sachen für dokumentationswürdig halten. Das was Person a nicht versteht, versteht wiederum Person b und fast sich an den Kopf warum dies kommentiert sein muss...

[Mechanics]

GUEST99 schrieb:

Einer hat als Programmierstil Funktionserlegung, d.h. eine Hauptfunktion besteht aus x Unterfunktionen, im Sourcecode gibt es keine Dokumentation, weil die kleinen Unterfunktionen - die auch in anderen Hauptfunktionen mit verwendet werden können - und Variablen alle selbsterklärend seien.

Der andere Kandidat hat als Programmierstil Black Box, d.h. eine Funktion mit möglichst wenig Unterfunktionen, wenn Unterfunktionen dann nur spezifisch für eine Hauptfunktion. Dokumentation inline, incl. Angabe der Parameterbereiche, Erklärung von Teilen der Funktion (was z.B. in einer Case alles abgefragt wird).

Woher weißt du das? Das irritiert mich bei den ganzen Antworten hier. Du kannst doch gar nicht wissen, was für einen Stil jemand hat. Ich könnte so spontan gar nicht sagen, was für einen Stil ich selber habe. Man findet sicherlich Programmteile von mir, die völlig unterschiedlich ausschauen. Mal mit mehr, mal mit weniger Kommentaren. Und wenn du mich darauf ansprichst, warum ich etwas so und so geschrieben habe, würde ich wahrscheinlich auch sagen, weil das schon gut ist so. Ich könnte mir aber auch sicherlich auch dutzende Lösungen vorstellen, die mir evtl. auch gut gefallen würden. Ich finde, Softwareentwicklung ist viel zu komplex, als dass man sich eindeutig auf einen Stil festlegen lassen könnte.

[Ohne Xing erfolgreich]

Jockelx schrieb:

asc schrieb:

Gregor schrieb:

Das Betonen des selbsterklaerenden Codes, der keine Kommentare benoetigt ist aus meiner Sicht eine unendlich arrogante Einstellung eines Programmierneulings, der noch nie mit Code einer anderen Person umgehen musste.

...

Deckt sich absolut mit meiner Erfahrung.
Vielleicht hast auch du, Gregor, auch nicht sooo viel Erfahrung, dass du dich durch Code mit Kommentaren wie

//Dies ist der Konstruktor der Klasse Blah. Er erzeugt ein Blah Objekt
  Blah();
  // Oder
  // Diese Schleife zählt von 0 bis 9
   for(int i= 0; i < 10; ++i)

durchwühlen musstest.
Das ist kein Scherz, sondern sind echte Beispiele.

Das ist kein Beispiel, das sind nicht einmal sinnvolle Kommentare.
Code Kommentieren bedeutet nicht, die Programmiersprache zu erklären.

[Gregor]

Jockelx schrieb:

Vielleicht hast auch du, Gregor, auch nicht sooo viel Erfahrung, dass du dich durch Code mit Kommentaren wie

//Dies ist der Konstruktor der Klasse Blah. Er erzeugt ein Blah Objekt
  Blah();
  // Oder
  // Diese Schleife zählt von 0 bis 9
   for(int i= 0; i < 10; ++i)

durchwühlen musstest.
Das ist kein Scherz, sondern sind echte Beispiele.

Ok, ich gehe natürlich davon aus, dass sinnvoll kommentiert und dokumentiert wird, wenn es gemacht wird. Ich stelle nicht in Frage, dass man Kommentare falsch nutzen kann.

Ich hatte in den letzten Jahren mit einem Code zu tun, in dem jede Menge numerische Algorithmen realisiert sind. Ich bin da über jedes kleine bisschen Kommentar glücklich. Aber das ist vielleicht ein Extremfall.

[SeppJ]

Selbstsprechender Code: Der Code erklärt selbst, was er macht.
Nützlicher Kommentar: Er erklärt, wieso etwas gemacht wird.

[Ohne Xing erfolgreich]

SeppJ schrieb:

Selbstsprechender Code: Der Code erklärt selbst, was er macht.
Nützlicher Kommentar: Er erklärt, wieso etwas gemacht wird.

Nicht ganz.

Wenn es Zeit kostet, den Code zu lesen, damit man versteht, was er macht, dann sollte man schon in nem kurzen Satz sagen, was er macht.

Oder anders gesagt, meine Definition:

Kommentare sollen nicht die Programmiersprache erklären.

Damit ist der Redunante überflüssige Müll weg und übrig bleiben die wichtigen Häppchen.

[volkard]

Ohne Xing erfolgreich schrieb:

SeppJ schrieb:

Selbstsprechender Code: Der Code erklärt selbst, was er macht.
Nützlicher Kommentar: Er erklärt, wieso etwas gemacht wird.

Nicht ganz.

Wenn es Zeit kostet, den Code zu lesen, damit man versteht, was er macht, dann sollte man schon in nem kurzen Satz sagen, was er macht.

Oder hübscher pr0ggern, das geht meistens.

[SeppJ]

Ohne Xing erfolgreich schrieb:

SeppJ schrieb:

Selbstsprechender Code: Der Code erklärt selbst, was er macht.
Nützlicher Kommentar: Er erklärt, wieso etwas gemacht wird.

Nicht ganz.

Wenn es Zeit kostet, den Code zu lesen, damit man versteht, was er macht, dann sollte man schon in nem kurzen Satz sagen, was er macht.

Ich meinte das in Anlehnung an die Diskussion selbstsprechender Code vs. Kommentare. Nicht jeder Code ist automatisch selbsterklärend. Aber es gibt in den modernen Sprachen keine Ausrede mehr, nicht das Idealbild des selbsterklärenden Codes anzustreben. Es ist nicht schwer. Wenn man es nicht schafft, dann programmiert man nicht gut genug.

[hustbaer]

SeppJ schrieb:

Aber es gibt in den modernen Sprachen keine Ausrede mehr, nicht das Idealbild des selbsterklärenden Codes anzustreben. Es ist nicht schwer. Wenn man es nicht schafft, dann programmiert man nicht gut genug.

Doch, leider gibt es eine Ausrede: man muss wissen wie man das macht, worauf man acht geben muss etc. Und leider bringt das den Schülern/Studenten keiner bei. Vermutlich weil viele Lektoren/Dozenten/... selbst nicht sauber programmieren können.

Bzw. vielleicht auch weil das alles sehr subjektiv ist, und daher schwer zu benoten.