Programmierstil - Grundsatzfrage



  • Hallo,

    ich hätte da mal eine Grundsatzfrage zum Programmierstil für C++ und C#. Selbst programmiere ich nicht, ich habe eigentlich mit den Kunden zu tun und gebe die Anforderungen an das Backoffice weiter. Da mein Kollege hier jedoch länger krank ist, darf ich das jetzt auch noch übernehmen und muss geeignete Programmierer raussuchen...

    Wir haben da einen Programmierauftrag zu vergeben und zwei mögliche Kandidaten.

    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).

    Problem: Beide sagen von sich, ihr Programmierstil sei handwerklicher Standard und alles andere nicht mehr Zeitgemäß.

    Da wir den Sourcecode behalten und ggf. irgendwann mal ein anderer Programmierer sich neu einarbeiten soll, was ist jetzt wirklich zeitgemässer Programmierstil? Was ist zum einarbeiten für einen Programmierer einfacher? Ein Sourceode mit vielen Funktionen und Unterfunktionen oder ein Sourcecode mit wenig Funktionen, die überwiegend einen kompletten Funktionsablauf haben.

    Was wäre eher an MISRA-C Anforderung angelehnt?

    Nebenbei, kann man über das Forum auch Programmierer suchen? 😉

    Danke im voraus.

    P.S.
    Das Programm umfasst Netzwerkkommunikation, SQL Datenbehandlung, Schnittstellenprogrammierung, Verschlüsselung, Graphische Benutzeroberfläche mit dynamischen Elementen.



  • Na ja, folgendes:

    1. Programmierer kann man im Unterforum Projekte suchen und finden.
    2. Funktionen sollten grundsätzlich übersichtlich mit eindeutiger Aufgabe sein.
    3. Grössere Aufgaben unterteilt man in sinnvolle Teilaufgaben, auch wenn sie nur einmal vorkommen.
    4. Was nicht selbsterklärend ist, sollte im Sourcecode dokumentiert sein.

    Wichtiger als die genannten zwei Programmierstile sind folgende Dinge:

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



  • GUEST99 schrieb:

    Da wir den Sourcecode behalten und ggf. irgendwann mal ein anderer Programmierer sich neu einarbeiten soll, was ist jetzt wirklich zeitgemässer Programmierstil? Was ist zum einarbeiten für einen Programmierer einfacher?

    Grundsätzlich bringen beide Codestile ihre Probleme mit sich, auch wenn ich tendenziell den ersten Entwickler vorziehen würde. Für die Wartung eines Programmes sind kleine Funktionen meist vorteilhafter, für die Einarbeitung nicht unbedingt (wobei zu große Funktionen kaum übersichtlich/verständlich sind).

    Als "moderner" würde ich aber den ersten Stil bezeichnen*. Sofern die Funktionen und Variablen wirklich selbsterklärend sind, kann tatsächlich auf eine Dokumentation verzichtet werden. Anders sieht es aber aus, wenn man eine Codedokumentation über Programme wie Doxygen aus dem Sourcecode extrahieren will.

    * Sofern man sich an das "Single responsibility principle" hält, werden Funktionen ohnehin selten groß.

    GUEST99 schrieb:

    Was wäre eher an MISRA-C Anforderung angelehnt?

    Keine Ahnung, C programmiere ich persönlich nicht, sondern C++ und C# (und da ist MISRA-C wohl eher nicht für sinnvoll anwendbar).



  • 1. Programmierer kann man im Unterforum Projekte suchen und finden.

    Danke für die Info.
    Wie lange muss man in der Regel auf Rückmeldungen warten?
    Ich müsste das Projekt spätestens am Freitag dem Kunden preislich anbieten und dann auch Zeitnah den Auftrag vergeben.

    2. Funktionen sollten grundsätzlich übersichtlich mit eindeutiger Aufgabe sein.
    3. Grössere Aufgaben unterteilt man in sinnvolle Teilaufgaben, auch wenn sie nur einmal vorkommen.

    Gibt es da eine Regel, ob man Unterfunktionen auch in weitere Unterfunktionen aufteilt? In den Unterlagen meines Kollegen habe ich gelesen, dass teilweise 5 Unterfunktionsebenen vorhanden sind.

    4. Was nicht selbsterklärend ist, sollte im Sourcecode dokumentiert sein.

    Ist auch die Meinung von einem der beiden Kandidaten. Der andere meint, Kommentare stören nur und wären ein Zeichen schlechter Programmierarbeit.

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

    Was ist hier besser? Sind Unterfunktionen von Unterfunktionen etc. Fehlersicherer oder nicht?
    Kann man sich in so eine Struktur besser einarbeiten als in Blackboxen, die Funktionszusammenhänge abbilden?

    Ich kenne das halt aus der Consultingseite und bin jetzt in der Situation, einen von beiden Programmierern raussuchen zu müssen.



  • GUEST99 schrieb:

    2. Funktionen sollten grundsätzlich übersichtlich mit eindeutiger Aufgabe sein.
    3. Grössere Aufgaben unterteilt man in sinnvolle Teilaufgaben, auch wenn sie nur einmal vorkommen.

    Gibt es da eine Regel, ob man Unterfunktionen auch in weitere Unterfunktionen aufteilt? In den Unterlagen meines Kollegen habe ich gelesen, dass teilweise 5 Unterfunktionsebenen vorhanden sind.

    Es gibt viele Entwicklerprinzipien, die sich teilweise auch widersprechen. Bei "agiler" Softwareentwicklung wirst du eher Verfechter sehr kleiner Funktionen finden (Bei traditionelleren Entwicklungsformen wiederum eher weniger), die für sich genommen leichter zu verstehen und zu warten sind. Aber gleichzeitig kann es aufwendiger sein das Gesamtprogramm zu verstehen (Üblicherweise arbeitet man nach meiner Erfahrung aber weit eher auf Modulebene, weniger auf Programmebene). Falls mit automatischen Softwaretests gearbeitet wird, empfehlen sich ebenso kleine Funktionen/Module.

    4. Was nicht selbsterklärend ist, sollte im Sourcecode dokumentiert sein.

    Ist auch die Meinung von einem der beiden Kandidaten. Der andere meint, Kommentare stören nur und wären ein Zeichen schlechter Programmierarbeit.

    Ich habe in mehreren Projekten festgestellt, das Dokumentation im Code gerne mal "altert" und nicht den aktuellen Stand wiederspiegelt. Sofern sie innerhalb der Funktionen sind, stören sie auch den Lesefluss (Weniger Probleme habe ich mit Dokumentation im Kopf, bzw. bei C und C++ noch besser im Header).

    Was ist hier besser? Sind Unterfunktionen von Unterfunktionen etc. Fehlersicherer oder nicht?
    Kann man sich in so eine Struktur besser einarbeiten als in Blackboxen, die Funktionszusammenhänge abbilden?

    Für den schnellen Überblick: Tendenziell Blackbox (Sofern "noch" übersichtlich)
    Für die Wartung/Erweiterung/Korrektur: Tendenziell untergliederter Code



  • Hallo asc:
    Danke für die Informationen.

    Ich hoffe, ich interpretiere es richtig:
    Letztendlich haben beide Programmierarten ihre Berechtigung und es gibt keine Patentlösung bzw. "die" richtige Programmierart.

    Es kommt eher darauf an, was der Programmierer bevorzugt, wie die Anforderungen gestellt werden, uws.

    Ich sehe, da habe ich noch viel Arbeit, bei der Selektion, welcher von beiden den Auftrag bekommt.



  • GUEST99 schrieb:

    Beide sagen von sich, ihr Programmierstil sei handwerklicher Standard und alles andere nicht mehr Zeitgemäß.

    Bei derart ausgeprägten Scheuklappen würde ich keinen von beiden beauftragen.



  • Fuer mich hoert sich das so an, als ob beide Programmierer mit ihrer jeweiligen Ideologie ins Extreme gehen.

    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.

    Auf der anderen Seite ist eine hierarchische Aufteilung von Code in Methoden und Untermethoden ein wichtiges handwerkliches Mittel, um die Komplexitaet eines Programmabschnitts beherrschen zu koennen. Wenn man so etwas voellig vernachlaessigt, dann spricht das auch nicht fuer den Programmierer. Andererseits kann man die Hierarchisierung auch uebertreiben.

    Ohne den Code gesehen zu haben kann man sich da keine fundierte Meinung bilden. Aber die Beschreibung hoert sich aus meiner Sicht nach solchen Extremfaellen an.



  • Bei derart ausgeprägten Scheuklappen würde ich keinen von beiden beauftragen.

    Hmm, das gibt mir zu denken.

    Fuer mich hoert sich das so an, als ob beide Programmierer mit ihrer jeweiligen Ideologie ins Extreme gehen.

    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.

    Auf der anderen Seite ist eine hierarchische Aufteilung von Code in Methoden und Untermethoden ein wichtiges handwerkliches Mittel, um die Komplexitaet eines Programmabschnitts beherrschen zu koennen. Wenn man so etwas voellig vernachlaessigt, dann spricht das auch nicht fuer den Programmierer. Andererseits kann man die Hierarchisierung auch uebertreiben.

    Ohne den Code gesehen zu haben kann man sich da keine fundierte Meinung machen. Aber die Beschreibung hoert sich aus meiner Sicht nach solchen Extremfaellen an.

    Autsch. Ich glaube, ich muss mit dem Kunden wegen Fristverlängerung reden.
    Wenn der Kunde zustimmt, setze ich die Anforderungen hier hinein und suche nach einem Programmierer hierrüber.

    Wie ist das hier mit der Suche? Überwiegend Freelancer oder auch Programmierfirmen mit mehereren Mitarbeitern die sich hier ggf. melden?



  • 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.



  • 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.



  • 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.



  • 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.



  • 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.



  • 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.



  • 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 😋



  • Der hier sollte es eigentlich werden : 🙂



  • 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.



  • 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.



  • 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
    };
    

Log in to reply