Codingstandards @UNI: Was meint ihr dazu?

Hallo zusammen,

ich hatte heute eine nette Vorlesung zum Thema Programmierung wo uns eine nicht wirklich kompetente Lehrperson über die Codingstandards aufklärte.
Dabei sind mir mehrere Dinge als sehr sinnlos erschienen.

Siehe:

Methoden die eine Boolean-variable als Parameter haben sollten mit "be" beginnen.
z.B: beOff();

Methoden die ein Object in einen anderen Typ umwandeln und diesen returnen sollten mit "as" beginnen.
z.B. asString();

Methoden müssen kurz sein, nur eine Aufgabe erfüllen und dabei komplett auf dem Bildschirm platz finden.
Der Standard ist bei max. 10 Zeilen

Keine Tabs verwenden. Es ist viel besser einfache Leerzeichen zu verwenden.
Dabei ist es auch wichtig dass man monospaced fonts verwendet.
Als Standard sollte man 8 Leerzeichen verwenden.

Man darf nicht öffnende Klammern in einer neuen Zeile tun.
Es ist viel besser diese am Ende am vorherigen statement anzuhängen.
Also so
if(true){
}

Wenn man es so wie es in C# üblich ist in eine neue Zeile einfügt so ist das ein Fehler.

Niemals zwei Objekte in einer Zeile deklarieren.
also
int i,j;
ist falsch. Man muss das so machen
int i;
int j;

Das Ganze habe ich jetzt vom Englischem ins Deutsch übersetzt aber der Inhalt ist der selbe wie der auf den Slides.

Bezogen ist das Ganze auf Java jedoch das Meiste was ich hier aufgeschrieben habe ist doch einfach total bescheuert.

und diese ganzen Regeln müsste ich jetzt bei meinem Projekt anwenden =)

Was sagt ihr dazu? Macht ihr das auch alles so? ^^

Grüsse
Michael

Das mit der Klammernsetzung aus Java kenne ich auch so, ist aber eher Geschmackssache, wuerde ich sagen.

In meinen Augen sind diese Vorgaben auch äußerst unsinnig. Gerade sowas wie die Klammerung soll ja die Lesbarkeit fördern, was mit deinem geposteten Beispiel m.E. nach verfehlt wird.

Methoden müssen kurz sein, nur eine Aufgabe erfüllen und dabei komplett auf dem Bildschirm platz finden.
Der Standard ist bei max. 10 Zeilen

So eine ähnliche Vorgabe hatten sie uns in der Uni auch mal gegeben. Allerdings war es bei uns großzügiger bemessen. Da hieß es eine Methode sollte nicht länger als ein Bildschirm sein.

Alles im allen finde ich, dass diese Regeln eher hindern, als das sie förderlich sind.

Hallo michlG,

Also einige der "Codingstandards" hab ich noch nie gehört/halte sie für überflüssig.

Methoden die eine Boolean-variable als Parameter haben sollten mit "be" beginnen.
z.B: beOff();

🙄

Methoden die ein Object in einen anderen Typ umwandeln und diesen returnen sollten mit "as" beginnen.
z.B. asString();

War es nicht ToString() ?

Methoden müssen kurz sein, nur eine Aufgabe erfüllen und dabei komplett auf dem Bildschirm platz finden.
Der Standard ist bei max. 10 Zeilen

Ob das so eine gute Idee ist? Dann wären es ja manchmal hunderte Methoden....

Keine Tabs verwenden. Es ist viel besser einfache Leerzeichen zu verwenden.
Dabei ist es auch wichtig dass man monospaced fonts verwendet.
Als Standard sollte man 8 Leerzeichen verwenden.

VS und ich verwenden immer 4 !?

Man darf nicht öffnende Klammern in einer neuen Zeile tun.
Es ist viel besser diese am Ende am vorherigen statement anzuhängen.
Also so
if(true){
}

Wenn man es so wie es in C# üblich ist in eine neue Zeile einfügt so ist das ein Fehler.

Versteh ich nicht.

Niemals zwei Objekte in einer Zeile deklarieren.
also
int i,j;
ist falsch. Man muss das so machen
int i;
int j;

mfg.
markus111

Hallo michlG,

solche Fragen scheinen momentan in Mode zu sein. Siehe auch Wie steht ihr zu diesen Clean-Code-Empfehlungen?

herbivore

Hallo zusammen,

thx für eine Antworten.
Das ist ein Zeichen dass ich da nicht der Einzige bin der einige der Regeln total überflüssig findet.

Jetzt sind mir noch ein paar Dinge in den Slides aufgefallen.

Eigenschaften müssen immer Singular (d.h. Player und nicht Players) sein.

Wenn man also einen Array von der Klasse Player hat so darf die Variable nicht "players" heissen.
Stattdeseen muss man es myListOfPlayer nennen.
Also Player[] players; ist falsch
Player[] myListOfPlayer; ist richtig

Weiters verwendet man bei den Eigenschaften verschiedene Prefixe.
thePlayer => es gibt nur eine Instanz von der Klasse Player
myPlayer => meine Instanz von der PlayerKlasse
aPlayer => eine Instanz von der Player Klasse

Grüsse
Michael

Das einzige, was mir aufstösst, ist das "man muss es so machen". Üblicherweise haben Coding Standards gute Gründe, in den Bereich fällt zumindest die Regel mit den Leerzeichen statt Tabulatoren (und die vorgegebene Anzahl Leerzeichen - bei uns sind das vier). Wenn der Dozent die Regeln nicht auch begründen kann - das sollte zumindest bei "beOff()" schwerfallen und bei "asType()" statt "toType()" komplett in die Hose gehen - dann ist da schon etwas faul.

Die Regeln sind im Gegensatz zu dem, was du denkst, nicht überflüssig 😃. Vielleicht will er nur eure Programme besser vergleichen können? Ich denke nicht, dass er behauptet, dass diese seine Standards weltweit gültig wären 😉.

LaTino
PS: "as" deutet auf eine Behandlung einer Variablen als von einen anderen Typ hin, nicht auf eine Umwandlung. Daher ja auch "var myResult = result as Object;".

Hi michlG,

ich finde auch, dass die Regeln etwas zu absolut formuliert sind.
Besonders bei den Bezeichnern sollte es danach gehn, was am Verständlichsten ist.
So kann es ja auch in manchen Sprachen Sinn machen, doch noch den Typ als Präfix zu vermerken. Auch bei Sprachen ohne statischer Typbindung sollte man wohl andere Bezeichner wählen. Was mir zu dieser Thematik einfällt: "God is Real, unless declared Integer."

Das mit den Tabulatoren macht eigentlich schon Sinn, da nicht überall Tabs gleich groß sind.

Und was das "Zwei Objekte in einer Zeile deklarieren angeht", bin ich leider selbst auch schon auf die Nase gefallen.

Folgender C/C++ - Code

int* ptr1, ptr2;

ist nämlich äquivalent zu

int* ptr1;
int ptr2;

was jedoch nicht von mir beabsichtigt war.
In C# ist das anders, dort sind beides Zeiger - korrekterweise, wie ich finde. Manche schreiben ja auch int ptr anstatt int ptr. Jedoch find ich schon, dass das Stern zum Typ gehört, da ptr vom Typ "Zeiger auf int" ist. Aber gut, das is ziemlich offtopic.

Jedenfalls kann man solchen Dingen aus dem Weg gehen, wenn man sie einzeln deklariert. Und da fast jeder Programmierer auch mal mit C/C++ konfrontiert wird, kann man das m.E. auch gern als "Regel" übernehmen.
Aber auch hier sollten Ausnahmen diese (eben nicht unumstößliche) Regel bestätigen.

beste Grüße
zommi

Hallo Latino,

ja dass die Codingstandards normalerweise einen Sinn haben ist mir schon klar.
Und ich finde es auch wichtig dass man sich daran hält, denn es erleichtert normalerweise wirklich die Arbeit und macht das Ganze übersichtlicher.

Aber wenn jemanden die Referentin Regeln sagt dass Methoden nicht länger als 10 Zeilen sein dürfen so fragt man sich schon nach dem Sinn.
Natürlich ist es sinnvoll den Methoden immer nur eine Funktion zu geben aber meistens reichen da 10 zeilen nicht aus.

Auch die Regel dass wir Tabulator nicht verwenden dürfen. Stattdessen sollen wir 8 mal auf Space klopfen 🤔
Und richtig begründen konnte sie uns leider auch nicht warum man Tabulator nicht verwenden soll.
Was passiert denn wenn man 100 Zeilen einrücken will. Mit Tab markiert man alle und drückt tab. Hingegen bei den Leerzeichen muss man das bei jeder Zeile einzeln machen.
EDIT:
Ok beim VS kann man das AFAIK direkt umstellen. Sodass er bei Tab automatisch Leerzeichen einfügt.

Ich denke nicht, dass er behauptet, dass diese seine Standards weltweit gültig wären

Nö von weltweit gültig hat sie nicht gesprochen. Jedoch hat sie gesagt dass das Standard ist und dass man das auch im Berufsleben so machen sollte. Also schon irgendwie weltweit 🙂

Grüsse
Michael

Aber wenn jemanden die Referentin Regeln sagt dass Methoden nicht länger als 10 Zeilen sein dürfen so fragt man sich schon nach dem Sinn.

Falsche Adresse für diese Frage. Was hat denn die Referentin geantwortet?

LaTino

Hallo LaTino,

Was hat denn die Referentin geantwortet?

Auf die Frage wieso es da diese doch sehr niedrige Begrenzung gibt hat sie gesagt dass es alles viel übersichtlicher macht und dass das einfach besser seie.
Natürlich hat sie auch gesagt dass man jeder Methode nur eine Funktion geben darf. Das finde ich auch für richtig aber ich habe ihr dann gesagt dass man oft auch Funktionen hat die man nicht so einfach in 10 Zeilen unterbringen kann.
Darauf hat sie wieder geantwortet dass man das Problem immer schön aufsplitten kann.
Darauf hin habe ich nicht mehr nachgefragt weil sie mir dann sicher nur nochmals das selbe gesagt hätte.

Also ich finde dass die nicht viel Ahnung vom Programmieren hat oder wenigstens noch nie richtig programmiert hat denn da kann man ein Problem nicht immer auf 10 zeilen aufsplitten.

Grüsse
Michael

Die Richtlinien scheinen sehr beliebig gewählt zu sein. Die Boolean-Eigenschaften kenn ich persönlich nur mit dem "Is"-Präfix. Die Klammernsetzung ist reine Geschmackssache, die Leerzeichen anstatt den Tabs haben ihre Berechtigung da so die Chance groß ist, dass der Code in einem anderen Editor genauso formatiert auf dem Bildschirm erscheint.

Ich weis nicht was ihr dort auf der Uni programmiert aber je nach Programmiersprache gibt es meiner Erfahrung nach verschiedene Stile.

Also ich finde dass die nicht viel Ahnung vom Programmieren hat oder wenigstens noch nie richtig programmiert hat denn da kann man ein Problem nicht immer auf 10 zeilen aufsplitten.

Als Hausnummer kann man die Zehn-Zeilen-Regel durchaus stehen lassen. Das ist aber weniger als harte Regel, sondern sollte man als "Warnwert" verstehen. Wenn eine Fuinktion mehr als 10 Zeilen hat, dann sollte es bei dir "klingeln" und man sollte ma schauen, ob man nicht was Refactorisieren sollte. Bestimmte Konstrukte wie z.B. Switch-Cases arten recht schnell mal in mehr als 10 Zeilen Code aus. Bei If-Ketten sieht es oftmals wieder anders aus.

Wenn immer möglich sollte eine Funktion nicht mehr als eine Bildschirmseite umfassen. Es ist nachgewiesen (an der Untersuchung habe ich selbst als Proband teilgenommen), dass das Verständnis für Code in dem Moment _rapide _abnimmt, wenn man nicht alle Zeilen einer Funktion im Ganzen im Blick hat.

Wir haben uns in der Firma auch gewissen Vorgaben geeinigt, die gerade bei größeren und Teamprojekten sehr die Lesbarkeit untereinander fördern. So beginnen alle Member mit "m", Methodenparameter mit "p" usw.
Eine Klasse wird grob gegliedert in Properties, dann die Konstruktoren und dann die Methoden, diese Blöcke jeweils alphabetisch oder funktioniell sortiert, je nach Klassengröße und (subjetivem) Sinn. Dadurch fällt es zumindest unseren Leute viel leichter, fremden Code zu verstehen.

Die 10-Zeilen-Regel finde ich ebenso quatsch. Generell sollte eine Funktion so kompakt wie möglich sein, umd die Übersicht zu wahren und den Ansatz der Objektorientierung sowie Wiederverwendbarkeit zu wahren. Aber auf Teufel komm raus zu splitten macht die Sache womöglich unübersichtlicher als notwendig.

Der Tab-Kommentar lässt mich an die Unizeiten zurück denken, wo jeder mit einer anderen Entwicklungsumgebung gearbeitet hat - vi, emacs, Eclipse, VS, ... 😄 Heutzutage kann jede vernünftige Umgebung einen "Tab" als 2, 4, 8 oder wieviel Leerzeichen auch immer umwandeln und die Einrückungen entsprechend behandeln. Ja, Leerzeichen sind in dem Sinne sinnvoll, allerdings sollte das die Entwicklungsumgebung unterstützen. Kein großes Projekt wird heutzutage noch in einem Texteditor programmiert. ^^

Das wollte ich nur mal loswerden. 😃

Hallo zusammen,

Als Hausnummer kann man die Zehn-Zeilen-Regel durchaus stehen lassen. Das ist aber weniger als harte Regel, sondern sollte man als "Warnwert" verstehen. Wenn eine Fuinktion mehr als 10 Zeilen hat, dann sollte es bei dir "klingeln" und man sollte ma schauen, ob man nicht was Refactorisieren sollte. Bestimmte Konstrukte wie z.B. Switch-Cases arten recht schnell mal in mehr als 10 Zeilen Code aus. Bei If-Ketten sieht es oftmals wieder anders aus.

Wenn immer möglich sollte eine Funktion nicht mehr als eine Bildschirmseite umfassen. Es ist nachgewiesen (an der Untersuchung habe ich selbst als Proband teilgenommen), dass das Verständnis für Code in dem Moment rapide abnimmt, wenn man nicht alle Zeilen einer Funktion im Ganzen im Blick hat.

Ja da hast du sicherlich recht. Man sollte die Methoden immer funktional aufsplitten aber da eine Begrenzung von 10 Zeilen festzulegen ist schon zu viel des Guten.
Denn oft macht es einfach keinen richtigen Sinn die Methode nochmals aufzuteilen.
Der Code wird dadurch teilweise noch unübersichtlicher.

Aber normalerweise werden die meisten Methoden schon in bis zu 20 Zeilen platz finden und das kann man auch noch auf einem Bildschirm anzeigen.

Der Tab-Kommentar lässt mich an die Unizeiten zurück denken, wo jeder mit einer anderen Entwicklungsumgebung gearbeitet hat - vi, emacs, Eclipse, VS, ... 😄 Heutzutage kann jede vernünftige Umgebung einen "Tab" als 2, 4, 8 oder wieviel Leerzeichen auch immer umwandeln und die Einrückungen entsprechend behandeln. Ja, Leerzeichen sind in dem Sinne sinnvoll, allerdings sollte das die Entwicklungsumgebung unterstützen. Kein großes Projekt wird heutzutage noch in einem Texteditor programmiert.

Die Einrückung mit Leerzeichen hat schon ihren Sinn, jedoch finde ich 8 Leerzeichen viel zu viel. Wenn man da 3-4 Einrückungen macht ist man schon am rechten Bildschirmrand 😃

Vor ein paar Tagen wuden uns dann noch ein paar nette Codingstandards mitgeteilt.
Wir dürfen nicht wie es für Schleifen üblich ist i als Zählvariable nehmen.
Stattdessen müssen wir die Zählvariable counter, mycounter, innercounter, usw nennen

Grüsse
Michael

Stattdessen müssen wir die Zählvariable counter, mycounter, innercounter, usw nennen

Würde ich aber auch so machen. Bei verschachtelten Schleifen kommt man sonst beim Lesen des Codes möglicherweise durcheinander.
Ein

for (int byteIndex = 0; ...
  for (int listIndex = 0; ...

ist halt übersichtlicher als

for (int i = 0; ...
  for (int j = 0; ...

Wir dürfen nicht wie es für Schleifen üblich ist i als Zählvariable nehmen.
Stattdessen müssen wir die Zählvariable counter, mycounter, innercounter, usw nennen

Sehr gut. Bei uns MUSS die Zaehlvariable "index" respektive "outerIndex", "innerIndex" und so weiter heißen. Sprechende Variablennamen sind nicht so sinnlos, wie es auf den ersten Blick aussieht. Manchmal ist das, was "üblich" ist, eben doch keine gute Praxis.

LaTino

Also wenn man immer mit i anfängt und auch nur i, j, k, etc verwendet, kann jeder auch direkt sehen, was damit gemeint ist und in welcher ebene der Schleifen-Verschachtelung man sich befindet... Ich finde, dass man bei Indizes gut und gern auch sprechende Variablennamen verzichten kann, insbesondere, da ja i, j, k, etc auch in anderen Bereich als Laufindizes benutzt werden. Zumal solch Konstrukte wie innerIndex konsequent durchgeführt auch zu ziemlichen "Monster"-Namen führen können (und ohne Konsequente Durchführung find ich das dann wieder sinnfrei, Variablen sprechende Namen zu geben), denn ob man nun "innerInnerInnerIndex" oder "k" schreibt ist schon ein Unterschied ^^

Ich finde, dass man bei Indizes gut und gern auch sprechende Variablennamen verzichten kann, insbesondere, da ja i, j, k, etc auch in anderen Bereich als Laufindizes benutzt werden.

Natürlich nur bei den Kollegen, die nicht auf "j" verzichten, weil es dem i so ähnlich sieht. Oder, falls durch eine Refakturierung die innere Schleife mal zur äußeren wird, und die Indizes nicht umbenannt werden (ob i oder j, ist doch egal - wenn die Dinger aber innerIndex und outerIndex o.ä. heißen, ist es NICHT mehr egal).

Zumal solch Konstrukte wie innerIndex konsequent durchgeführt auch zu ziemlichen "Monster"-Namen führen können (und ohne Konsequente Durchführung find ich das dann wieder sinnfrei, Variablen sprechende Namen zu geben), denn ob man nun "innerInnerInnerIndex" oder "k" schreibt ist schon ein Unterschied ^^

Ja, ein Tastenanschlag dank IntelliSense 😉. Ausrede!

LaTino
EDIT: bevor das wieder zur einer Krümel-Diskussion wird: jaaa, klar MUSS man es nicht machen mit den sprechenden Variablennamen. Es ist aber auch nicht so sinnlos, wie es aussieht.

So, auch mal meine Meinung zum Rest:

Methoden die eine Boolean-variable als Parameter haben sollten mit "be" beginnen.
z.B: beOff();

Sehe darin keinen Vorteil, zumal man dann konsequenterweise Methoden für alle Parametertypen Präfixe geben müsste...

Methoden die ein Object in einen anderen Typ umwandeln und diesen returnen sollten mit "as" beginnen.
z.B. asString();

Also ToType find ich da deutlich sinniger und solche Umwandlugnsmethoden wird man vermutlich eh so nennen, oder?

Methoden müssen kurz sein, nur eine Aufgabe erfüllen und dabei komplett auf dem Bildschirm platz finden.
Der Standard ist bei max. 10 Zeilen

Natürlich sollte man versuchen ne Methode zu kurz zu halten, wie möglich, aber ne feste Begrenzung auf 10 Zeilen? Wenn ich da an manche Methoden bei mir in der Firma denke, bei denen physikalische und chemische Dinge berechnet werden sollen... Da reichen 10 Zeilen manchmal nur dafür, dass man die Variablen einigermaßen sinnig und übersichtlich deklariert ^^
Und zum Thema Splitten: Also Methoden, die nicht als Schnittstelle der Klasse dienen sollten nur dann existieren, wenn sie mehrfach verwendet werden, denn genau dafür gibt es Methoden. Einfach einen Teil auf einer Methode A (bspw. eine foreach-Schleife) in einer andere Methode B auszulagern, die aber nur von A und auch nur an einer Stelle aufgerufen wird, ist Schwachsinn. Sobald B aber mehrfach verwendet wird, ist es natürlich eine gute Idee dieses Funktionalität auszulagern.

Keine Tabs verwenden. Es ist viel besser einfache Leerzeichen zu verwenden.
Dabei ist es auch wichtig dass man monospaced fonts verwendet.
Als Standard sollte man 8 Leerzeichen verwenden.

Sinnvolle Forderung, eben, damit man den Quelltext auch in verschiedenen Umgebungen gut lesen kann, aber auch nicht so wichtig, da das meist ja eh über die IDE einstellbar ist.

Man darf nicht öffnende Klammern in einer neuen Zeile tun.
Es ist viel besser diese am Ende am vorherigen statement anzuhängen.
Also so
if(true){
}

Persönliche Vorliebe. Meiner Meinung nach liest es sich so schlechter, aber das sieht jeder anders ^^ In Java ist es üblich, also in diesem Kontext okay.

Niemals zwei Objekte in einer Zeile deklarieren.
also
int i,j;
ist falsch. Man muss das so machen
int i;
int j;

Kommt darauf an. Wenn ich an o.g. Berechnungsmethoden mit einigen Variablen denke, dann werden die auch teilweise in einer Zeile deklariert, also bspw.:

private double
            a1, a2,
            b1, b2, b3, b4, b5,
            ca, co, co2, cp, cs,
            d, dc, dv;

(ich weiß, die Variablen sehen nicht "sprechend" aus, sind aber die Bezeichnungen in den jeweiligen Formeln, und deshalb so besser zu verstehen ^^)

Also Variablen, die zusammengehören, kommen in eine Zeile (hier bspw. auch alphabetisch geordnet). Zumal diese Forderung auch der Forderung der 10-Zeilen-Methode abträglich ist.

@Latino: Ging auch nicht nur um die Schreibarbeit, sondern um die Lesbarkeit, und man erkennt (so jedenfalls ich) schneller, wie weit ein Buchstabe vom "i" weg ist, als wieviele "inner" in innerInnerInnerInner... steckt ^^ Aber letztlich ists ja meistens eh einem selbst überlassen (ein anderer Grund für "i" ist bei mir, dass ich manchmal "index" oder "counter" schon für was anderes gebrauche und dann auch keine Lust habe mir nen treffenden Namen zu überlegen ^^).

Naja, ich sehe es so: Jeder Boss erstellt seine Regel, ob er sich auf eine Diskussion einläßt ist 'ne andere Sache, von daher, wenn man in einem Team arbeitet, muss man die Regel des Teams einhalten, ob das nun beWhatever oder b_Whatever oder bWhatever ist, wichtig ist nur, dass alle sich an der vorgegebenen Konvention halten und somit der produzierte Code für alle einheitlich und lesbar ist.

In meinem Berufsleben habe ich bisher in 4 Firmen gearbeitet und jedes Mal mit einer anderen Code-Konvention zu tun gehabt, ob ich mich mit der Vorgabe anfreunden kann, hat keiner gefragt; ich muss mich halt danach richten und alle sind zufrieden 🙂