qualitativ hochwertiger Programmcode...

[shoat]

volkard schrieb:

shoat schrieb:

Wenn jemand allerdings zum Manövrieren eines Cursors über den Bildschirm

void Mobile::go (int richtung)
{
    int rx=richtung%3-1; 
    int ry=richting/3-1; 
    x+=rx; 
    y+=ry;
}

verwendet. Dann wäre es doch schon recht schön, wenn er mir einen kurzen Tip geben würde, was es eigentlich zu bedeuten hat.

ja. der schwere fehler,

void Mobile::go(int richtung)

zu schreiben, verzerrt die angelegenheit. in dieser verzerrten lage isses natürlich gut, die schnittstelle zu kommentieren.
aber das ist jetzt ein wenig wie wenn man beweist, daß goto gut ist, solange man keine destruktoren verwendet.

... Du bist ja auf meine Argumentation gar nicht eingegangen ...
Schade, ich hatte ursprünglich gedacht, Du wolltest mir helfen.

[shoat]

Hallo Leute,

nachdem wir das Thema der Kommentare recht ausführlich behandelt haben, wäre es schön, wenn wir jetzt auch die meinen anderen Fragen behandeln könnten! Vor etwa vier Seiten habe ich gefragt:
**
Was stellt ihr persönlich sicher, dass Euer Code
- gut kommentiert/dokumentiert ist?
- gut wartbar ist?
- (möglichst) fehlerfrei ist?
- eine gute Performance besitzt?
- plattformunabhängig bzw. leicht portabel ist?
- (wenigstens teilweise) wiederverbar ist?**

Für neue Ideen in all diesem Bereich wäre ich sehr dankbar! Insbesondere zu den letzten drei Punkten habe ich noch kaum Antworten bekommen! Wäre also sehr schön, wenn ihr mir da ein wenig unter die Arme greifen könntet!

Vielen Dank für die Hilfe!

Ciao
shoat

[Marc++us]

shoat schrieb:

... Du bist ja auf meine Argumentation gar nicht eingegangen ...
Schade, ich hatte ursprünglich gedacht, Du wolltest mir helfen.

Pfüüüüü.... halt mal den Ball flach.

Vielleicht war er auch der Ansicht, es wäre offensichtlich.

shoat schrieb:

... Du bist ja auf meine Argumentation gar nicht eingegangen ...

Wenn Du als Richtung einfach einen int-Parameter reinwirfst, ohne Kommentar, dann ist klar daß der Code mit dem Modulo(3) unverständlich ist.

Denn korrekt wäre es hier gewesen eine Legende für den int-Parameter zu machen, sowas in der Art:

/*richtungen   7 8 9 
               4 5 6 
               1 2 3 
*/

Denn damit kann man die Berechnung verstehen, die 3 vom Modulo ergibt auf einmal ("aha, ein 3er-Block mit Richtungen") Sinn.

Oder man macht's mit einem Enum.

Und man gibt der Funktion noch den Namen "followCompassDirection" (oder sowas in der Art).

Aber go(int) ist halt recht wenig.

[Marc++us]

shoat schrieb:

Was stellt ihr persönlich sicher, dass Euer Code
- gut kommentiert/dokumentiert ist?
- gut wartbar ist?
- (möglichst) fehlerfrei ist?
- eine gute Performance besitzt?
- plattformunabhängig bzw. leicht portabel ist?
- (wenigstens teilweise) wiederverbar ist?

Für neue Ideen in all diesem Bereich wäre ich sehr dankbar! Insbesondere zu den letzten drei Punkten habe ich noch kaum Antworten bekommen! Wäre also sehr schön, wenn ihr mir da ein wenig unter die Arme greifen könntet!

Eigentlich dachte ich, wir sprechen von diesem Thema... das steht doch alles da. Bisher war es eine interessante und lehrreiche Diskussion, der aufmerksame Zuhörer konnte einiges mitnehmen. Nun gut.

- Kommentiert/Doku: hat die Diskussion ergeben, die Masse der Leute steht er auf eindeutige Namen für Klassen, Objekte und Variablen statt Kommentaren. Für die Struktur der Klassen ist teilweise ein UML-Klassendiagramm hilfreich.
- wartbar: schlankes Design, nur genau das machen was man soll, das eigentliche Problem lösen
- fehlerfrei: schlankes Design, automatische Tests, Assertions bzw. allgemein Bereichsüberprüfungen
- Performance: erst Mal muß es laufen... optimiert wird danach, d.h. Rapid Prototypen in einigen Bereichen, Profiling, danach Optimierung kritischer Zeitfresser. Und: schlankes Design, da solche Programme oftmals effizienter sind.
- Plattformunabhängig wird in der Praxis massiv überbewertet und ist oftmals vernachlässigbar. Berücksichtigt man bei seinen Applikationen das MVC-Modell, kann man die Klassen in OS-abhängige Teile (GUI, Viewer) und Modell (ISO-C++) trennen, damit hat man ein portables funktionierendes Modell
- wiederverwendbar: wie immer: schlankes Design, das genau das macht was das Programm aus der realen Welt abbilden soll. Während der Entwicklung reduziert man dadurch Dinge auf das wesentliche, Erweiterungen können sich dann später abstützen. Ansonsten habe ich ja einen ganzen Sermon dazu geschrieben, ich verstehe nicht wieso Du denkst daß es dazu noch keine Punkte gibt.

[DStefan]

shoat schrieb:

Allerdings bleibe ich dabei, dass man die externen Schnittstellen erschöpfend beschreiben muss. D. h. die Dokumentation muss einem alles sagen, was man benötigt, um die Funktion bzw. Klasse korrekt nutzen kann. Es ist schließlich so, dass man bei einigen Libs keine Möglichkeit hat den Quellcode (abgesehen von den Prototypen natürlich) einzusehen. (Wohl aber die aus den Kommentaren entstehene Dokumentation!)

Jo! Genau! Da habe ich im Prinzip ja auch gar nichts gegen. Bloß eine Kleinigkeit fehlt bei deiner Forderung, und die ist halt schon ziemlich wichtig:

[...]die Dokumentation muss einem qualifizierten Entwickler alles sagen, was [er] über die Deklaration hinaus benötigt, um die Funktion bzw. Klasse korrekt [zu] nutzen[...]

So weit sind wir gar nicht (mehr) auseinander. Jetzt fordere noch, daß alle Namen "sprechend" sein sollen: Bingo!!!

volkard schrieb:

ich warte auf die metrikenbefürworter. immerhin werden die ja eingesetzt. immerhin lernt man an hochschulen, wie toll die sind.

Tja, ich schätze, da kannst du lange warten. Sie sind alles andere als toll. Und mal im Ernst: Mag sein, daß man an den Hochschulen was von Informatik versteht, aber von Software-Entwicklung?!!!

Zu "Wie stellt ihr sicher....":
Ich glaube, es zeichnet sich langsam(?) ab, daß es der Entwicklungs-Prozeß also solcher ist, der bei den meisten relevanten Punkten für gute Software sorgt. Keine Tools, keine Metriken, keine Threorien usw., sondern die Art und Weise, wie ein Team organisiert ist und geführt wird, und wie innerhalb des Teams kommuniziert wird. Vielleicht auch, wie man Ziele formuliert bzw. welche Ziele man sich setzt. Ein pragmatischer Prozeß ist ein guter Prozeß, also ein Prozeß, der sein Hauptgewicht darauf legt, qualitativ guten Code herzustellen. Punkt! Das scheint mir auch in Marcus' Aussagen (z.B. zur Gewichtung von Wiederverwendbarkeit) rüberzukommen.

Stefan.

[shoat]

Marc++us schrieb:

Pfüüüüü.... halt mal den Ball flach.
Vielleicht war er auch der Ansicht, es wäre offensichtlich.

Ich wollte niemanden auf den Schlips treten, wenn er mich aber zitiert und dann von irgendetwas ganz anderen erzählt, dann finde ich es doch ziemlich seltsam. Aber wahrscheinlich habe ich ihn nur wieder mißverstanden...

Marc++us schrieb:

Wenn Du als Richtung einfach einen int-Parameter reinwirfst, ohne Kommentar, dann ist klar daß der Code mit dem Modulo(3) unverständlich ist.

Denn korrekt wäre es hier gewesen eine Legende für den int-Parameter zu machen ...

Genau dass erzähle ich auch die ganze Zeit!

Viele Grüße!

Ciao
shoat

[shoat]

Marc++us schrieb:

Bisher war es eine interessante und lehrreiche Diskussion, der aufmerksame Zuhörer konnte einiges mitnehmen.

Ich kann Dir nur zustimmen. Ich persönlich habe schon sehr viel gelernt. Insbesondere auch durch volkards und Deine Beiträge.

Marc++us schrieb:

Eigentlich dachte ich, wir sprechen von diesem Thema... das steht doch alles da.

Es stand eben nicht alles da! Über einige Themen, wie z. B. Performance, wurde noch nichts oder noch nicht viel gesagt. Deswegen habe ich die Fragen erneut gestellt um auch dazu (mehr) Feedback zu erhalten und nicht nur noch über Kommentare zu reden. Deine letzte Antwort zu alle diesen Punkte hat wieder einige ganz neue Sachen enthalten, über die ich nachdenken und googeln werde. Danke dafür!

Ciao
shoat

[shoat]

DStefan schrieb:

Jo! Genau! Da habe ich im Prinzip ja auch gar nichts gegen. Bloß eine Kleinigkeit fehlt bei deiner Forderung, und die ist halt schon ziemlich wichtig:

[...]die Dokumentation muss einem qualifizierten Entwickler alles sagen, was [er] über die Deklaration hinaus benötigt, um die Funktion bzw. Klasse korrekt [zu] nutzen[...]

Ok. darauf kann man sich doch einigen! Allerdings ist dann doch noch zu definieren, was man unter einem qualifizierten Entwickler versteht.

Nehmen wir zum Beispiel das JDK. Damit muss jeder sich jeder Java-Entwickler (auch und v. a. die erst angehenden und wenig erfahrenen) auseinandersetzen. Wäre es nicht angemessen, dass die Schnittstellenbeschreibungen hier etwas ausführlicher gestaltet werden, da man davon ausgehen muss, dass auch viele Anfänger die verschiedenen Libs nutzen woll / müssen. Oder sollte man darauf bestehen, dass sie sich die ihnen fehlenden Informationen aus Büchern oder sonst wo zusammentragen?

Dies ist eine offene Frage. Ich habe dazu keine definitve Meinung. Vielleicht helft ihr mir eine eigene Meinung zu bilden!

DStefan schrieb:

So weit sind wir gar nicht (mehr) auseinander.

Ganz offentsichtlich meinen wir schon die ganze Zeit ziemlich das Selbe...

DStefan schrieb:

Jetzt fordere noch, daß alle Namen "sprechend" sein sollen: Bingo!!!

Damit hast Du sicher vollkommen recht! Dagegen hatte ich auch noch nie einen Einwand. Ganz im Gegenteil!

Vielen Dank!

Ciao
shoat

[Marc++us]

shoat schrieb:

Dies ist eine offene Frage. Ich habe dazu keine definitve Meinung. Vielleicht helft ihr mir eine eigene Meinung zu bilden!

Das ist ganz einfach: es gibt einen substantiellen Unterschied zwischen der Doku eines Frameworks oder eine API (wie hier dem JDK) und der Doku einer Applikation - hier gibt's ganz andere Zielgruppen, und auch andere Vorkenntnisse.

Bei einem Framework mußt Du quasi von einem vollkommenen Neuling ausgehen, der diese Funktion erstmalig benutzt und mit den internen Abläufen in keinster Weise vertraut ist. Vor allem kann man gar nicht wirklich hinter die Schnittstelle schauen, das ist eine reine Blackbox.

Bei einer Applikation ist der Kreis der Leser und Anwender einer Schnittstelle viel stärker eingegrenzt - man ist mit der Problemwelt eher vertraut, kennt die Begriffe, es gibt auch ein Wissen über die internen Abläufe im Team (soviele Leute werden im Team nie ausgewechselt).

Daher sieht die Doku in solchen Fällen ganz anders aus.

[shoat]

volkard schrieb:

ich warte auf die metrikenbefürworter. immerhin werden die ja eingesetzt. immerhin lernt man an hochschulen, wie toll die sind.

Ich habe an der (Fach-) Hochschule noch nie etwas zu Metriken gehört. Ok, irgendwann sollten wir in Software Engeneering mal ein Referat halten und da stand auch dieses Thema zur Auswahl. Allerdings hat es keiner ausgewählt, also wurde ich auch nicht damit behelligt. Dagegen hat uns der Prof. selbst schon etwas von XP und Prototyping erzählt.

Erst im Betrieb wurde ich dann mit dem Thema Metriken konfrontiert!

DStefan schrieb:

Und mal im Ernst: Mag sein, daß man an den Hochschulen was von Informatik versteht, aber von Software-Entwicklung?!!!

Natürlich gibt es solche und solche Professoren. Aber ich kann mich eigentlich nicht beschweren. Diejenigen, bei den ich Programmieren und Software-Engeenering hatte, waren davor selber Software-Entwickler (z. B. bei sd&m bzw. siemens). Ich weiß nicht recht, warum die keine Ahnung von Software-Entwicklung haben sollen?

Ok. Sie sind bestimmt nicht mehr ganz up2date, aber die Grundlagen sollten sie einem schon vermitteln können.

DStefan schrieb:

Zu "Wie stellt ihr sicher....":
Ich glaube, es zeichnet sich langsam(?) ab, daß es der Entwicklungs-Prozeß also solcher ist, der bei den meisten relevanten Punkten für gute Software sorgt. Keine Tools, keine Metriken, keine Threorien usw., sondern die Art und Weise, wie ein Team organisiert ist und geführt wird, und wie innerhalb des Teams kommuniziert wird. Vielleicht auch, wie man Ziele formuliert bzw. welche Ziele man sich setzt. Ein pragmatischer Prozeß ist ein guter Prozeß, also ein Prozeß, der sein Hauptgewicht darauf legt, qualitativ guten Code herzustellen. Punkt! Das scheint mir auch in Marcus' Aussagen (z.B. zur Gewichtung von Wiederverwendbarkeit) rüberzukommen.

Danke für diesen Beitrag! Ich werde Teile davon in meine Arbeit aufnehmen!

Ciao
shoat

[shoat]

Marc++us schrieb:

shoat schrieb:

Dies ist eine offene Frage. Ich habe dazu keine definitve Meinung. Vielleicht helft ihr mir eine eigene Meinung zu bilden!

Das ist ganz einfach: es gibt einen substantiellen Unterschied zwischen der Doku eines Frameworks oder eine API (wie hier dem JDK) und der Doku einer Applikation - hier gibt's ganz andere Zielgruppen, und auch andere Vorkenntnisse.

Bei einem Framework mußt Du quasi von einem vollkommenen Neuling ausgehen, der diese Funktion erstmalig benutzt und mit den internen Abläufen in keinster Weise vertraut ist. Vor allem kann man gar nicht wirklich hinter die Schnittstelle schauen, das ist eine reine Blackbox.

Bei einer Applikation ist der Kreis der Leser und Anwender einer Schnittstelle viel stärker eingegrenzt - man ist mit der Problemwelt eher vertraut, kennt die Begriffe, es gibt auch ein Wissen über die internen Abläufe im Team (soviele Leute werden im Team nie ausgewechselt).

Daher sieht die Doku in solchen Fällen ganz anders aus.

Kann man also sagen, dass man die Schnittstellendokumentation auf Zielgruppe zuschneiden
muss?

Kann man allgemein soweit gehen, dass man sich beim Kommentieren (nicht nur bei der Schnittstellendoku) immer darüber Gedanken machen muss, für wenn er gedacht ist?

Kann man sogar sagen, dass der Programmierer seine Kommentare vorrangig auf den potentiellen Leser abstimmen muss und nicht danach gehen darf, welche Art von Kommentaren er persönlich am Liebsten vorfinden würde?

Vielen Dank für Deinen Beitrag!

Ciao
shoat

[volkard]

shoat schrieb:

... Du bist ja auf meine Argumentation gar nicht eingegangen ...
Schade, ich hatte ursprünglich gedacht, Du wolltest mir helfen.

such dir die antwort aus

ich helfe nie. ich bin der geist, der stets verneint.

die argumentation hab ich wohl übersehen. oder meintest du, daß du die funktionsweise nicht sofort gesehen hast? das haste nicht geschrieben oder ich habs nicht wahrgenommen, weil das ja gar nicht sein darf.

die bewertung der performance ist von projekt zu projekt verschieden. warum sonst würden manche leute alle wartbarkeit wegwerfen zugunsten des (fas immer irrigen) versuchs, in assembler ein paar prozent rauszuschinden und warum sonst würde man vieles in scriptsprachen machen?

[volkard]

shoat schrieb:

Kann man also sagen, dass man die Schnittstellendokumentation auf Zielgruppe zuschneiden muss?

man muß bereits beim coden dran denken. so zu coden, daß die arbeitskollegen mitspielen können, nennt sich teamgeist.

also weiterhin: lieber lesbaren code bauen als unlesbaren zu kommentieren. allerdings gibs gewisse untergrenzen. wenn einer nicht mit modulo umgehen kann oder keine zeiger kennt, dann stellt man sich einfach vor, der wäre nicht im team und optimiert für die anderen.

[volkard]

übrigens: meine gelungenste code-dokumentation war ein tutorial. damals hab ich ein paar (wirre template-) klassen um die ODBC-Schnittstelle gebaut (unter anderem werte cachen für mehr performance). es wäre völliger unfug gewesen, die klassen und methoden ohne kontext einzeln zu beschreiben. also hab ich ein tutorial gebaut, wie der user die klassen einsetz. zuerstmal nur db öffnen und nen wert aus ner tabelle lesen. dann auch mal 100 werte lesen. mal was schreiben. mal ne abfrage machen und so.
zielgruppe war mir unbekannt, wußte nur, daß die doku auf englisch zu sein hatte.

[Helium]

Den Ausdruck Test-Driven-Design habe ich zwar noch nicht gehört. Aber Du hast Recht. Ich habe vorerst recht viel Material. JUnit oder ein vergleichbares Opensource-Tool soll ein zentraler Bestandteil, des aufzubauenden Testframeworks, werden!

Test-Driven-Design sieht so aus, das due erst einen Test zu einer Funktion schreibst, und erst anschließend die Funktion implementierst. So kannst du sicher sein, dass deine Funktion alles kann, was von ihr verlang wird.

nutzlos. das ist nur ne umformulierung des programmcodes. wirksamer ist ne testfunktion, die nur den zweck hat, die funktion zu testen.

Unit-Test vs. Post-Kondition?
Außerdem erklär das mit der Umformulierung nochmal kurz. Der algorithmus zum Berechnen der Wurzel sieht ja so aus :
w[n+1] = (w[n] + radiant / w[n]) / 2;

das lässt man dann in ner Schleife laufen, bis w[n] == w[n+1]. Ein schnellerer Algorithmus ist mir nicht bekannt.

/edit: letzter Teil war nutzlos.

[shoat]

Hallo erstmal!

Hier bin ich wieder! Hat zwar ein wenig gedauert, da ich den ganzen Input, den ich bekommen habe, erst mal verdauen mußte. Aber jetzt bin ich wieder da und habe auch wieder reichlich neue Fragen!

volkard schrieb:

ich warte auf die metrikenbefürworter. immerhin werden die ja eingesetzt. immerhin lernt man an hochschulen, wie toll die sind.

Ich habe jemanden gefunden. Mein Chef mag sie natürlich! Er ist also nicht der eine von hundert. Nun ja vielleicht doch, hier gleich mal, wie er sie einsetzen will:

Hier - in meinem Betrieb - gibt es zahllose J2EE-Anwendungen (für verteilte Systeme). Die Anwendungen sind dabei grundsätzlich immer sehr ähnlich aufgebaut. Per Definition ist es dabei wichtig, dass einige Funktionen / Klassen sehr klein (effizient) bleiben müssen (und auch fast immer können).

Da es aber ständig unzahlige neue Anwendungen mit noch viel mehr genau solcher Funktionen gibt, möchte er über Metriken (wahrscheinlich reichen hier sogar schon die LOCs) automatisch schnell herausfinden können, ob die diese (o. g.)Funktionen / Klassen bei der entsprechenden J2EE-Anwendung in einem bestimmten Toleranzbereich liegen. Alle die nicht in dem Bereich liegen müssen, werden dann noch mal separat kontrolliert und evtl. verbessert.

Er möchte also nicht den Code an sich (oder gar den Programmierer) komplett bewerten, sondern nur mögliche Schwachpunkte in Systemen finden. Die gefundenen Stellen werden dann auch nicht sofort als Fehler angesehen, sondern zuerst einmal genauer unter die Lupe genommen.

Was haltet ihr davon? Oder gibt es dafür einen einfacheren Weg?

Vielen Dank!

Ciao
shoat

[shoat]

volkard schrieb:

such dir die antwort aus

ich helfe nie. ich bin der geist, der stets verneint.

die argumentation hab ich wohl übersehen. oder meintest du, daß du die funktionsweise nicht sofort gesehen hast? das haste nicht geschrieben oder ich habs nicht wahrgenommen, weil das ja gar nicht sein darf.

die bewertung der performance ist von projekt zu projekt verschieden. warum sonst würden manche leute alle wartbarkeit wegwerfen zugunsten des (fas immer irrigen) versuchs, in assembler ein paar prozent rauszuschinden und warum sonst würde man vieles in scriptsprachen machen?

Oh! Hatte ich doch glatt übersehen.
Hmm ... äh ... nun ja ... obwohl ich A sehr lustig finde, wähle ich doch
"Du hast eine eigene Meinung, die Du hier auch gnadenlos vertrittst!
Außerdem bist Du sehr genau und weist mich auf Fehler hin.
Gelegentlich verstehe ich Dich auch einfach nur falsch."

Danke für Deine Beiträge!

Ciao
shoat

[shoat]

volkard schrieb:

also weiterhin: lieber lesbaren code bauen als unlesbaren zu kommentieren.

Mit der Reihenfolge habe ich gar kein Problem. Natürlich zuerst einen lesbaren Code bauen und diesen dann bei Bedarf kommentieren.

volkard schrieb:

allerdings gibs gewisse untergrenzen.

Genau, dass war (für mich) das Problem. Was sind die Untergrenzen? Welches Wissen kann ich vom Leser des Codes und der Kommentare / Dokumentation erwarten?

Diese Fragen haben sich allerdings für mich mittlerweile (Dank Euerer Hilfe) erst einmal beantwortet.

Ciao
shoat

[shoat]

Jetzt habe ich auch gleich noch eine Frage:

Im Laufe meiner Recherchen stoße ich immer wieder die Begriffe, wie
- Capability Maturity Model (CMM)
- Rational Unified Proces (RUP)
- Modell View Controller (MVC)
- Prototyping

Wie wichtig / wie zeitgerecht sind dahinterstehenden Ideen eigentlich noch?
( MVC scheint ja zumindest Marc++us für ziemlich wichtig zu halten! )

Vielen Dank!

Ciao
shoat

[shoat]

Ach ja,

kann mir vielleicht jemand ein gutes (Open-Source-) Tool zum Durchführen von Lasttest empfehlen?
Meint - ich suche ein Tool, bei dem ich den gleichzeitigen Zugriff von sehr vielen unterschiedlichen Clients auf eine Web-Applikation simulieren kann!

Und wie überprüfe ich überhaupt eine GUI? Ich habe noch nichts in dieser Richtung gefunden und kann mir auch nicht recht vorstellen, wie es funktionieren soll! Kennt jemand dafür ein gutes (Open-Source-) Tool?

Vielen Dank!

Ciao
shoat