Welche Fragen sollten "Programming Guidelines" beantworten?

Welche Fragen sollten "Programming Guidelines" beantworten? (10 Beiträge, 132 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Folgendes Szenario: du fängst in einer neuen Softwareentwicklungsbude als Java Entwickler an und bekommst ein Dokument mit dem Titel "Java Programming Guidelines" in die Hand gedrückt. Welche Fragen hättest du gerne von diesem Dokument beantwortet?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

Die verbindlichen Namenskonventionen und sonstige Richtlinien, die einzuhalten sind.

Kannst du das sonstige Richtlinien ein bisschen genauer erläutern?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

Alles, was im Unternehmen allgemein gültig und einzuhalten ist, Details hängen vom Unternehmen bzw. von der geforderten Vorgangsweise ab.

Vor allem soll durch solche Richtlinien verhindert werden, dass jeder wie die Axt im Wald durch die Gegend programmiert und ein Coding für alle anderen ausser dem Erstverfasser unlesbar bzw. nicht nachvollziehbar ist.

Keinesfalls wird in solchen Richtlinien auf eine Programmiersprache eingegangen, die Kenntnisse darüber werden vorausgesetzt oder sind woanders verfügbar.

1. Einrückungsregeln. Nix ist konfuser zu lesen als Code wo einer 4, der nächste 2 und einer 5 zeichen einrückt.

2. Namenskonventionen. Wenn Du das Teil schreiben sollst weisst ja hoffentlich was gemeint ist.

3. Kommentierregeln. Soll was im Head stehen, wenn was, Versionshistory wird wie geschrieben, welche Kommentare wo, mit // oder /* */, usw.

4. Stanrdardpakete, die Verwendet werden. Welche Packages muss/kann/darf/soll ich (nicht) verwenden.

5. Regeln zum Testablauf. Was muß getestet werden, von wem, was ist hinreichend um als Funktionstest zu gelten?

6. Regeln zur Dokumentation. Wo sind die Dokuvorlagen, was muß wer ausfüllen? Gibt's bestimmte Richtlinien die eingehalten werden müssen (ISO, SOA...).

7. Ablauf des Funktionstest. Wer testet was, an wen geb ich meinen Code wenn ich glaub daß ich fertig bin?

Usw. Gib mir man 'ne Idee wie groß Eure Bude ist, das schaut für 'n 5-Mann-Entwicklerteam anders aus als für einen Großkonzern...

________________________________________________________________________
Some people are like compilers. They take simple statements, add stuff from their memory, assume what you don't tell them explicitely and make some big production out of it.

Danke für den Input. Aktuell soll das Dokument für ca. 12-15 Entwickler geschrieben werden, das Ziel ist es aber, daß die Entwicklertruppe größer wird.

Wie code auzuschauen hat lasse ich mal außen vor, denn in dieser Hinsicht sollen die Java Coding Conventions von Sun eingehalten werden. Selbes gilt für Dokumentation und Nomenklatur von Klassen/Feldern.

Folgende Fragen habe ich aufgeschmissen, die ich in so einem Dokument gerne beantwortet hätte:

Namespaces:
- was ist der basisnamespace?
- welche Richtlinien sind bei der Erstellung von Packages zu beachten?
- darf ich überhaupt ein neues Package unterhalb von com.meinefirma anlegen, bzw. welche Voraussetzungen müssen erfüllt werden, damit ich es darf? Wer darf/entscheidet es?
- was sind die einzelnen Module, die bereits vorhanden sind. Was ist wo zu finden?

Exceptionhandling:
- Wie werden Exceptions verarbeitet?
- Unterschiede zwischen Systemexceptions (z.B. java.sql.SQLException) und Applikationsexceptions (z.B. com.meinefirma.core.logic.InternalException)?
- Was muß im Fehlerfall getan werden? Stichpunkt: logging
- Wie soll man Exceptions schmeissen?

Logging:
- Was muss geloggt werden?
- Wie muss geloggt werden?
- Wohin muß geloggt werden?
- Wie sind Logger zu konfigurieren (alles in ein File? Pro Modul? Pro Namespace?)
- Was wird mit welchem Status geloggt? Sind Stati tabu?
- Sollen Stacktraces mit ausgegeben werden oder nicht? Nur bei Exceptions?

Testing:
- welches Testingframework wird verwendet?
- was wird getestet?
- wann wird getestet?

Teamwork/CVS:
- Wie wird das Arbeiten im Team gehandhabt und wie wird verhindert, daß mehrere Entwickler die selben Files editieren.
- Wann wird ein File ins CVS gestellt?
- Tags/branches?

Konfigurationen/Customizing:
- wie werden Konfigurationen erstellt und wo werden sie abgelegt?
- wo im Buildprozess muß man die Konfigfiles eintragen, damit sie auch deployed werden?
- .properties oder .xml?
- Wie werden Konfigurationen strukturiert?
- Wie kommt meine Klasse zum Konfigurationsfile?

Standardlibraries:
- welche Libraries werden verwendet und welchen Zweck erfüllen sie?
- wo gibt es Dokumentationen/Beispielcode/Bücerh dafür?

Ich bilde mir aber ein, daß ich noch ganz wesentliches Zeug vergessen habe.

Andere Frage: weiss jemand inwieweit man die Java Coding Conventions von Sun (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html ) auch für C# einsetzen kann?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

-) Namenskonventionen
-) zu verwendende Standardroutinen inkl. Beispiel und eventuell bekannte Fehler bzw. "Eigenheiten"
-) Kurzbeschreibung der IDE inkl. verwendete Versionsverwaltung
-) Kurzbeschreibung zusätzlich angekaufter Utilities
-) Angabe eines Musterprogrammes

pong

EDV-Systeme verarbeiten, womit sie gefüttert werden.
Kommt Mist rein, kommt Mist raus

die absolute kern (und bei uns oft zu stundenlangen diskussionen) führende frage

wo gehört die depperte geschwungene klammer auf hin

if (irgendwas == null) {
}

oder

if (irgendwas == null)
{
}

rennegade@gmx.at

Wie wärs mit einer Umfrage?

ps: ich bin dafür, die öffenende Klammer in eine neue Zeile zu tun.

Das Vergleichen ist das Ende des Glücks und der Anfang der Unzufriedenheit.

Søren Kierkegaard (1813 - 1855)

Also dieses Thema wurde auch bei uns bis zum Erbrechen diskutiert - mein Fazit aus unzähligen Diskussionen - die Firma soll das vorgeben - alle machens so und das Leben ist schön. Ich find mittlerweile beide Versionen gleich gut übersichtlich.

Schade um die Zeit für Diskussionen diesbezüglich!

Gruß
grimsvoetn
<a href="http://www.mozilla.org/products/firefox/" title="Get
Firefox - The Browser, Reloaded"> Get Firefox

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung