---

Hallo,

ich stosse im Moment, beim Programmiern, immer wieder auf Situationen in denen ich mir wünschte, dass wir eine Programmiervorschrift hätten. Leider haben wir sowas nicht .. ;( .. Jedes grössere bzw. kleinere Unternehmen hat sowas, nur wir nicht. Leider bin ich auch noch nicht so lange dabei, dass ich weiss, auf was man warum alles achten sollte. Kann mir jemand von Euch eine Seite, Tips oder gar eine Programmiervorschrift zur Verfügung stellen? Evtl. eine kurze Erklärung dazu?

Denke da an sowas wie ... keine globalen Variablen, Konstanten und spezielle Bezeichnungen in extra Klassen (Zentralisierung), Benutzung der Ungarischen Notation, Fehlerbehandlungen (Allgemein [bei Zugriff auf Dateisystem und Datenbank]), Trennung eines Formulares nach Logic, Design und Daten, Funktionen nur in Klassen, Funktionsaufrufe mit nicht mehr als 3 Übergabeparametern, etc..

Wenn Euch noch Sachen einfallen, sei es auch noch so trivial, dann schreibt es bitte, was man unbedingt vermeiden sollte beim Programmieren.

Habt tausend Dank und viele Grüsse TP

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo TP,

interessante Sache das ... erinnert mich an die Konstruktionsvorschriften im mechanischen CAD-Umfeld. Jeder meint, man müßte das haben, jeder meint, das muss es doch schon irgendwo geben, jeder meint, dass kann doch nicht so schwierig sein, keiner hat so etwas und keiner, der es dann doch selbst gemacht hat, setzt es dann in der Praxis auch noch konsequent um.

Ist natürlich überspitzt, aber du verstehst den Sinn dahinter 

> Jedes grössere bzw. kleinere Unternehmen hat sowas, nur wir nicht.

Ich programmiere schon lange und viel, meist aber auf "Hobby"basis und eben eher aus Sicht des Ingenieurs. Aber ich hab ehrlich gesagt noch nie so Programmiervorschriften als Vorgabe gesehen. Ich persönlich finde die Idee von Best Practice angenehmer als Vorschriften ... man nimmt sich das an, was passt und man auch selbst sinnvoll anzuwenden findet und überlässt den Rest Pedanten und Normleuten      

Die meisten Dinge deiner Aufzählung sind mir zwar geläufig, viele davon mache ich, einige auch nicht oder nur, wenn es gerade passt. Was ist z.B. gegen globale Variablen einzuwenden, wenn die mir das Leben leichter machen?

Was mir jedoch unbedingt in deiner Auflistung fehlt:

• Aufgabenstellung und Zielbeschreibung
  
• Erstellen einer Grobstruktur (verbal, nicht mit diesen komischen Flussdiagrammen  )
  
• Kommentieren
  
• Kommentieren 
  
• Kommentieren  
  

Ciao,
Stefan

------------------
Inoffizielle deutsche SolidWorks Hilfeseite
http://solidworks.cad.de

[Diese Nachricht wurde von StefanBerlitz am 08. Jul. 2005 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Stefan,

vielen Dank für deine Gedanken. Bin immer offen für andere Sichtweisen und versuche diese dann aus der Sicht des anderen zu verstehen. Aber ..  .. eine Programmiervorschrift soll sich auf allgemeine Konventionen zur Programmierung stützen. Wenn man ein Projekt hernimmt, welches von mehreren Programmierern bearbeitet wird, dann kann es nicht sein, dass der eine globale Variablen benutzt, weil man auf diese von überall Zugriff hat und der nächste leitet sich das aus irgendwelchen Klassen ab. (Krasses Beispiel, aber durchaus vorstellbar) .. Dadurch wird die Lesbarkeit des Codes einfach nur schlecht und jemand der sich dann in diesen Code hineinfummeln soll kuckt dann wie ein Schwein ins Uhrwerk und das ist bei grossen Projekten einfach nicht akzeptabel.

Sicher kann man jetzt auch hergehen und sagen, wer überprüft das eigentlich und warum soll man den Leuten alles vorschreiben. Bei mehreren Programmierern und grossen Projekten macht sowas durchaus Sinn. Meine Meinung.

Ich verstehe deine Einwände sehr wohl. Habe bisher auch immer nur kleinere Projekte bearbeitet und das auch nur als Hobby .. nun ist es aber Beruf ..  .. und der Code soll sich nun auch für andere Programmierer schnell erschliessen. Deshalb hätte ich gerne solch ein Vorschrift, die nur einen gewissen Rahmen vorgibt und es reicht sogar, wenn es auf andere OOPs übertragbar ist.

Habe da auch ein paar Sachen gefunden.
VB Coding Standard
C++ Coding Standards

Das ist aber schon alles zu speziell. Werde mir da jetzt einige Sachen raussuchen, welche für uns zutreffen und ich werd mal schauen, in wie weit man sich da einigen kann. Ein Standard zu haben bringt auch lokal Vorteile! Was wäre wenn ftp oder http nicht standardisiert wären? Aber so ins Detail möcht ich es garnicht treiben .. 

Noch eine gute Seite, wo man viel über Code lesen kann, wie er nicht sein sollte .. auch an Hand von Beispielen .. http://thedailywtf.com/

Ein schönes Wochenende und viele Grüsse TP

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nochmal ich,

habe deinen Beitrag gerade nochmal gelesen und dabei sind mir noch zwei Sachen aufgefallen.

Zitat:

---

Was ist z.B. gegen globale Variablen einzuwenden, wenn die mir das Leben leichter machen?

---

Das Problem an globalen Variablen ist, dass sie in jedem Formular, Modul oder Klasse definiert sein können! Du weisst also nie, wo Sie eigentlich herkommen. Der Unterschied, wenn Du es über eine Klasse machst ist, dass Du den Namen der Klasse voranstellen musst und somit auch weisst, dass die Variable in der und der Klasse deklariert ist und es gibt dazu evtl. get und set Methoden. Erhöht unheimlich die Lesbarkeit!
Wenn Du jetzt noch einen Schritt weitergehst und nicht eine Variable, sondern ein Objekt deklarierst, dann hast Du auch dieses Objekt überall verfügbar. Das Objekt lässt sich ohne weiteres zerstören! Kommt es allerdings aus einer Klasse, muss das über eine Anfrage an die Klasse gelöst werden. Fällt unter Datenkapselung der OOP. Trennung von Daten und Logic eines Programmes.

Zitat:

---

• Aufgabenstellung und Zielbeschreibung
  
• Erstellen einer Grobstruktur (verbal, nicht mit diesen komischen Flussdiagrammen     )
  
• Kommentieren
  
• Kommentieren  
  
• Kommentieren   
  

---

Diese Punkte würde ich nochmals unterscheiden. Zum einen in die Spezifikation des Programmes (1 & 2). Das Kommentieren gehört allerdings in die Programmiervorschrift.

Gruss TP

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi.

Als weitere Anregung: Sun hat auf seiner Website noch Richtlinien fuer Java-Programmierung.

Was letzlich an Programmierrichtlinien benoetigt wird, sollte man sich selbst ueberlegen und aus den Quellen (C++, Java,...) selbst zusammenbauen.

Zur allgemeinen Diskussion:
Programmierrichtlinien sind definitiv sehr sinnvoll. Je groesser ein Projekt, desto wichtiger sind sie. Wenn man mal den Code eines Kollegen anfassen muss und derjenige wie Kraut und Rueben coded, weiss man, was man an Richtlinien hat....
Die Richtlinien sollten einerseits restriktiv genug sein, dass man fremden Code auf Anhieb ueberschauen und verstehen kann, andererseits aber auch genug Freiheit lassen, um nicht die meiste Zeit mit dem Kampf um die Einhaltung der Richtlinien zu verbringen.

Was die Codedokumentation angeht, ein Kommentar wie "Kommentieren, Kommentieren, Kommentieren" zeugt von gnadenloser Ueberkommentierung -- sowas kann den Code auch wieder extrem unleserlich machen. Eine kurze Beschreibung vor einer Methode schafft in aller Regel mehr als genug Klarheit, ein Zeilenkommentar an einer schwierigen Stelle sinnvoll platziert kann gelegentlich hilfreich sein.

Die Programmierrichtlinien sollten die Art der Kommentierung, die Art der Formatierung und Aussagen ueber Verwendung von Klassen, globalen Variablen u.ae. treffen. Zudem ist eine Aufteilung in Files und Namenskonvention aeusserst hilfreich, z.B. keine Datei laenger als 1000, im Hoechstfall (Ausnahme) 2000 Zeilen, Funktionen nicht laenger als 50, in Ausnahme 100 Zeilen, Methodennamen fangen mit einem kleingeschriebenen Verb an, Substantive werden ohne Underscore mit einem Grossbuchstaben direkt angehaengt, etc.

Alles weitere, Design und Co. sollte ein guter Programmierer beherrschen und notfalls durch entsprechende Literatur erlernen, z.B. "Design Patterns", "eXtreme Programming", etc. Auch hier kann man einige Standardwerke definieren, die gelesen werden sollten und deren Techniken und Hilfsmittel fuer klareres Design zum Einsatz kommen sollen.

Daneben ist gerade in groesseren Teams Kommunikation meist das beste Werkzeug 

Gruss
Jochen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP