qualitativ hochwertiger Programmcode...

shoat schrieb:

Nur auf eines möchte ich beharren. Schnittstellen, die nach außen gehen (public!), die also auch der User / Laie verstehen muss, sollten zusätzlich sehr ausführlich, meint newbie-tauglich gehalten werden.

(In der Tat sind, dass auch die Schnittstellen, an denen unter Java javadoc ansetzt, auch, wenn ich es bisher nie so empfunden habe.)

Können wir uns darauf einigen?

Nein, ich finde das weder notwendig noch wünschenswert!

Code, der Newbie- oder gar Laien-tauglich ist, ist normalerweise alles andere als qualitativ hochwertig! Dasselbe gilt (vielleicht sogar in verstärktem Maße) für Kommentare bzw. Schnittstellenbeschreibungen. Wie soll ich mir Code vorstellen, der dieser Anforderung genügt, was soll ich voraussetzen können und was nicht?! Das ist doch bei diesen Zielgruppen kaum zu entscheiden. Ich müßte so ziemlich alles erklären, was schon im Code zu sehen ist, denn ein Newbie (oder gar ein Laie) kennt es möglicherweise nicht.

Qualitativ hochwertiger Code muß voraussetzen können, daß der Entwickler, der damit zu tun hat, sein Geschäft beherrscht. Das bedeutet nicht nur, daß er die Sprachmittel und Standard-Bibliotheken erschöpfend kennt, sondern auch Dinge, wie Design Patterns, grundlegende Algorithmen usw., die also mit der Programmiersprache nichts zu tun haben. Und selbst Kenntnisse bezüglich des Fachgebiets, für das die Software geschrieben ist, muß man voraussetzen können - zumindest grundlegende Kenntnisse.

Newbies sollten genügend Erfahrungen mit nicht produktivem Code machen, bevor sie ernsthaft zu entwickeln beginnen. Sie haben an produktivem Code nichts zu suchen! Das gilt natürlich erstrecht für Laien. In diesem Sinne ist natürlich wieder einmal XP erwähnenswert: Das Pair Programming ist, finde ich, genau das Richtige, um Newbies schnell an ihren Job heranzuführen. (Bloß schade, daß in diesem unserm Lande die Firmen anscheinend überhaupt kein Intersse an XP haben. Oder weiß jemand einen XP-Job für mich? ).

Stefan.

volkard

DStefan schrieb:

Im Falle von find() fehlt eine Fehlerbehandlung (arr darf nicht 0 sein).

und was passiert da? ein assert? da ist meine schutzverletzung doch gleichwertig.
bei msvc gilt: die dereferenzierung von 0 löst eine feine schutzverletzung aus, die öffnet die ide und zeigt auf die code-zeile, wo es passiert ist und man kann prima die variableninhalte und alles so inspizieren und in wenigen sekunden hat man den fehler behoben.

volkard

Helium schrieb:

assert(ergebnis * ergebnis == radiant);

nutzlos. das ist nur ne umformulierung des programmcodes. wirksamer ist ne testfunktion, die nur den zweck hat, die funktion zu testen.
dann passieren auch so fehler nicht, wie "assert(ergebnis * ergebnis == radiant);" statt "assert(fabs(ergebnis*ergebnis-radiant)<=42*WILLKUER);"

volkard

shoat schrieb:

Ich persönlich würde es trotzdem dazuschreiben, wenn es sich um public-Funktionen (s. o.) handelt.
Denn eine Schnittstellenbeschreibung sollte unbedingt immer gemacht werden!

wir fragen, warum eine schn. immer gemacht werden muß. da reicht als begürndung nicht "denn eine schn. muß immer gemacht werden!!!!".

shoat

DStefan schrieb:

Nein, ich finde das weder notwendig noch wünschenswert!
...

Deine Ausführungen bzgl. des Codes kann ich nur bestätigen.

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

Viele Grüße
shoat

volkard

und nochwas aus der ganz ganz tiefen praxis:
ungutes gefühl haben bei

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

gutes gefühl haben bei

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

das erkennt der kundige progger nämlich als das muster auf dem ziffernblock und wenn er mal die grafik bildlich braucht, weils schwieriger wird, muß er nicht blättern.

shoat

volkard schrieb:

shoat schrieb:

Ich persönlich würde es trotzdem dazuschreiben, wenn es sich um public-Funktionen (s. o.) handelt.
Denn eine Schnittstellenbeschreibung sollte unbedingt immer gemacht werden!

wir fragen, warum eine schn. immer gemacht werden muß. da reicht als begürndung nicht "denn eine schn. muß immer gemacht werden!!!!".

Du bist nicht mehr up2date. Ich habe diese allgemeine Meinung
1. revidiert und
2. ausführlich erklärt warum

Solltest ich mich irgendwo mißverständlich ausgedrückt haben. Dann sag mir ruhig Bescheid.

Vielleicht sollest Du und auch alle anderen Bedenken, dass ich weder die Erfahrung noch dass Wissen von Dir / Euch habe. Deswegen höre ich etwas, sage meine Meinung dazu und lasse mich dann belehren, oder auch nicht. Ihr seid also meine Quasi-Lehrer! (und ich der ungezogene Schüler )

Vielen Dank für Deine Beiträge!

Ciao
shoat

shoat

volkard schrieb:

shoat schrieb:
public class Mobile...
    /**
     * Versetzt das Mobile in die angegebene "richtung".
     * @param 	richtung    Gibt die Richtung an. Dabei bedeutet richtung%9 
     *                        gleich 0 linksunten, 1 unten, 2 rechtsunten, 
     *                        3 links, ...
     */
ähm. wolltest du mir jetzt zeigen, daß ein wechsel nach java besser ist? oder daß man mehr kommentare machen soll?

zweiteres
(Aber vielleicht auch ersteres. Hast Du Dich schon bei der xavo beworben?)

volkard schrieb:

übrigens: ein wort sagt weniger als 1e-3 bilder.
/* richtungen: 012
               345
               678
*/

Du hast vollkommen recht. Dieses Bild habe ich heute auch schon gemalt! Nur bin ich von einem kartesichen Koordinatensystem ausgegangen. Ich hatte mich schon gewundert, warum bei Nordwest xPos-- und yPos-- gelten soll. Ich habe etwas länger gebraucht um dahinter zu kommen, dass Du in Bildschirmkoordinaten gerechnet hast. I'm really sorry!

volkard schrieb:

"am besten" ist eine so fette beschreibung...

Mit meinem bescheiden Wissen, fand ich es so besser und es war das Beste, was mir dazu im Moment eingefallen ist. Wobei ich mich v. a. auf die Kommentierung bezogen hatte.

Natürlich ist der superlativ "am Besten" wahrscheinlich nie angebracht, genauso wenig wie es schicklich ist immer oder nie zu sagen. Es gibt bestimmt immer was besseres, also sollte man nie "am Besten" sagen. Ich wundere mich immer wieder, warum mir soetwas passiert. Selbstreded weiss ich, dass Dir sowas noch nie passiert ist...

Warum? Ganz einfach. Wenn Dritte Deinen Code nutzen sollen, dann fällt ihnen dies viel leichter, wenn die nutzbaren Schnittstellen verständlich beschrieben sind. I. d. R. dauert es viel länger, wenn man erst den Quell-Code anschauen und verstehen muss.

Ich möchte nochmals sagen, dass ich meine Meinung bzgl. der Schnittstellbeschreibung schon revidert habe.

Es ist natürlich schön dem anderen gelegentlich das Wort im Mund rumzudrehen und genau das reinzuinterpretieren, was er nicht ausdrücken wollte.

Du weißt genauso gut wie ich, dass sich alle nicht Freaks (meint Du und Deinesgleichen ausgeschlossen) bestimmt mit einer kurzen Beschreibung viel leichter täten, als mit dem reinen Quelltext. Dass ich bestimmt nicht darauf aus war, dass jemand Kommentar machen muss, wenn er x++ verwendet, weißt Du genau! 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. Oder ist es sinnvoll, wenn jeder, der den Funktion benutzen soll, erst die Formeln nachvollziehen muss? Deswegen wäre ich für einen Kommentar (Schnittstellenbeschreibung) - gerne in Form einen Bildes (s. o.) - sehr dankbar.

Ich hoffe, ich habe mich nicht schon wieder mißverständlich ausgedrückt.

Ciao
shoat

volkard

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.

volkard

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

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.

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