Programmierstandards - Feedback und Ideen

[LordCinimod]

Hallo : ),

ich möchte diesesmal um Feedback und vllt. weitere Ideen bitten!
Die Situation bei der Firma wo ich gerade meine Ausbildung mache ist nämlich das wir noch keine Programmierstandards besitzten. Was natürlich verschiedenste Probleme in der Entwicklung und Wartung aufwirft, zum Beispiel nutzt kaum einer Prozeduren oder Serviceprogramme oder es werden noch alte RPG Syntax verwendet. Ganz zu schweigen davon das es Neulingen in RPG die Einarbeitung in diese Sprache noch schwerer macht ; )

Also habe ich das bei meiner Gruppen und Abteilungsleitung angesprochen und diese fanden diese Idee sehr gut und meinten Ich solle mir mal Gedanken machen, da dies längst überfällig sei.

Dies habe ich getan und wollte hier einfach einmal Feedback bekommen wie ihr als erfahrene Entwickler dieses Standards seht, was ich verbessern kann oder was ich vllt. komplett vergessen habe.

Ich als Azubi habe ja noch nicht alles von RPG kennengelernt und mir fehlt schlicht auch die Erfahrung.

Hier also die Punkte welche ich bis jetzt habe:

CN = Camel Notation (Bsp:getData)
PN = Pascal Notation (Bsp:GetData)
UN = ungarische Notation(btngetdata)

RPG

• Formatierung und Nutzung
  
  • Variablen
    
    • CN
    • kleinstmöglicher Gültgigkeitsbereich
    
    
  • Datenstruktur
    
    • PN
    • Qualified
    
    
  • Prozeduren
    
    • PN
    • max. X Zeilen Code je Prozedur um diese klein und wartbar zu halten
    • immer Rückgabewert, bei void dann ind
    • immer Prüfung des Rückgabewertes
    
    
  • Konstanten
    
    • UPPERCASE
    
    
  • DDS/PF Variablen
    
    • # vorangestellt
    • UN + CN
    
    
  • Printer Variablen
    
    • $ vorangestellt
    • CN
    
    
  
  
• File Benennung
  
  • DDS/Profound
    
    • Programm
      
      • wie zugehöriges RPG Programm nur mir D am Ende
      
      
    • Records
      
      • ## vorangestellt
      • der Funktion des Records entsprechend
      • CN
      
      
    • SFL
      
      • # vorangestellt
      • UN + PN
      
      
    
    
  • Printerdateien
    
    • Programm
      
      • wie zugehöriges RPG Programm nur mir P am Ende
      
      
    • Records
      
      • $$ vorangestellt
      • der Funktion des Records entsprechend
      • CN
      
      
    
    
  • physische/logische Dateien
    
    • entfällt da heute überflüssig
    
    
  
  

• Kontrollstrukturen
  
  • einfache Kontrollstrukturen
    
    • kein GOTO
    • wenn möglich keine tiefen Verschachtelungen
    
    
  
  

• Schleifen
  
  • keine Endlosschleifen
  
  

• Erklärung und Dokumentation
  
  • Eingangskommentar
    
    • Programmname
    • Berarbeitungsstatus
    • kurze Erklärung
    • änderungen + zeitpunkt + name programmierer
    
    
  • Kommentar Prozedur
    
    • kurze Erklärung
    • Input/Output
    
    
  • sonstige Kommentare
    
    • so gering wie möglich halten und nur bei kompl. Vorgängen
    
    
  • Prozeduren Doku
    
    • welche gibt es
    • wie nutzte ich sie
    • nötige Bindeverzeichnise und Copystrecken
    
    
  
  

• Verbotene Funktionalitäten
  
  • Goto
  
  

• Vermeidbare Funktionalitäten
  
  • neue physische Dateien, besser DB
  • neue GreenScreen Anwendungen, besser Profound
  • Subroutinen, besser Prozeduren
  
  

• Testen
  
  • außer manuellem Testen keine Idee, unit-tests oder so etwas scheint es nicht für dieiSeries zu geben
  
  

Ich hoffe das da ein paar gute Ideen dabei sind, falls alles Mist sein sollte könnt ihr mir das aber sonst auch gerne ungeschont klarmachen : P

Grüße
Dominic

[BenderD]

Hallo Dominic,

Programmierstandards müssen immer mit dem Team gelebt werden, von daher zu dem Team passen - was hilft der beste Standard, wenn alle vorhandenen Programme anders aussehen und sich bei neuen Programmen keiner dran hält. Von daher kann man als Außenstehender nicht zu allen Punkten Stellung nehmen.

In jedem Fall ändern sollte man:
- kein #, $ und auch keine weiteren Sonderzeichen aus dem Invarianten Teil des EBCDIC in Bezeichnern verwenden
ich empfehle zu ändern:
- Präfixe und Suffixe für 10stellige Namen vermeiden
- Kommentare nur in Procedure Headern (wenn man ein Codesegment kommentieren muss, gehört es ausgegliedert)
- Subroutines sind generell überflüssig, wenn man Procedures hat und kennt.
- Variablen: adäquater statt minimaler Gültigkeitsbereich (=> kann raus)
- Rückgabewert void würde ich zulassen, stattdessen Fehlerrückgabe durch Exception Mechanismus (senden Escape Message via QMHSNDPM) damit muss die rufende Funktion prüfen, wenn sie nicht percolation vorzieht)
was mir fehlt:
- kein Export von Variablen (stattdessen getter und setter)
- Werkzeuge (damit meine ich nicht RDI, sondern das, was da fehlt!!!)
-- Change Management (absolutes Minimum ist da : sicherstellen reproduzierbarer Compiles, was die Verwendung zentraler BNDDIRs auschließt, ebenso das überschreiben der Signaturen mit ISMIREGAL) Im Minimum kann man da mit einem Präprozessor arbeiten.
-- Version Controll
-- automatisierte Kontrolle der Richtlinien (hier kommt man wohl um einen eigenen Stylechecker nicht drumherum)
-- automatisierte Unterstützung der Richtlinien (z.B.: einen Generator, der aus der CopyStrecke mit den Exporten einen Rahmen generiert - da gibt es was in meiner OpenSource Ecke meiner Website)
-- zum testen gibt es opensource RPGUnit (damit habe ich keine umfassenden praktischen Erfahrungen)
-- ansehen würde ich mir da auch Log4RPG aus derselben Quelle (Thomas Raddatz)

soviel erst mal an Anmerkungen

D*B

[dschroeder]

Hallo Dominic,

du hast dir ja schon viele Gedanken zu dem Thema gemacht. Das finde ich sehr gut. Ich würde an deiner Stelle die Überlegungen mit deinem Team besprechen und einen gemeinsamen Nenner mit deinen Kollegen finden. Dieter Bender hat recht: So ein Standard muss vom Team gelebt werden. Du kannst nur soweit etwas vorgeben, wie die anderen bereit sind, es auch anzuwenden.

Eine konkrete Empfehlung habe ich aber auch noch: Wenn ihr mit Profound arbeitet, könnt ihr in Displayfiles mit langen Feldnamen (Stichwort "alias") arbeiten. Bei uns heißt ein normales Displayformat F1. Wenn es ein zweites gibt, heißt das dann F2 usw. Wenn es eine Subfile ist, heißt das Format S1. (Bei mehreren Subfiles S2, S3, usw...).

Die Felder in den Formaten habe dann ganz "normale" Namen, wie z.B. "name" oder "rechnungsbetragBrutto". Sie brauchen keine eigene Kennung als Variablen von Display-Files, da sie über die Displayfiles-Datenstrukturen angesprochen werden. Also z.B. "f1.name" oder "s1.rechnungsbetragBrutto".

Dieter

[ExAzubi]

Hallo,

das Problem was ich sehe - weil ich mit was ähnlichem auch konfrontiert wurde - ist die berreitschaft des Teams!
Ich kam aus einem Softwarehaus wo es für allem(ähnlich wie du) Regeln gab wie was zu benennen ist.
Ich ging zu einem großen Unternehmen. Dort war es Kraut und Rüben!
Einerseits gab es einen Standard der sich nur auf RPT-Programme bezog und dieser wurde dort auch angewendet.
Für alle sonstigen Programmierungen und alles was nicht primär das ERP System betraf herrschte wilde Anarchie.
Jeder wie er wollte, tlw. waren Programmierer nicht mehr im Hause, wo man aber am Sourcecode sah "Sie wissen nicht was sie tun!"
Dort wurden mal eben 1000! Statements übersprungen (goto) wiel man ja nicht wusst eob dazwischen nicht was definiert wurde
Von den anderen Programmieren wollte sich keiner auf "neue" Standards einlassen, dauert zu lange; machen wir schon immer so; Sind meine Programme da kümmere ich mich dannn drum...;

Die waren alle 50+ und flexibel wie T-Träger - warum --> keine Ahnung...

Deshalb die Dieter Bender bereits gewchrieben hat; Standards müssen gelebt werden und du solltest den kleinsten gemeinsamen Nenner aus dem Teamgespräch nehmen, alles andere wird *IGNORED

[LordCinimod]

Erstmal danke für das Feedback : )

Die Ideen von von euch greife ich sehr gerne auf und werde mich damit weiter beschäftigen, RPG4Unit kannte ich nicht und auch die Escape Message via QMHSNDPM hört sich interessant an. Getter und Setter kenne ich von Java/C#, da muss ich mich auch einmal schlau machen wie man dies in RPG nutzt. Die Idee mit den Aliasen bei Profound ist auch klasse, kannte dies schon von der POW3R, jedoch noch nicht dazu gekommen mir das selber genauer anzuschauen, werde ich aber jetzt nachholen. Zudem viel mir noch ein das es auch sicher sinnvoll ist TFR da mit reinzunehmen, da dies auch nocht nicht von allen genutzt wird.

An der Versionierung arbeite ich auch schon, dies ist ein Punkt in meinem Rdi Tutorial was ich gerade in meiner Freizeit erstelle um meinen Kollen die Vorteile von Rdi zu PDM aufzuzeigen. Wenn Rdi genutzt wird geschieht dies in der Abteilung eigentlich nur als grafischer Editor. Vorteile wie SVN/Git, TASKs, Snippets oder IBM i Projekte mit Push usw. kennt und nutzt keiner.

Natürlich muss der Standard gelebt werden die Ideen werden auch noch mit den Kollegen besprochen, ich soll ja nur ein Grundkonzept entwickeln. Klar wird es auch Diskussionen dazu geben aber wichtig ist besonders das mit den Standards auch ein Stück weit dafür gesorgt werden soll das modern entwickelt werden soll besonders als Richtlinie für neue Azubis/Entwickler, die damit gleich modern Entwickeln sollen. Wäre natürlich schön wenn die älteren Kollegen diese mit aufgreifen aber wichtig ist vorallem das die neuen damit "aufwachsen"(Aussage Führungskräfte).

Wenn es OK ist würde ich euch gerne auf den laufenden halten und weiter euer Feedback zu eventuellen anderen Ideen einholen : ) ?

[dschroeder]

Ich fände es gut, weiter von euren Fortschritten zu hören. Oft ist bei solchen Diskussionen auch für andere Programmierer etwas neues dabei.

Bei uns versuchen wir möglichst, die neuesten Programmiermöglichkeiten zu nutzen. Wir sind gerade dabei, das "Fully free" (also das RPG ohne Spaltenbegrenzung) zu nutzen. Leider gibt es da noch einen Bug. IBM sucht den gerade.

Am leichtesten ist es, seine Kollegen von neuen Dingen zu überzeugen, wenn man sofort einen handfesten Vorteil mitliefert. Vielleicht kanst du ja einiges an allgemeingültigen Tools schreiben, die andere nutzen können. Oder du baust "schöne" Kopiervorlagen in neuem Stil. Die Erfahrung sagt, dass wenn für ein Themengebiet gleich anfangs eine gute Lösung existiert, wird diese sofort kopiert, wenn jemand ein ähnliches Problem hat.

Wir haben bei uns einen Link zu einem zentralen Dokument, in dem viele Kopiervorlagen mit ihren spezifischen Eigenschaften aufgeführt sind. Wenn dann jemand z.B. eine Profound-Vorgabeseite für eine Auswertung mit SBMJOB-Option haben möchte, kann er so ganz einfach eine passende Kopiervorlage finden. So setzen sich Standards schnell durch.

Desweiteren haben wir im RDi einige Schablonen definiert. Damit kann man sich ganze Codesequenzen in seinen Source eintragen lassen. Z.B. eine standardisierte Schleife für die Verarbeitung eines SQL-Cursors.

Dieter

[Robi]

Frohes Neues zusammen,

ich kenne eine Firma in der auch das GOTO verboten wurde ...
Lösung der findigen Entwickler:

DO

und im 'GOTO' Fall

LEAVE

Ursprünglich war das ENDDO immer am Ende der SR

Aber das ist durch verschiedene Entwickler und fehlende Standards 'raus-gewachsen'
In den Pgmmen wünscht sich so mancher das GOTO wieder, da dann wenigstens der Ansprungspunkt einfach zu finden ist.
Ihr solltet also nicht nur das GOTO verbieten sondern ggf auch mal eine Stil-Schulung durchführen.
Manch guter Entwickler freut sich wenn er etwas anderes(nachweislich - begründbar besseres) kennen lernt
Robi

[BenderD]

@QMHSNDPM: gehört natürlich in Funktionen gekapselt throw(...) für error auslösen und eventuell noch joblogout(...) als einfachere Alternative zu log4RPG. (aktuelles Beispiel findest Du u.a. hier: http://appserver4rpg.cvs.sourceforge....2&view=markup) etwas ältere findest Du auch hier: http://www.bender-dv.de/Snippets.html)
@getter und setter: ebenfalls in den oben zu findenden Quellen.
@RDI: das Problem mit RDI ist, dass es von der Optik her moderne Standards vortäuscht. Sieh dir mal all das an, was Eclipse unter Source und Refactoring kann, das fehlt bei RDI komplett. Leider gibt es derzeit nix besseres und bei RDI wird man darauf ewig warten dürfen, fürchte ich.
@Snippets: da sollte man sich das Freemarker Plug in mal ansehen. Hier sollte man aber die Gefahr im Auge behalten, dass man bei generieren statt modularisieren landet. Wer viele Snippets verwendet, der macht in der Modularisierung was verkehrt!!!
@"alte" Programmierer: das ist im wesentlichen keine Frage des Alters, sondern der Ausbildung - und da kann man nachbessern. Ohne dies ist das kaum sinnvoll.

D*B
PS:
@Robi: Ich bin sicher kein Freund von leave und iter, gute Programme kommen auch ohne so etwas aus, aber besser als Goto ist das allemal, da man damit nur an das Ende oder den Anfang des Blocks kommt.
@anderen Dieter: Das mit den Vorteilen kann ich nur unterstreichen. Was das sogenannte fully free angeht, habe ich leichte Vorbehalte, das ist doch wieder nur eine umständlichere Schreibweise für Kartenart (D in Spalte 6) und Kartenunterart (DS, S, PR, PI). Große Vorbehalte habe ich allerdings gegen Kopiervorlagen und Schablonen, das ist in Bezug auf Modularisierung kontraproduktiv.

[Fuerchau]

Nun fehlen nur noch Preprozessor-Anweisungen (á la C++, also nicht nur /IF und /END-IF)), die Funktionen und Makros kapseln, so dass man wirklich nur im Spooler noch nachvollziehen kann, was das Programm wirklich tut.
Ähnliches habe ich schon bei COBOL's Copy-Anweisung mit "replacing" gesehen.

[dschroeder]

Das mit den Vorteilen kann ich nur unterstreichen. Was das sogenannte fully free angeht, habe ich leichte Vorbehalte, das ist doch wieder nur eine umständlichere Schreibweise für Kartenart (D in Spalte 6) und Kartenunterart (DS, S, PR, PI). Große Vorbehalte habe ich allerdings gegen Kopiervorlagen und Schablonen, das ist in Bezug auf Modularisierung kontraproduktiv.

Das unschöne am fully free ist, dass man gar kein fixed format mehr verwenden kann. Das heißt, man muss zwingend Prototypes für jeden CALL bauen. (Das haben wir jetzt automatisiert, war aber schon etwas Mühe).
Bei den Kopiervorlagen kommt es meiner Meinung nach darauf an, was das für Kopiervorlagen sind. Es gibt ja Dinge, die man nicht generisch bauen kann (z.B. vieles was mit Masken zu tun hat). Da finde ich es besser, wenn jeder dieselbe Kopiervorlage verwendet. Es soll auf keinen Fall heißen, dass man kopieren anstatt modularisieren sollte!

Dieter

[BenderD]

Das unschöne am fully free ist, dass man gar kein fixed format mehr verwenden kann. Das heißt, man muss zwingend Prototypes für jeden CALL bauen. (Das haben wir jetzt automatisiert, war aber schon etwas Mühe).
Bei den Kopiervorlagen kommt es meiner Meinung nach darauf an, was das für Kopiervorlagen sind. Es gibt ja Dinge, die man nicht generisch bauen kann (z.B. vieles was mit Masken zu tun hat). Da finde ich es besser, wenn jeder dieselbe Kopiervorlage verwendet. Es soll auf keinen Fall heißen, dass man kopieren anstatt modularisieren sollte!

Dieter

... das ist ja sogar mal eine positive Sache an "fully free". Seitdem man für exec sql nicht mehr aus dem free raus musste, habe ich jedenfalls keien C Zeile mehr benutzt.

Bei näherem hinsehen entpuppt sich so manche Kopiervorlage als etwas. was man besser durch Modularisierung erreichen könnte, da geht mehr als die meisten denken, auch bei Masken!

D*B

[cbe]

Hallo Dominic,

das erinnert mich an meine ersten Wochen in meiner Firma. Da habe ich auch Programmierrichtlinien einführen sollen.
Nur wurden halt selten wirklich neue Programme geschrieben, sondern immer nur geändert oder "was ähnliches wie dortunddort" erstellt (also kopiert+angepasst).
Dadurch blieben die verschiedenen Stile erhalten, weil die komplette bestehende Software umstellen macht keinen Sinn.

Was mir letztlich gelungen ist, ist im wesentlichen folgendes:
- Eingangsparameter und lokale temporäre Variablen haben ein erkennbares Präfix
- Kopieren+Anpassen möglichst vermeiden. Lieber nur 1 Routine mit Parametern.
- sinnvolle COPYs eingeführt für Dinge, die immer wieder manuell ausformuliert waren
- Templates für Reportprogramme (redundante Logik zentral ausgelagert)
Und das alles nur bei neuen Programmen. Das ist im Rückblick nicht allzuviel.
Andererseits wenn ich den Entwicklungstil komplett neu erfunden hätte, dann wäre die heterogene Landschaft um 1 Variante reicher geworden, und dadurch noch schlimmer.


Letztlich wirklich wichtig war es, eine Versionsverwaltung einzuführen, um Änderungen nachvollziehbar zu machen und Quellen gegen parallele Änderungen zu sperren.

Weiterhin wichtig ist es, die Einhaltung der Regeln zu prüfen!
Die Versionsverwaltung wurde hochgelobt - und ich musste später feststellen, dass aus Bequemlichkeit nur 95% darüber lief. Erst ein regelmäßiger (automatischer) Check und dann auf die Finger hauen half.


Das ist wahrscheinlich nicht ganz das, was Du hören willst.
Aber vielleicht ist Deine Situation auch eine ganz andere wie bei mir damals :-)
Viel Erfolg!

Gruß, Christian