Suchergebnisse

Suchergebnisse 1-5 von insgesamt 5.

  • Benutzer-Avatarbild

    @All Jou. Obwohl schon überall gesagt: Prozeduren, Properties usw. kommentieren ist ein Muss (/// bzw. ''' über dem zu kommentierenden Code). Dies wird einem selbst bei der Entwicklung angezeigt. Mein Chef gab mir ein älteres Projekt, das ich weiterführen soll, das war im Prinzip gar nicht dokumentiert, mein Vorgänger hatte es nicht nötig und war dann mal weg. Das wichtigste am Dokumentieren des eigenen Codes ist, dass man in einem halben Jahr oder so, wo in der Zwischenzeit am Code nix passiert…

  • Benutzer-Avatarbild

    @ErfinderDesRades Das ist Geschmackssache. Und da gibt es noch firmeninterne Codierungsregeln, und ich seh nicht ein, dass ich mir bei meinen privaten Projekten da einen anderen Stil aneignen soll. Sehen sie halt genau so aus.

  • Benutzer-Avatarbild

    @ErfinderDesRades Zitat von jvbsl: „Und ich glaube @RodFromGermany meinte mit seinem Satz eben XML kommentare.“Ja, es ist so. Der Haken im Projekt gehört zu den firmen-gegebenen Projekteinstellungen. Kommentare zwischendurch da, wo sie nötig sind. Wenn ich ein Projekt übernehme (und die beiden letzten dieser waren praktisch unkommentiert) fräse ich erst mal quer durch und formatiere den Code nach den neuen Vorschriften (@EDR: Da würdest Du Dich wohl im Grabe herum drehen, { und } stehen da einze…

  • Benutzer-Avatarbild

    Zitat von Nils_Kr: „mit Git kann man den Projektverlauf dokumentieren, aber es erfordert etwas Einarbeitungszeit“Mit jedem Sourcecode-Verwaltungs-Tool. Meins wäre SVN.

  • Benutzer-Avatarbild

    Wenn ich mich nicht irre, sind die UML-Diagramme was für Chefs, die von Software keine Ahnung haben, aber ihren Chefs und den Gästen die Tollizität der Software erklären sollen. Ich kannte mal einen Entwickler, der von dem damaligen Projekt der SW-Architekt war, der hat sich von einem UML-Generator Klassen generieren lassen. Das hat mich sehr gestört, weil da die Properties alphabetisch und nicht logisch sortiert waren.