denn sie wissen nicht was sie programmieren, zumindest ich =)

-rebell- 0

mir gings früher ähnlich wie dem Threadersteller. Ich hab abends immer dann aufgehört als ich zu Müde war, und morgens wieder weitergemacht. Abends liefs flüssig, und morgens wußt ich nicht, wie ich weitermachen soll. IMO hilft es, wenn man sich vor dem Beenden am Abend noch ein paar Zeilen Kommentar schreibt, wie es weitergehen soll, so findet man am nächsten Morgen wieder leichter zurück. Mir is es jedenfalls so ergangen

Ob man ein gutes Gedächtnis braucht kann ich nicht sagen, ich selber habe im Bezug auf Programmierung ein verdammt Gutes, dafür vergesse ich alles was nicht mit proggen zu tuen hat. Bei kleinen Projekte kenne ich fast den ganzen Code auswendig, ab einer bestimmten Größe (100k Zeilen und mehr) weis ich zumindest grob wo der Code steht und was er ungefähr macht.

Jedoch, wenn man schon am nächsten Tag nicht mehr versteht was der eigene Code macht, dann hat das wenig mit Gedächtnis zu tuen, sondern ist imho einfach ein Zeichen für sehr schlechten Code-Style. Gut lesbarer Code definiert sich (imho)darüber, wie schnell jemand der diesen vorher _nicht_ kannte ihn verstehen kann. Allein die gute Wahl von Namen (sowohl Methoden als auch Variablen) wirkt hier oft Wunder. Wirft man noch ein paar simple Grundregeln ein wie z.B.: "eine Funktionalität pro Funktion" so kommt man schnell zu gut verständlichem Code.

Nebenbei, guter Code braucht wenig KOmmentare. Ich behaupte sogar das das auftauchen bestimmter Kommentararten ein deutliches Zeichen für schlechten Code ist. Beispielweise, wenn man eine Variable kommentieren muß um zu verstehen wofür sie gedacht ist, dann ist der Variablenname wahrscheinlich schlecht gewählt.

Ich glaube es hilft wenn man den Begriff "Lesbarkeit" bis zu einem gewissen Grad wörtlich nimmt. Stellt euch einfach vor ihr müsstet den Code am Telefon einem anderen Programmierer vorlesen und der müßte ihn dann verstehen ohne ihn aufschreiben zu können...

long pLongDtaDstPtr;
 long pLongDtaSrcPtr;

im Gegensatz zu

long dataSource;
 long dataDestination;

Woher wollt ihr mit eurem schlechten Gedächtnis eigentlich wissen, dass ihr gute Programmierer seid, wenn ihr es schon wieder vergessen habt? :p

_matze

dieFrage schrieb:

Woher wollt ihr mit eurem schlechten Gedächtnis eigentlich wissen, dass ihr gute Programmierer seid, wenn ihr es schon wieder vergessen habt? :p

Zettel am Monitor.

Nexus

loks schrieb:

Jedoch, wenn man schon am nächsten Tag nicht mehr versteht was der eigene Code macht, dann hat das wenig mit Gedächtnis zu tuen, sondern ist imho einfach ein Zeichen für sehr schlechten Code-Style. Gut lesbarer Code definiert sich (imho)darüber, wie schnell jemand der diesen vorher _nicht_ kannte ihn verstehen kann.

Naja, ein "gutes" Gedächtnis ist sicher hilfreich. Zum Beispiel, wenn man etwas Grösseres programmiert und dabei immer wieder an verschiedenen Ecken rumwerkelt. Auch wenn einem moderne IDEs einige Arbeit abnehmen (IntelliSense & Co.), ist es meiner Ansicht nach besser, wenn man selbst den Überblick behalten kann. Auch dass ein schlechtes Gedächtnis eher förderlich für gute Programmierer sei, halte ich für eine gewagte Aussage.

loks schrieb:

Nebenbei, guter Code braucht wenig KOmmentare. Ich behaupte sogar das das auftauchen bestimmter Kommentararten ein deutliches Zeichen für schlechten Code ist. Beispielweise, wenn man eine Variable kommentieren muß um zu verstehen wofür sie gedacht ist, dann ist der Variablenname wahrscheinlich schlecht gewählt.

Ich glaube es hilft wenn man den Begriff "Lesbarkeit" bis zu einem gewissen Grad wörtlich nimmt. Stellt euch einfach vor ihr müsstet den Code am Telefon einem anderen Programmierer vorlesen und der müßte ihn dann verstehen ohne ihn aufschreiben zu können...

Je nachdem widersprechen sich deine beiden Kriterien aber. Es gibt ab und zu Bezeichner (Variablen, Funktionen, Klassen, Typen,...), die für eine komplexere Funktionalität stehen. Um diese ersichtlich zu machen, wäre aber wieder ein langer, aussagekräftiger Name notwendig - ist oft unleserlich.

Ich kommentiere ab und zu Variablen. Damit kann ich meistens mehr aussagen und die Beschreibung an einer einzigen Stelle ändern, sodass der Bezeichner unberührt bleibt.

byto

Nexus schrieb:

loks schrieb:

Jedoch, wenn man schon am nächsten Tag nicht mehr versteht was der eigene Code macht, dann hat das wenig mit Gedächtnis zu tuen, sondern ist imho einfach ein Zeichen für sehr schlechten Code-Style. Gut lesbarer Code definiert sich (imho)darüber, wie schnell jemand der diesen vorher _nicht_ kannte ihn verstehen kann.

Naja, ein "gutes" Gedächtnis ist sicher hilfreich. Zum Beispiel, wenn man etwas Grösseres programmiert und dabei immer wieder an verschiedenen Ecken rumwerkelt. Auch wenn einem moderne IDEs einige Arbeit abnehmen (IntelliSense & Co.), ist es meiner Ansicht nach besser, wenn man selbst den Überblick behalten kann. Auch dass ein schlechtes Gedächtnis eher förderlich für gute Programmierer sei, halte ich für eine gewagte Aussage.

Ich denke, häufig ist es eher das Langzeitgedächtnis, dass bei einem Logiker-Hirn nicht so ausgeprägt ist. Das heisst, man vergisst nicht umbedingt die Dinge, mit denen man ständig zu tun hat (z.B. den täglichen Code), sondern eher Dinge, mit denen man lange nicht mehr zu tun hatte.

Darüber hinaus braucht man sich nicht "merken" (in Form von lernen), wo welcher Code steht, wenn der Code hinreichend strukturiert ist. Da ergibt sich aus dem Kontext, wo man was findet. Zumindest die grobe Richtung ist dadurch vorgegeben. Und bei den letzten Metern hilft dann die IDE.

Hier ist einer der besser hätte programmieren können, wenn er ein besseres Gedächtnis gehabt hätte. http://www.c-plusplus.net/forum/viewtopic-var-t-is-253654.html

Begrün schrieb:

Hier ist einer der besser hätte programmieren können, wenn er ein besseres Gedächtnis gehabt hätte. http://www.c-plusplus.net/forum/viewtopic-var-t-is-253654.html

jaja, das macht nur der viele alkohol. *fg*

Icematix

Kennt ihr das auch?

Man schaut nach etwas Zeit alten Code an, bemerkt plötzlich vermeintliche Fehler, schreibt den halben Code um bis man bemerkt dass es davor doch richtig war und jetzt falsch ist?

Icematix schrieb:

Man schaut nach etwas Zeit alten Code an, bemerkt plötzlich vermeintliche Fehler, schreibt den halben Code um bis man bemerkt dass es davor doch richtig war und jetzt falsch ist?

ja, das passiert wenn man nicht mehr komplett im thema drinsteckt und meint, irgendwas verbessern zu müssen, was vordergründig umständlich aussieht. liegt aber oft auch an schlechten/falschen kommentaren im code. ich bin in der beziehung sehr vorsichtig geworden. der spruch: 'never change a running system' existiert nicht ganz zu unrecht.

byto

Icematix schrieb:

Man schaut nach etwas Zeit alten Code an, bemerkt plötzlich vermeintliche Fehler, schreibt den halben Code um bis man bemerkt dass es davor doch richtig war und jetzt falsch ist?

Mit Unittests wäre das nicht passiert.

EXDW

;fricky schrieb:

der spruch: 'never change a running system' existiert nicht ganz zu unrecht.

dieses sprichwort fuehrt dazu das dirty hacks auch drinnen bleiben
(wenn man nie ein funktionierendes system geaendert haette waeren wir noch auf windows 3.0)

man muss immer wieder etwas riskieren um auch richtige fortschritte zu haben

Mr Evil schrieb:

;fricky schrieb:

der spruch: 'never change a running system' existiert nicht ganz zu unrecht.

dieses sprichwort fuehrt dazu das dirty hacks auch drinnen bleiben
(wenn man nie ein funktionierendes system geaendert haette waeren wir noch auf windows 3.0)
man muss immer wieder etwas riskieren um auch richtige fortschritte zu haben

naja, ich brauche schon einen triftigen grund, um irgendwas zu verändern. wenn eine software nur aus lauter miesen hacks besteht, sonst aber prima läuft, ist für mich kein grund.

MasterK

;fricky schrieb:

wenn eine software nur aus lauter miesen hacks besteht, sonst aber prima läuft, ist für mich kein grund.

Bis man irgendwann in der situation ist, dass man in relativ kurzer zeit neue funktionalität hinzufügen soll. Dann steht man vor einem riesen haufen code-müll und versucht die neuen funktionen da irgendwie reinzufrickeln, was in noch grösserem code-müll endet. Ganz abgesehen davon natürlich, dass es 3x so lang dauert. Und man beim nächsten mal vor genau dem gleichen problem steht.

Aber es läuft ja. Irgendwie...

MasterK schrieb:

Bis man irgendwann in der situation ist, dass man in relativ kurzer zeit neue funktionalität hinzufügen soll.

das wäre z.b. ein grund fürs aufräumen.

EXDW

er sagte ja "relativ kurze zeit"
man kann doch schon vorher aufraeumen - wo man die zeit hat - und da muss man ein funktionierendes system anfassen und aendern - einfach damit die dirty hacks weg sind (die aus zeitmangel rein kamen) und man spaeter beim erweitern keine zeit dafuer aufbringen muss

viele meiner kollegen dachten anfangs auch so - immer mehr leute gehen von diesem sprichwort weg und riskieren auch mal etwas - muss man halt hin und wieder

byto

Deswegen ist der konsequente Einsatz von Unittests so sinnvoll.

Muss man das System ändern, kann man jederzeit überpüfen, ob Unittests fehlschlagen. Laufen alle Tests durch, ist das natürlich noch keine Garantie, dass alles einwandfrei funktioniert. Aber viele Fehler lassen sich dadurch schonmal aufdecken.

Und je besser die Qualität der Tests, umso mehr Fehler findet man bei Codeänderungen. Zusätzlich sinkt die Hemmschwelle der Entwickler, bestehenden Code sinnvoll zu refactorn, statt einfach nur einen Balkon dranzubauen.

Mr Evil schrieb:

viele meiner kollegen dachten anfangs auch so - immer mehr leute gehen von diesem sprichwort weg und riskieren auch mal etwas - muss man halt hin und wieder

aber es ist doof risiken einzugehen, wenn man am ende fast nichts gewinnt. jede software ist irgendwie modular aufgebaut. wenn nun eins dieser module von übelsten dilettanten zusammengeflickt wurde und nur per zufall funktioniert, gibt es keinen grund, etwas daran zu verändern, wenn dieses modul einfach nur benutzt werden soll und es zuverlässig arbeitet. aus sicht von client-code ist es eine 'black box', die irgendwelche funktionen erfüllen soll. wie sie das macht, oder wie schlecht sie programmiert ist, spielt dabei keine rolle. erst wenn das ding probleme macht, muss es umgebaut oder ersetzt werden, vorher nicht. man sollte sein ästhetisches empfinden in den hintergrund stellen, wenn man fremden code einsetzt. das ist vielleicht für viele nicht ganz einfach.

byto schrieb:

Deswegen ist der konsequente Einsatz von Unittests so sinnvoll.

auf jeden fall sind unit-tests sehr sinnvoll. aber sie sind keine versicherung gegen fehler, wenn man an code rumbastelt, ohne zu wissen, welche folgen irgendwelche eingriffe haben können.

EXDW

wenn das modul aber in sehr kurzer zeit erweitert oder anders veraendert werden soll hat man nicht mehr die zeit den dirty hack weg zu bekommen oder das ding neu auf zu ziehen - schlimmstenfalls verstaerkt man noch die hacks indem andere drum herum gebastelt werden

fuer den benutzer ist es ne blackbox - da hast du recht - aber darum gehts gar nicht sondern um das modul selber

;fricky schrieb:

aber es ist doof risiken einzugehen, wenn man am ende fast nichts gewinnt. jede software ist irgendwie modular aufgebaut. wenn nun eins dieser module von übelsten dilettanten zusammengeflickt wurde und nur per zufall funktioniert, gibt es keinen grund, etwas daran zu verändern, wenn dieses modul einfach nur benutzt werden soll und es zuverlässig arbeitet. aus sicht von client-code ist es eine 'black box', die irgendwelche funktionen erfüllen soll. wie sie das macht, oder wie schlecht sie programmiert ist, spielt dabei keine rolle. erst wenn das ding probleme macht, muss es umgebaut oder ersetzt werden, vorher nicht. man sollte sein ästhetisches empfinden in den hintergrund stellen, wenn man fremden code einsetzt. das ist vielleicht für viele nicht ganz einfach.

Zum Teil gebe ich Dir da Recht, nur weil ein Modul schlecht programmiert ist muß man es nicht zwingend verbessern. Auf der anderen Seite gehst Du aber ebenso ein Risiko ein es nicht anzupacken.

Scenario 1: Du läßt das schlechte MOdul solange laufen bis tatsächlich ein Problem austritt und packst es erst dann an.

Scenario 2: Du machst eine Refaktoring Runde um zumindest die schlimmsten Hacks loszuwerden auch ohne das ein akutes Problem existiert.

Nach "Never change a running System" würde man Scenario 1 bevorzugen. Das große Risiko dabei ist, daß man nicht vorhersagen kann _wann_ ein Problem auftritt und ob man dann, wenn es auftritt die notwendige Zeit hat es zu lösen. Im worst-case könnte das Problem so ungünstig auftreten das man eine wichtige Deadline vermasselt. Erschwerend kommt hier hinzu das der schlechte Code eine Problemlösung in der Regel zusätzlich erschwert.

Im Scenario 2 dagegen wird die Problembekämpfung zu einem Zeitpunkt durchgeführt den man selbst bestimmen kann, damit wird die Arbeit planbar. Klar kann immer noch zu einem späteren Zeitpunkt ein unvorhergesehenes Problem auftreten, aber dann kommt einem der bereits aufgeräumte Code wahrscheinlich entgegen und die Problemlösung wird leichter.

In der Realität bin ich allzu oft gezwungen Scenario 1 zu wählen, aber mehr als einmal mußte ich bei Projekten erleben wie ein "Quick Hack" meines Vorgängers mir eine Deadline versaut hat. Sauberer Code ist mehr als nur ein "Nice to have", langfristig kann er Dir den Arsch retten. Wogegen diese "läuft schon irgendwie Hacks" auf lange Sicht fast immer mehr Probleme erzeugen als sie lösen.