Regeln

[IASKMYSELF]

Aber wer sagt mir denn dass die gefundenen Regeln auch richtig sind? Nur weil es alle so machen heisst es ja nicht dass es auch stimmen muss...

[Der Kommunist]

Mit Regeln ist hier nicht gemeint, ob etwas richtig oder falsch ist, sondern diese Regel beschreiben mehr oder weniger abstrakt, die Code strukturiert ist. Anhand eines Matching mit weiteren Regeln, welche eine Information ueber "richtig/falsch/unsauber/gefaehrlich" beinhalten, kann die Richtigkeit oder Sicherheit von Code geprueft werden. Sollte eigentlich klar sein, wenn man mal ueber den Artikel nachdenkt.

[IASKMYSELF]

das ist mir schon klar, aber trotzdem, muss ja nicht heissen das die struktur dann gut ist.

[mosi]

IASKMYSELF schrieb:
--------------------------------------------------------------------------------
> das ist mir schon klar, aber trotzdem, muss ja nicht heissen das die
> struktur dann gut ist.


Das Programm gibt nur einen Hinweis. Ob du als Entwickler was unternimmst, ist deine Sache. Solche Programme sind auch nicht perfekt, und nur dem Programm zu trauen wäre gefährlich. Aber wenn du als Entwickler dies nicht nachvoll ziehen kannst ob dies gut oder schlecht ist, dies wäre noch viel gefährlicher...

[neues thema]

Als Projektleiter würde ich in der Firma bestimmte "Regeln" bzw. "progger-Patterns" verbieten.

Ich würde den Code auch automatisch nach Firmenstandards "beautifien" bevor er im Repository hochgeladen wird. Es ist ja nicht Aufgabe eines Programmierers, Spaces einzurücken. Das kann der beautifier.

Man sollte nicht erkennen, wer im Team den Code produziert hat.
Code sollte leserlich sein.
Laufvariablen wie x,i usw, sind erlaubt, andere Variablen werden gewarnt, wenn sie zu kurz und somit wohl nicht selbstbeschreibend sind.
Usw.
Das waren halt bisher "nur" Syntaktische Regeln.

Aber jetzt kann man dank Saarland auch strukturelle Strukturen erkennen und zuordnen.

Diese Projekte sind echt nett. Aber die Quake-3D werden sie sicher nicht verfügbar sein :-(((

[DummBatz]

Ich mag's echt nicht mehr hören: Es gibt kein Maß für LESBARKEIT! Lesbarkeit ist stets subjektiv.

neues thema schrieb:
--------------------------------------------------------------------------------
> Als Projektleiter würde ich in der Firma bestimmte "Regeln" bzw.
> "progger-Patterns" verbieten.
>
> Ich würde den Code auch automatisch nach Firmenstandards "beautifien" bevor
> er im Repository hochgeladen wird. Es ist ja nicht Aufgabe eines
> Programmierers, Spaces einzurücken. Das kann der beautifier.
>
> Man sollte nicht erkennen, wer im Team den Code produziert hat.
> Code sollte leserlich sein.
> Laufvariablen wie x,i usw, sind erlaubt, andere Variablen werden gewarnt,
> wenn sie zu kurz und somit wohl nicht selbstbeschreibend sind.
> Usw.
> Das waren halt bisher "nur" Syntaktische Regeln.
>
> Aber jetzt kann man dank Saarland auch strukturelle Strukturen erkennen und
> zuordnen.
>
> Diese Projekte sind echt nett. Aber die Quake-3D werden sie sicher nicht
> verfügbar sein :-(((

[gd800]

Du darfst ihn gerne reformatten. Gerne automatisiert beim Checkout.
Er wird ja unified formatted, bevor er eingecheckt wird.

Wir sind ja keine China-Gold-Farmer die nur 800x600-Displays haben, damit man daneben kein ICQ auf Firmenkosten laufen lassen kann.

Die Firma muss/soll sich mit dem Kunden pro Projekt auf einen Satz von Standards einigen.

Und wenn Du mal Setzer/Drucker-Regeln liest, merkst Du, das diese dafür gut sind, Texte für optimale Lesbarkeit zu optimieren.
Längere Zeilen => Abstand zwischen den zeilen größer, damit das Auge beim carriage-return nicht aus der Spur springt und die nächste Zeile trifft.

Oder achte mal auf ____ und links rechts daneben auf selber y-Pixel-Position die Zeile. Die ist quasi komplett mit Pixeln gefüllt. Das ist eine optische Schiene für das Auge. Dort ist innerhalb einer Zeile die Anzahl der schwarzen Pixel vermutlich am Häufigsten. Auch helfen sich die Buchstaben gegenseitig, sich voneinander zu unterscheiden. Wenn man mal Texte in unpassenden Schrift-Arten liest, merkt man das, wenn Buchstaben sich zu ähnlich sind oder sich nicht gegenseitig helfen sondern seltsam aussehen, wenn sie nebeneinander stehen.

Dasselbe kann man bei Code machen und messen, ob bestimmte Formatierungen besser oder schlechter zu lesen sind.

Im Repository der Code entspricht dem Kunden_Standard oder irgendeiner DIN-Norm, wenn der Kunde da keinen Wert drauf legt.
Was Du beim Auschecken machst, ist Dein Bier.
Was beim Einchecken passiert, ist Kunden-Angelegenheit.

[Klumpatsch]

Gewöhne dir an Code nach Formatierungsregeln zu schreiben und zu lesen. Wer sich nicht innerhalb von einigen wenigen Stunden umstellen kann, hat irgendwie nichts in der Programmierung zu suchen ...