Programmierstandards - Feedback und Ideen

[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

[LordCinimod]

Also ich liebe TFR(total free rpg) oder wie ihr es nennt fully free RPG (gibt es da eine offi. Bezeichnung von IBM? ) Habe noch das beschnittene Free RPG am Anfang der Ausbildung mitbekommen und fand die Variablendeklaration immer sehr umständlich, mit dem TFR ist das viel einfach gelöst wie ich finde

Ich warte einfach ab wie es aufgenommen wird es wird Zeit brauchen das ist klar aber hoffe das sich alle damit anfreunden können was zum Schluss durch die Führungskräfte abgesegnet wird! Aber wie gesagt geht es dabei ja auch primär um neue Mitarbeiter. Mir ist auch bewusst das man nicht einfach mal alle Programme modernisieren kann, aber z.B. als ich auf der Common-D Azubi Schulung für RPG war hat ein Mitstudent erzählt das seine Firma einen externes Programm gekauft hat und dann haben die beim Anfassen eines Programmes dieses einfach vorher in TFR umgewandelt und mussten ab und zu nurnoch ein paar kleine Probleme manuell fixen
Find ich genial, leider sind wir davon bei uns in de Firma noch weit weg

Am überlegen bin ich ob MVC mit in die Standars rein sollte, habe letzens einen Artikel von S. Klement und P. Tohy gefunden und war freudig überrascht. Kenne MVC bereits von C#/Java und da ist MVC ja seit Jahren Standard bei der Entwickung.

Grüße
Dominic

[dschroeder]

Zur Klarstellung: Früher gab es nur das "Fixed Format" RPG. Vor einigen Jahren hat IBM dann das sogenannte "free format" RPG herausgebracht. Dort konnte man einigen Code in freierer Form schreiben, die Deklaration der Variablen war aber noch auf fixed format angewiesen. Danach gab eine Erweiterung zum "total free RPG", in dem dann auch alle Deklarationen im free format gemacht werden konnten. (Also Einführung der dcl- Anweisungen).
Aber auch dieses "total free RPG" hat noch eine Einschränkung: Code kann nur in den Spalten 7 bis 80 stehen.

Seit Ende November 2015 gibt es jetzt das "fully free RPG". Dort ist jegliche Spaltenbeschränkung aufgegeben. Man kann also ganz links in Spalte 1 anfangen zu schreiben und soweit nach rechts raus schreiben, bis die maximale Breite der SRCPF erreicht ist (Wir haben das bei uns auf 240 eingestellt).

Die Begriffe habe ich von den IBM Veröffentlichungen übernommen. Ich finde sie auch etwas ungewöhnlich. Aber da IBM die Free-Syntaxen in mehreren Schritten eingeführt hat, gingen denen anscheinend die Begriffe aus. Dehalb ist wohl die Rede von "free", "totally free" und "fully free".

Dieter

[Fuerchau]

Mal sehen, welche Free-Varianten es demnächst gibt und wie die heißen.
Es gibt ja keinen Grund, warum eine DCL-Anweisung unbedingt am Anfang stehen muss.
Der Compiler arbeitet ja sowieso in mehreren "Phasen".

Die nächste Option ist ein Copy, der je nach Quelltyp ein Copystrecke automatisch von RPG nach ILERPG nach FullyFree konvertiert.
Hierbei werden dann dynamisch erstellte Variablen (was ja nur im Nicht-Free geht) dann kurz davor per DCL definiert.
PLIST-Aufrufe werden in PR's konvertiert und die Call's angepasst.
KLIST's werden aufgelöst (entfernt) und die entsprechenden EA-Befehle um die Keyfelder ergänzt.
Hier brauche ich dann nicht mehr zu suchen, mit welchem Schlüssel denn nun tatsächlich zugegriffen wird.
Dann brauch ich mich um die "Modernisierung" der Quellen auch nicht mehr zu kümmern.

Nun gut, das automatische Konvertieren von Subroutinen in Prozeduren wird dann wohl nicht lange auf sich warten lassen.

[BenderD]

Nun gut, das automatische Konvertieren von Subroutinen in Prozeduren wird dann wohl nicht lange auf sich warten lassen.

... umsetzen von SUBRs nach PROCs konnte das Linoma Teil schon bevor es free gab.

D*B, der das Gedöns um free RPG nicht verstehen kann, das war für andere Programmiersprachen schon normal, bevor die meisten Programmierer aus den Windeln raus waren.

[dschroeder]

D*B, der das Gedöns um free RPG nicht verstehen kann, das war für andere Programmiersprachen schon normal, bevor die meisten Programmierer aus den Windeln raus waren.

Gerade weil die freie Eingaben für eine Programmiersprache so wichtig ist, ist es doch klar, dass sich die RPG-Programmierer dafür interessieren, wie es geht und die Forderung aufstellen, dass es vernünftig funktioniert.

Dieter

[BenderD]

Gerade weil die freie Eingaben für eine Programmiersprache so wichtig ist, ist es doch klar, dass sich die RPG-Programmierer dafür interessieren, wie es geht und die Forderung aufstellen, dass es vernünftig funktioniert.

Dieter

... warum erinnert mich das nur immer wieder an F.W. Bernstein? Die schärfsten Kritiker der Elche, waren früher selber welche.
Die Metamorphose des tiefblau gefärbten AS/400 Anhängers lässt mich immer wieder schmunzeln.
Stufe 1: der RPG Zyklus ist das Größte.
Stufe 2: RPG ist so toll, weil man den Zyklus nicht mehr benutzen muss.
Stufe 3 a: /free und /end-free ist Spitze , weil man sofort sieht, dass jetzt keine Spalten mehr kommen.
Stufe 3 b: toll, dass man Kommentare am Zeilenende nicht kennzeichnen muss
Stufe 3c: Deklarationen müssen in Spalten bleiben, das ist einfacher
Stufe 3d: embedded SQL, da kann kein free format gehen
Stufe 3e: call und eval sind das Größte
Stufe 4: toll das embedded SQL jetzt auch in Freeformat geht
Stufe 5: toll, jetzt gibt es sogar noch ein eval corr
Stufe 6: toll, jetzt braucht man nicht einmal mehr /free und /end-free schreiben
Stufe 7: toll, jetzt gibt es total free
Stufe 8: noch toller, jetzt gibt es fully free
Stufe next: jetzt warten wir auf total fully free
Stufe übernext: jetzt fehlt nur noch full total fully free
final Stufe: jetzt funktioniert sogar alles

D*B

PS: das Endergebnis hätte man auch einfacher haben können: CRTDUPOBJ CRTBNDC QSYS *CMD NEWOBJ(CRTBNDRPG), dann hätte man sich sogar eine Menge Gedöns mit Prototypen erspart und Blöcke könnte man einfach durch geschweifte Klammern darstellen (Vorsicht Elchtest: das könnte in full total fully free RPG kommen), aber das hätten die Elche wahrscheinlich nicht gemocht.

[camouflage]

Die ganze Diskussion erinnert mich an die Aussage einer befreundeten Fotografin:
"Was nützt die tollste Fotoausrüstung, wenn man nicht das Auge für das Motiv hat"!

just my 2 cts.

[Fuerchau]

Dem kann ich mich nur anschließen.
Bei den ganzen Möglichkeiten bin ich einfach froh, dass meine Programme funktionieren.
Egal ob COBOL, RPG, mit oder ohne ILE oder SQL, meine Kunden zufrieden sind und die (interne) Doku verständlich wirkt.
Dabei habe ich meinen eigenen Standard entwickelt, passe mich den Kundenwünschen aber an oder überzeuge Sie, wenn mein Weg der bessere ist.

[LordCinimod]

... warum erinnert mich das nur immer wieder an F.W. Bernstein? Die schärfsten Kritiker der Elche, waren früher selber welche.
Die Metamorphose des tiefblau gefärbten AS/400 Anhängers lässt mich immer wieder schmunzeln.
Stufe 1: der RPG Zyklus ist das Größte.
Stufe 2: RPG ist so toll, weil man den Zyklus nicht mehr benutzen muss.
Stufe 3 a: /free und /end-free ist Spitze , weil man sofort sieht, dass jetzt keine Spalten mehr kommen.
Stufe 3 b: toll, dass man Kommentare am Zeilenende nicht kennzeichnen muss
Stufe 3c: Deklarationen müssen in Spalten bleiben, das ist einfacher
Stufe 3d: embedded SQL, da kann kein free format gehen
Stufe 3e: call und eval sind das Größte
Stufe 4: toll das embedded SQL jetzt auch in Freeformat geht
Stufe 5: toll, jetzt gibt es sogar noch ein eval corr
Stufe 6: toll, jetzt braucht man nicht einmal mehr /free und /end-free schreiben
Stufe 7: toll, jetzt gibt es total free
Stufe 8: noch toller, jetzt gibt es fully free
Stufe next: jetzt warten wir auf total fully free
Stufe übernext: jetzt fehlt nur noch full total fully free
final Stufe: jetzt funktioniert sogar alles

D*B

PS: das Endergebnis hätte man auch einfacher haben können: CRTDUPOBJ CRTBNDC QSYS *CMD NEWOBJ(CRTBNDRPG), dann hätte man sich sogar eine Menge Gedöns mit Prototypen erspart und Blöcke könnte man einfach durch geschweifte Klammern darstellen (Vorsicht Elchtest: das könnte in full total fully free RPG kommen), aber das hätten die Elche wahrscheinlich nicht gemocht.

Mhm, ich verstehe gerade deine Aussage nicht so genau, was ist schlimm daran das RPG moderner wird? Als ich meine Ausbildung angefangen habe habe ich mit free rpg angefangen. Ich fand das sehr umständlich, mir persönlich gingen diese Spalten tierisch auf den Nerv! Gleichzeitig war ich froh, da mir das so definitv besser gefiel als die alte Schreibweise ohne free und end-free.

Als dann tfr rauskam war ich selig, viel angenehmer zu schreiben und zu lesen(da sind sich alle Azubis bei uns in de EDV und in der Common-D Schulung einig). Ich finde es klasse das RPG weiterentwickelt wird und mir ist bewusst das es vllt. erst in x Jahren (wenn überhaupt) den Stand einer heutigen Sprache erlangt, aber hey was solls hauptsache es gibt einen Fortschritt und warum soll man das dann nicht auch gut finden dürfen?

Selbes trifft auf DDS und Profound zu (wie dschroeder schon schrieb) Profound ist viel angenehmer zu programmieren und auch zu nutzen.

Vllt. bin ich aber auch als Azubi nur naiv und habe zu wenig durchblick xD

PS: Auch wir schreiben Programme nur rein intern für unsere Firma, arbeiten also nicht für externe Firmen. Vllt. ist das ja der Grund für die unterschiedlichen Meinungen ; )