Gedankenexperiment zu Code-Richtlinien
-
brotbernd schrieb:
pumuckl schrieb:
- implementieren
- Unit-Tests laufen lassen
- goto 6)
- Refactoring
- Unit-Tests laufen lassen
- goto 6)
Refactoring gehört bei mir zur Implementierung dazu. Ganz einfach deshalb, weil ich davon ausgehe, dass ein Implementierungsschritt mit einem genügend rafactored (?) Code beginnt und erst fertig ist, wenn nach dem neu implementierten Feature der Code wieder genügen refactored wurde.
Th69 schrieb:
oder laufen bei dir die Unit-Tests in einer Endlosschleife?
Natürlich nicht. Nur bei jedem noch so kleinen Build
-
OK, dann werd ich dazu wohl mal Stellung nehmen
Im Voraus: Ich habe wenig Erfahrung mit Richtlinien, bisher stelle ich die mir noch selbst und ich wende auch fast keine von denen an, die sind mir nur mal durch den Kopf gegangen, daher erhebe ich auch keinen Anspruch auf Vollständigkeit.
1. Klar, Funktionalität usw. gehört natürlich dazu. Ersteller über Verwaltungssystem, bei unzureichender Sicherheitsüberprüfung kann/sollte man stattdessen vermutlich eher ein TODO irgendwo festhalten. Für Getter und Setter ist das natürlich überzogen, höchstens für ein Doku-Tool.
2. Wie gesagt, ich habe es noch nie ausprobiert. Das sollte (wie goto usw. auch) kein hartes Limit sein, eher fragt man im Umkehrfall mal bei jemand anderem nach, ob es nicht noch besser geht. 30 Zeilen sind ja auch noch kurz. (je nach Aufgabe)
3. Hier stimme ich brotbernd zu. Das muss ja keine Umfrage hier im Forum sein, sondern entwicklungsintern oder erstmal nur einen Mitarbeiter.
4. @pumuckl: Wie gesagt, Ausnahme für Pointer-Implementierungen. Ansonsten gilt wie 2., dass das kein hartes Limit sein sollte. Wenn man ein 9*9-Sudoku-Array hat, muss man natürlich keinen std::array<9, std::array<9, uint8> > daraus machen. Allerdings sollte man sich dann auch im Klaren sein, dass man in einem rohen Array nicht so einfach Debug-Ausgaben realisieren kann. (im std::array auch schwer, aber wenn es dann an eigene Kleinklassen geht, wird das wesentlich einfacher)
5. Sorry, meinte natürlich freie Funktionen und nicht statische. (Hm... in Java heißt es ja static-Funktionen ) Was ich gegen freie Funktionen ohne namespace habe? Das weiß ich auch nicht so genau . Ich fände es besser, sie zu gruppieren (sowohl in namespace als auch dann entsprechend in verschiedene Dateien) aber diese Regel finde ich nicht so wichtig. Globale Variablen sollte man sich wirklich genau überlegen und mindestens absprechen.
6. Das war wohl die gewagteste Aussage. Zur Teamarbeit: Wenn die Main-Funktion einmal implementiert ist und meinetwegen 5 Funktionen aufruft, kann man schon mal 5 Entwicklergruppen einteilen, die die Funktionen implementieren. Entsprechend könnte dann weiter aufgeteilt werden. Mit Tests usw. und ohne gute Planung geht das vermutlich nur sehr schwierig. Das Implementierungsverbot für nicht benutzte Funktionen/Klassen ist vermutlich zu hart, da gebe ich euch Recht.
7. + 8. Wie gesagt, Ausnahmen sind generell möglich, aber nicht unbedingt erwünscht.
-
wxSkip schrieb:
bei unzureichender Sicherheitsüberprüfung kann/sollte man stattdessen vermutlich eher ein TODO irgendwo festhalten.
Nein, man sollte es von vornherein richtig machen. Exceptionsicherheit wirkt sich auf alles aus, was du in einer Funktion machst. Wenn du sie nicht von Anfang an sicher schreibst, heißt dein "TODO", dass du sie nochmal zu 80% neu schreiben musst. Das ist dann wiederum eine so große Hürde, dass das Provisorium nie aufgelöst wird. Machs also gleich oder lass es ganz sein.
4. @pumuckl: Wie gesagt, Ausnahme für Pointer-Implementierungen. Ansonsten gilt wie 2., dass das kein hartes Limit sein sollte. Wenn man ein 9*9-Sudoku-Array hat, muss man natürlich keinen std::array<9, std::array<9, uint8> > daraus machen. Allerdings sollte man sich dann auch im Klaren sein, dass man in einem rohen Array nicht so einfach Debug-Ausgaben realisieren kann. (im std::array auch schwer, aber wenn es dann an eigene Kleinklassen geht, wird das wesentlich einfacher)
Wenn du an Klein- und Kleinstklassen wie einem Array schon debugausgaben anbringen willst, dann gute Nacht. Solche Klassen sind in größeren Projekten zu tausenden vertreten, und wenn da Debugausgaben kommen, heißt das Millionen von zeilen Debugmist, den keiner mehr lesen kann -> alles für die Katz. Mal abgesehen davon, dass ein "array.get() aufgerufen" nicht wirklich aussagekräftig sein kann.
-
pumuckl schrieb:
4. @pumuckl: Wie gesagt, Ausnahme für Pointer-Implementierungen. Ansonsten gilt wie 2., dass das kein hartes Limit sein sollte. Wenn man ein 9*9-Sudoku-Array hat, muss man natürlich keinen std::array<9, std::array<9, uint8> > daraus machen. Allerdings sollte man sich dann auch im Klaren sein, dass man in einem rohen Array nicht so einfach Debug-Ausgaben realisieren kann. (im std::array auch schwer, aber wenn es dann an eigene Kleinklassen geht, wird das wesentlich einfacher)
Wenn du an Klein- und Kleinstklassen wie einem Array schon debugausgaben anbringen willst, dann gute Nacht. Solche Klassen sind in größeren Projekten zu tausenden vertreten, und wenn da Debugausgaben kommen, heißt das Millionen von zeilen Debugmist, den keiner mehr lesen kann -> alles für die Katz. Mal abgesehen davon, dass ein "array.get() aufgerufen" nicht wirklich aussagekräftig sein kann.
Du könntest damit immerhin einen falschen Arrayzugriff feststellen/ausschließen, auch ohne Debugausgaben...