IPS Programming style guide.

Hallo alle zusammen.

Das Thema „Programming style guide“ wird in unserer Firma „groß geschrieben“.

Wir haben uns angelehnt an den „Programming style guide“ von Siemens.
Dieser wird von uns erweitert und gepflegt.

Dort ist genauestens beschrieben wie zu programmieren ist und zu dokumentieren ist.

Beispiel:

  • Wie sollte der Name eines Parameters aussehen.
    zum Beispiel: Am Anfang steht immer ein kleiner Buchstabe keine Unterstriche und in CamelCase Schreibweise.

oder:

Konstanten werden immer in Grossbuchstaben mit Unterstrichen geschrieben -> ROLLO_AUF

Eventuell kann man ja hier sowas zusammentragen.
Auch nur als Anlehnung nicht als muss gedacht!!

Hier mal mein Dokumentations-Grundgerüst für Scripte:


<?
/** Scriptname
* @author Martin Heinzel
* @date tt.mm.jjjj
* @version x.y.z
*
* Beschreibung:
*
*
*
* Änderungen
* ----------
* @date tt.mm.jjjj
* @version x.y.z
*
* Beschreibung:
*
*/

/**
* Variablen Deklaration --------------------------------------
*/

/**
* ID's
*/


/**
* Variablen
*/


/**
* Konstanten
*/


/**
* Variablen Deklaration ENDE ---------------------------------
*/

/**
* Main --------------------------------------------------------
*/


/**
* Main ENDE ---------------------------------------------------
*/

/**
* Funktionen --------------------------------------------------
*/

/** Funktionsname
* @param[in,out] Name Beschreibung
* @param[in,out] Name Beschreibung
* @return Beschreibung
*/

/**
* Funktionen ENDE ----------------------------------------------
*/
?>

Was haltet Ihr davon?

Netz-Fundstücke:

In PHP richtig dokumentieren
PHP Coding Style Guide
Variablen richtig benennen obwohl die Ungarische Notation nicht mehr zeitgemäß ist. (da streiten sich aber auch die Geister!! )

Ich finde die Idee gut. Da ich sehr wenig programmiere und mir viel aus anderen Scripts „borge“ geht bei mir oft alles durcheinander.:rolleyes:

Die Idee an sich ist gut.
Nur funktioniert sowas in der Community kaum.
Du brauchst sowas wie ein Audit oder ein Review für den Code.
Und da wird’s schwierig bei Communitys.
Hier geht es um Hobby und da kann man eben nicht die selben Maßstäbe wie in Firmen anlegen.

Gruß
Dieter

An sich eine schöne Idee, aber mit der Umsetzung wird es eher nichts :smiley:

Man kann froh sein, wenn alle möglichst viel dokumentieren. Ich bin auch nicht sooo der dokumentier-Freund :smiley: Ich gebe mir Mühe den Code immer „nachvollziehbar“ zu schreiben und wenn es etwas zu beachten gibt, dann gibt es entweder oben im Skript Infos (siehe SonosBY) oder es gibt eine Readme die ich möglichst gut schreibe (siehe meine Module).

Aber da wirklich einen Standard durchsetzen…öhm…nö :smiley: Da halten sich dann eine Hand voll Leute dran und andere schreckt es am Ende eher ab, weil die eh kaum was machen und dann noch so viel und genaue dokumentieren. Oder sie trauen sich dann nicht ihren Kram zu posten, weil es eben nicht nach dem „Standard“ geht usw…

So viel zu meiner Meinung :slight_smile:

Grüße,
Chris

Davon halte ich sehr viel, aber :frowning: leider haben meine Vorschreiber recht.

Ich versuchs bei meinen Scripten auch, verschiebs dann wieder auf irgendwann, wenn ich Zeit habe.
Und ich bin Rentner und hab keine Zeit.:smiley:

Coding Style Guides funktionieren in Teams nur in Verbindung mit Code Reviews. In meiner Firma machen wir das natürlich so. Aber einen Standard hier für alle anzugeben wird sicher nicht funktionieren.

Viele sind hier wahrscheinlich auch keine professionellen Programmierer, und der Code wird dann durch einen Coding Style auch nicht besser :slight_smile:

Wer sauberer programmieren lernen will lege ich zum Beispiel dieses Buch ans Herz: Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin: Amazon.de: Robert C. Martin: Fremdsprachige Bücher

Auf den ersten Blick etwas übertrieben, was da „vorgebetet“ wird, aber im Kern sehr viel Wahres drin.

So hatte ich das jetzt nicht gemeint. :eek:

Ihr habt alle recht. Für die meisten ist das Hobby.
Für mich unter anderem auch.

Ich hatte auch mehr an einem Nachschlagewerk gedacht.
An den man sich anlehnen kann aber nicht muss.

Es ist ja auch nur ein Style guide.

Na ja. War ja auch nur so ne Idee. :o

Ich werde oben noch ein paar Netz-Fundstücke hinterlegen und gut is.

Gerade der Anfang deines Beispiels ist für eine spätere Veränderung sehr wichtig.
Was noch gut dazu passen würde, ist der Link, der das Script beschreibt.
Seitdem ich den im Script notiere, habe ich es bei Ergänzungen oder Veränderung leichter.