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