Gedankenexperiment zu Code-Richtlinien

[knivil]

Voellig ueberzogen und manchmal sogar inhaltlich falsch! Die Umfrage fuer Namen findet ich besonders schwachsinnig. Die Frage draengt sich foermlich auf: Was willst du mit diesen Richtlinien erreichen?

[pumuckl]

wxSkip schrieb:

1. Jede Funktion wird kommentiert mit Sicherheitsgrad, Teststatus, Ersteller, ...

Jede Funktion: überzogen. public und protected Funktionen reichen meist, getter und Setter sollten selbsterklärend sein.
Sicherheitsgrad: wie meinen? Grad der Exception-Sicherheit?
Teststatus: was ist damit gemeint?
Ersteller: unnötig, wenn ein vernünftiges CM genutzt wird.

2. Funktionen sollten maximal 5-10 Zeilen enthalten (es wird soviel gekapselt wie möglich)

Ok.

3. Wenn einem kein Funktionsname einfällt, der die Funktion treffend beschreibt, wird eine Umfrage gestartet. (Gleiches für Variablen-/Klassennamen)

Blödsinn, dauert viel zu lange. Außerdem werden andere Entwickler, die in der Thematik vielleicht nichtmal drin stecken, keinen passenderen Namen finden. Wenn einem wirklich kein beschreibender Name einfällt, sollte man nochmal schauen, was die Funktion macht. Meist macht sie dann nämlich mehrere Dinge oder nicht genau abgegrenzte Dinge und sollte überarbeitet werden.

4. Rohe Pointer sind verboten (außer bei char **argv, welches in einen Vektor geschoben wird und evtl. eigenen Pointer-Implementierungen wie shared_ptr, unique_ptr, ... Bibliotheken, die Pointer-Funktionen enthalten, werden gekapselt)

Und was ist mit den rohen Pointern, die du brauchst, um eigene Smartpointer zu implementieren? Ich halte ein komplettes Verbot für zu restriktiv.

5. Globale Variablen und Funktionen sind verboten. (Statische Funktionen müssen mindestens in einen namespace)

Statische Funktionen sind quark, das gleiche kann man mit anonymen Namespaces erreichen. Das Verbot von globalen Funktionen und Variablen wird leicht umgangen, indem man sich einen dummy-namespace ausdenkt. (und grundsätzlich alle Funktionen und Variablen auf namespace-Ebene zu verbieten wäre Irrsinn)
Besser: Den Leuten beibringen, was an globalen Variablen (ggf. auch an globalen Funktionen) unerwünscht ist, und statt eines Verbots eine Dokumentationspflicht aussprechen. (D.h. wenn ich ne globale Variable nutze, muss ich dokumentieren, warum die üblichen Alternativen nicht funktionieren.)

6. Design von oben nach unten -> Erst wird die main()-Funktion implementiert, dann eine andere, die von main() aufgerufen wird usw. => Es dürfen nur Klassen/Funktionen/Memberfunktionen/Membervariablen implementiert werden, die aus bestehendem Code aufgerufen werden)

Zu restriktiv. Bestehender Code können auch unit-tests sein, d.h. ich schreibe ein Klasseninterface, danach den Unit-Test, dann implementiere ich die Klasse, bis der test läuft, dann hänge ich sie in den bestehenden Code ein.

7. Variablen in Klassen dürfen nicht public sein.

... und Ausnahmen müssen dokumentiert werden. Ausnahme: struct ohne Methoden als einfache Datenklammer.

8. Kein goto.

OK.

Das ist aber noch nicht alles, da fehlen dann in meinen Augen noch zig Richtlinien. Was du uns da geliefert hast sieht aus wie ein Querschnitt von "selbstverständlich" bis "viel zu detailliert und restriktiv".

[brotbernd]

knivil schrieb:

Die Umfrage fuer Namen findet ich besonders schwachsinnig.

Ich fand das war einer der wenigen Punkte worüber man nachdenken kann. So ungefähr mach ich das auch. Wenn ich bei der Namenssuche nicht weiterkomme, frage ich einfach mal den Tischnachbarn. Wenn der nix weiß frag ich halt jemand an der Kaffeemaschine...
Namen sind etwas extrem wichtiges und manchmal ist es echt schwer einen guten zu finden. Bevor man dann irgendeine schlechte Wahl trifft, fragt man einfach mal jemand anderes. Vielleicht fällt dem spontan was ein. Aber das gilt eigentlich für jede Form von Problemen. Kommunikation im Team ist sehr wichtig. Das ist allerdings wirklich nichts für eine Code-Richtline. Sowas sollte irgendwie im Entwicklungsprozess festgehalten sein und an die Mitarbeiter kommuniziert werden.
Zu den anderen Punkten

1. Jede Funktion wird kommentiert mit Sicherheitsgrad, Teststatus, Ersteller

Zumindest für öffentliche Funktionen kann man das durchaus festlegen, auch das Format der Kommentare (zb für Einsatz von doxygen)

2. Funktionen sollten maximal 5-10 Zeilen enthalten (es wird soviel gekapselt wie möglich)

Und was ist eine Funktion mit 7 Zeilen? 5-10? Gültig oder nicht? Ich würde sowas nicht anhand einer quantitativen Regeln festmachen. Man könnte sagen es wird alles axtrahiert was geht. aber das ist auch zu vage, daher wird ich so eine Regel gar nicht einführen.

4. Rohe Pointer sind verboten (außer bei char **argv, welches in einen Vektor geschoben wird und evtl. eigenen Pointer-Implementierungen wie shared_ptr, unique_ptr, ... Bibliotheken, die Pointer-Funktionen enthalten, werden gekapselt)

Je nach Projekt und Wissensstand der Teammitglieder könnte man darüber streiten. Generall halte ich da abe rnichts von.

5. Globale Variablen und Funktionen sind verboten. (Statische Funktionen müssen mindestens in einen namespace)

Was ist denn an "globalen Funktionen" schlecht?

6. Design von oben nach unten -> Erst wird die main()-Funktion implementiert, dann eine andere, die von main() aufgerufen wird usw. => Es dürfen nur Klassen/Funktionen/Memberfunktionen/Membervariablen implementiert werden, die aus bestehendem Code aufgerufen werden)

Hä was soll das denn? Continous Integration Extreme? Integration vor der Implementierung? Man könnte vielleicht sagen, es darf nur Code geschrieben werden, der aus bestehenden UnitTests aufgerufen wird, a la TDD, aber das fänd ich als Richtlinie auch etwas hart.

7. Variablen in Klassen dürfen nicht public sein.

Würde ich einschränken auf Klassen, die ausser Daten noch Logik enthalten.

8. Kein goto.

Kann man machen.

[pumuckl]

brotbernd schrieb:

Man könnte vielleicht sagen, es darf nur Code geschrieben werden, der aus bestehenden UnitTests aufgerufen wird, a la TDD, aber das fänd ich als Richtlinie auch etwas hart.

Ich persönlich machs in meinem privaten Projekt so. Ähnlich wie oben beschrieben:

1. was muss die Klasse können?
2. -> öffentliches Interface festlegen
3. Unit-Tests schreiben und laufen lassen
4. -> natürlich Linkerfehler
5. implementieren
6. Unit-Tests laufen lassen
7. goto 6)

[hustbaer]

(1) Nicht sinnvoll, da meist viel zu viel Overhead. In den meisten Projekten ist die Gefahr, dass solche Kommentare "veralten", und bald nur mehr Unnsinn sind, viel zu gross.
(2) Als Richtlinie OK, strikt forciert die Hölle.
(3) Kommt drauf an wie so eine Umfrage aussieht. Formlos in einem internen Forum o.ä. ist vielleicht gerade noch OK. Ansonsten sehe ich die Gefahr dass die Produktivität sehr leidet.
(4) Nicht sinnvoll, da es einige Fälle gibt wo rohe Zeiger sich ganz natürlich anbieten. z.B. Parent-Control referenziert Child-Controls über shared_ptr, Child Control referenziert Parent über Control*. weak_ptr wäre da unnötiger Overhead.
(5) "Statische Funktionen müssen mindestens in einen namespace" - meinst du freie Funktionen oder wirklich statische? Freie Funktionen sind auf jeden Fall sehr nützlich, diese zu verbieten wäre ein Fehler.
(6) Sehr stark Ansichtssache. Man kann dabei viele Dinge übersehen, und je mehr Code bereits existiert wenn man draufkommt dass man etwas übersehen hat, desto mehr muss refactored werden.
(7) OK, ausgenommen POD-structs (müssen auch keine strengen PODs sein, oft ist ein Konstruktor sinnvoll, manchmal sogar 1-2 Memberfunktionen)
(8) Grundsätzlich OK, allerdings nur, wenn die Regeln nicht 100% strikt sind. Goto um jeden Preis zu verhindern ist nicht sinnvoll.

[Jockelx]

hustbaer schrieb:

(2) Als Richtlinie OK, strikt forciert die Hölle.

Hab mich schon gewundert, dass scheinbar keinem vorher direkt eigene Funktionen eingefallen sind, deren Kürzung auf unter 10 Zeilen komplett unleserlich und unsinig wären.

Generell würde ich bei einem solchen Projekt nicht arbeiten wollen und das obwohl ich da sehr offen bin (zumindest im Vergleich zu anderen hier, die scheinbar schon wenn sie z.B. UN sehen, schreiend weglaufen).

[Th69]

pumuckl schrieb:

...
5) implementieren
6) Unit-Tests laufen lassen
7) goto 6)

Du meinst wohl eher

if (error)
  goto 5

oder laufen bei dir die Unit-Tests in einer Endlosschleife?

Zu Coding Styles schreibe ich jetzt lieber nichts - aktuell warte ich nämlich auf die unseres Framework-Anbieters...

[CStoll]

wxSkip schrieb:

1. Jede Funktion wird kommentiert mit Sicherheitsgrad, Teststatus, Ersteller, ...

Halte ich für eine gute Idee, aber wichtiger ist imho, den Zweck der Funktion und die Bedeutung der Parameter zu dokumentieren.

2. Funktionen sollten maximal 5-10 Zeilen enthalten (es wird soviel gekapselt wie möglich)

Keine gute Idee - das führt nur dazu, daß aus einer mittelgroßen Funktion ein Dutzend kleine werden, von denen keine für sich alleine etwas sinnvolles macht.

3. Wenn einem kein Funktionsname einfällt, der die Funktion treffend beschreibt, wird eine Umfrage gestartet. (Gleiches für Variablen-/Klassennamen)

Wenn einem kein Name einfällt, ist das vermutlich ein Zeichen dafür, daß die Aufgaben der Funktion nicht klar sind.

4. Rohe Pointer sind verboten (außer bei char **argv, welches in einen Vektor geschoben wird und evtl. eigenen Pointer-Implementierungen wie shared_ptr, unique_ptr, ... Bibliotheken, die Pointer-Funktionen enthalten, werden gekapselt)

Damit bin ich einverstanden. Nackte Pointer sollten nur dort verwendet werden, wo es unbedingt notwendig ist (die Implementation einer Smart-Pointer-Klasse oder einer Wrapper-Klasse für Pointer-Funktionen gehört imho zu den Ausnahmefällen)

5. Globale Variablen und Funktionen sind verboten. (Statische Funktionen müssen mindestens in einen namespace)

Bei globalen Variablen gebe ich dir recht (und Ausnahmen sollten wirklich genau begründet werden), aber was hast du gegen globale Funktionen?

6. Design von oben nach unten -> Erst wird die main()-Funktion implementiert, dann eine andere, die von main() aufgerufen wird usw. => Es dürfen nur Klassen/Funktionen/Memberfunktionen/Membervariablen implementiert werden, die aus bestehendem Code aufgerufen werden)

Das ist nur begrenzt sinnvoll - gerade bei weitläufig verwendeten Klassen dürfte es schwierig sein, dort nachträglich etwas zu ändern. Überleg' dir lieber beim Schreiben der Klassen-Schnittstelle, was diese Klasse eigentlich können muß. Die nötigen Methoden stellst du dann bereit - und entscheidest später, welche dann wirklich verwendet wird (sowas kann sich im Lauf der Entwicklung ändern).

7. Variablen in Klassen dürfen nicht public sein.
8. Kein goto.

Die beiden Punkte würde ich wieder unterstützen (ebenfalls mit der Möglichkeit für gut begründete Ausnahmen).

[hustbaer]

Zu (2) nochmal: ich halte auch das Limit 5-10 für viel zu niedrig. 20-30 klingt für mich eher OK.

Und es kommt immer drauf an was die Funktion macht. Funktionen wie Konstruktor/Init() einer Dialogklasse werden einfach lange. Das künstlich zu unterteilen macht IMO gar keinen Sinn.

Alle Teile rausziehen die man *sinnvoll* rausziehen kann, Rest bleibt drin.

[EOutOfResources]

Und ein Getter oder ein Setter stehen leer da.

[Bashar]

Ich halte nicht viel von Coderichtlinien.

Nehmen wir das Beispiel mit der Einschränkung der Funktionslänge. Das wird ja hier im Forum schon lange vertreten und ist auch sinnvoll: Eine Funktion sollte höchstens 6 Zeilen lang sein. Aber was soll passieren, wenn mal eine Funktion länger ist? Mit Coderichtlinien geht der Entwickler hin und macht auf Teufel komm raus 6 Zeilen daraus. Dabei soll die Regel ihn eigentlich nur dazu konditionieren, kurze Funktionen zu bevorzugen. Bei zu langen Funktionen muss ihm unheimlich werden und es ihm in den Fingern jucken, sie aufzuteilen, wenn das möglich ist.

Oder das mit der Dokumentation von Funktionen. Wir haben für ein Projekt mal ein Tool angeschafft, das das prüft. Ergebnis: Die Leute schreiben irgendwas hin, das den formalen Richtlinien entspricht, aber inhaltlich belanglos ist, das Wesentliche nicht trifft, oder sogar falsch ist! Im Ergebnis ist das Tool kontraproduktiv, denn falsche Kommentare sind schlimmer als keine Kommentare.

So sehr ich sehe, dass das mit Coderichtlinien adressierte Problem dringend ist, ich halte sie für das falsche Mittel.

(Das begrifft nicht Code-Konventionen, auf die man sich nur einigen muss, wie z.B. Wahl von Bezeichnern oder Einrückung.)

[StellerFragen]

Wie würde denn so ein Kommentar aussehen, der die Funktionalität einer Funktion beschreibt? Ich habe mal gerade bei Qt nachgesehen. Die machen das so:

/*!
Returns true if \a n and this named node map are not equal;
otherwise returns false.
*/

Gibts da einen Standard wie so ein Kommentar auszusehen hat? Was macht z.B. das Ausrufezeichen oder das \a?

[Shade Of Mine]

StellerFragen schrieb:

Gibts da einen Standard wie so ein Kommentar auszusehen hat? Was macht z.B. das Ausrufezeichen oder das \a?

Je nachdem welches Tool zum erstellen der Doku verwendet wird. Beliebt sind JavaDoc-Like Tools wie zB Doxygen.

[CStoll]

StellerFragen schrieb:

Wie würde denn so ein Kommentar aussehen, der die Funktionalität einer Funktion beschreibt?

Es gibt ein paar quasi-Standards für solche Kommentare, da kann man dann z.B. doxygen oder ähnliche Programme auf den Code loslassen, um sich eine Dokumentation der Library zusammenstellen zu lassen.
Inhaltlich sollte der Kommentar ausführlich genug sein, damit ich weiß, wozu und wie ich diese Funktion einsetzen kann. Außerdem sollte das Format bei allen Kommentaren halbwegs einheitlich aufgebaut sein.

[Eisflamme]

Ansonsten ist fast alles zu strikt und gleichzeitig nicht vollständig, da wird das Augenmerk fast überall auf die falschen Dinge gesetzt imo.

1. Also ich nehme auch an, Du meinst, dass das zusätzlich dazu kommt neben dem, was normalerweise da reinsoll. Ersteller finde ich super, Teststatus zweifelhaft (jemand ändert die Klasse und muss dann den Teststatus wieder löschen? Oder man hält die ganze Hierarchie dort vor; das würde ich irgendwie separat machen) Und

2. 5-10 Zeilen find ich auch zu wenig. Wenn wir eine doppelte for-Schleife haben, und { und } jeweils in eine eigene Zeile schreiben, sind bereits 6 Zeilen weg. Jetzt darf ich in die unterste Ebene nur 4 Zeilen schreibe? Ich finde es in Ordnung zu sagen, eine Funktion/Methode sollte nur eine Seite umfassen (also vll. 40-50 Zeilen); 5-10 find ich viel zu wenig.

3. KA, was gegen rohe Pointer spricht. Wenn ich einen Container baue, der ausdrücklich nur Verweise auf nicht-verwaltete Objekte beinhalten soll und gleichzeitig klar ist, dass der Container abgebaut wird, bevor der verwaltende Container der Objekte abgebaut wird, ist das imo absolut in Ordnung. Auch andere Verweise brauchen oft keine Smartpointer, dann baue ich auch einfach keine ein.

4. Was ist so schlimm an globalen Variablen und Funktionen? Ich stecke immer alles in einen namespace, aber das gilt genau so für meine Klassen. Und da ich nicht jede Funktion in eine Klasse stecke, weil es oft keinen Sinn macht, ergeben sich zwangsläufig (namespace-)globale Funktionen. Das ist absoluter Standard imo.

5. Und wie willst Du das bewerkstelligen, wenn ein großes Team verschiedene Module bearbeitet? Sollen alle über jede einzelne Funktion ständig sprechen? Im Nachhinein ein paar Funktionen rauszustreichen erscheint mir da sinnvoller. Aber ob das so viel bringt...

6. Es gibt doch ein paar seltene Fälle, in denen goto angebracht ist, was spricht dagegen? Ich find ein Verbot davon nicht gut.

Noch was:
Ich glaube, die Codingrichtlinien muss man auch in Abhängigkeit davon abstellen, wie erfahren das Team ist und wie gut man es kennt. Wenn Du mit Anfängern arbeitest, sodass Du dazu sagen musst, dass goto fast immer schlechter Stil ist, dann musst Du noch eine breite Palette von weiteren Dingen klären...

Wenn Du hingegen davon ausgehst, dass die meisten mitdenken und sich im C++-Umfeld bereits gut auskennen, brauchst Du eine ganze Menge der Restriktionen gar nicht erst.

[seldon]

Ich stimme generell Bashar zu. Über strenge Richtlinien ärgert sich das ganze Team, und sie führen zu kontraproduktiven Ausweichmanövern. Ich halte es für sinnvoller, zwischen Unterprojekten klare Schnittstellen (mit Unit-Tests!) zu definieren und die jeweils zuständigen selbst entscheiden zu lassen, was für ihren Teil am sinnvollsten ist - die wissen das im Zweifel eh am besten. Allenfalls kann es sinnvoll sein, Empfehlungen zu geben, und die können naturgemäß nicht sehr spezifisch sein.

Konkret zu den aufgezählten Punkten:

1.) Kommentare sind prinzipiell eine gute Sache, aber nur da, wo es auch etwas zu kommentieren gibt. Schnittstellen müssen natürlich gut dokumentiert sein (doxygen o.ä. empfiehlt sich), und wenn eine Backend-Funktion etwas macht, was nicht auf den ersten Blick als solches erkennbar ist, ist es geradezu fahrlässig, Kommentare zu unterlassen. Nichtsdestoweniger ist es ausgesprochen frustrierend, wenn Kommentare für jede Funktion, egal wie trivial, verlangt werden (insbesondere in Zusammenhang mit Punkten 2 und 7), und das wird zu massig copy&paste kurzer Codeteile führen. Auch musst du sehr vorsichtig sein, was du in Kommentaren verlangst. Der Autor bzw. die Autoren einer Funktion sind besser über das Versionskontrollsystem feststellbar, der Teststatus sollte durch Unit-Tests festgestellt werden. Und was soll das mit dem Sicherheitsstatus? Niemand wird eine Funktion schreiben, von der er weiß, dass sie das System zusammenkrachen lassen kann. Nein, Kommentare sollen bei Schnittstellen festhalten, wie sie zu benutzen sind und in Implementationsdetails erklären, was man sich bei der Umsetzung gedacht hat.

2.) Funktionen sollten kurz sein. Den Entwickler auf eine Zeilenanzahl festzunageln, ist indes unsinnig - die Zeilenanzahl ist eine schlechte Metrik für Codelänge, und es gibt Zusammenhänge, die sich nicht in 10 Zeilen erschlagen lassen. Wenn eine Fuktion länger als 20-30 Zeilen wird, ist das ein Warnsignal, aber auf Ausnahmen von der Regel muss man vorbereitet sein.

3.) Das soll ein Witz sein, oder?

4.) Rohe Zeiger sind zur Ressourcenverwaltung nicht geeignet, aber sie komplett zu verbieten, schießt weit über das Ziel hinaus - ganz besonders unter Performance-Gesichtspunkten. Soll man jedes Array in einen Vektor stopfen, bloß weil man sonst Zeiger in Standardalgorithmen stopfen müsste? Man kann C++ wie Java schreiben, aber wenn man das vorhat, hat man die falsche Sprache für das Projekt gewählt.

5.) Bei globalen Variablen stimme ich zu, aber alle Funktionen an Klassen zu ketten, scheint mir wenig sinnvoll. Der Satz über Java im vorherigen Punkt gilt auch hier - wofür gibt es denn Namensräume? Gegen globale Konstanten (echte Konstanten, zwecks Threadsicherheit) ist auch nichts zu sagen - es macht wenig Sinn, eine Lookup-Tabelle oder einen TST jedes mal neu aufzubauen, wenn man etwas nachschlagen will.

6.) Genau umgekehrt wird ein Schuh draus. Wie willst du denn Teile zu einer main zusammenfügen, die noch gar nicht existieren? Meiner Erfahrung nach ist es sinnvoller, von innen nach außen vorzugehen - wenn du eine Kalenderanwendung schreibst, fängst du mit der Datumsklasse an. Dann lässt sich bestehender Code auch besser (bzw. überhaupt) testen.

7.) Generell richtig, mindestens für öffentlich sichtbare Klassen. In Implementationsdetails tut's auch mal ein nacktes Struct.

8.) D'accord.

[otze]

wxSkip schrieb:

2. Funktionen sollten maximal 5-10 Zeilen enthalten (es wird soviel gekapselt wie möglich)

Insbesondere beim numbercrunching kommt man da nicht weit. Da hast du dann permanent die Wahl zwischen: eine Funktion mit 15 Parametern oder dinge doppelt berechnen. Super. Und all das nur, weil eine Funktion nicht länger als 10 Zeilen sein darf.
Und selbs tin Anwendungslogik schätze ich, dass es den Code mit Hunderten von Bezeichnern zu müllen würde.

[brotbernd]

pumuckl schrieb:

1. was muss die Klasse können?
2. -> öffentliches Interface festlegen
3. Unit-Tests schreiben und laufen lassen
4. -> natürlich Linkerfehler
5. implementieren
6. Unit-Tests laufen lassen
7. goto 6)

1. Unit-Tests schreiben und laufen lassen -> Fail
2. Minimale + falsche Implementierung schreiben
3. Unit-Tests laufen lassen -> Fail, Test funktioniert
4. Minimale + richtige Implementierung
5. Unit-Tests laufen lassen -> Pass
6. Refactoring
7. Unit-Tests laufen lassen
8. goto 6)

[pumuckl]

brotbernd schrieb:

pumuckl schrieb:

5. implementieren
6. Unit-Tests laufen lassen
7. goto 6)

6. Refactoring
7. Unit-Tests laufen lassen
8. 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

[wxSkip]

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.