Code Inspector -> Eigene Prüfung
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo Zusammen,
gerade bin ich dabei, da ich etwas Zeit nebenbei habe, eine Prüfung für den Code Inspector zu schreiben. Nun möchte ich noch ein paar Prüfungen einbauen.
Speziell geht es mir darum, dass die Entwickler "clean" programmieren sollen. Heißt in einer einheitlichen Form, so dass es schön lesbar ist. Ein Aspekt der dabei schon sehr gut unterstützt, ist der Pretty Printer.
Für die Prüfung von "Clean Code" möchte ich jetzt einfach prüfen ob der Entwickler den Pretty Printer verwendet hat.
gibt es also eine Möglichkeit, zu Prüfen, über einen FUBA, Methode, etc. ob ein Pretty Print ausgeführt worden ist?
Vielen Dank.
gerade bin ich dabei, da ich etwas Zeit nebenbei habe, eine Prüfung für den Code Inspector zu schreiben. Nun möchte ich noch ein paar Prüfungen einbauen.
Speziell geht es mir darum, dass die Entwickler "clean" programmieren sollen. Heißt in einer einheitlichen Form, so dass es schön lesbar ist. Ein Aspekt der dabei schon sehr gut unterstützt, ist der Pretty Printer.
Für die Prüfung von "Clean Code" möchte ich jetzt einfach prüfen ob der Entwickler den Pretty Printer verwendet hat.
gibt es also eine Möglichkeit, zu Prüfen, über einen FUBA, Methode, etc. ob ein Pretty Print ausgeführt worden ist?
Vielen Dank.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Nein - und das ist auch gut so!
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Daniel
Moin.
Rezept zum erweitern des Codeinspector
https://blogs.sap.com/2006/11/02/code-i ... new-check/
Ich würde aber auch keine Erweiterung für eine Pretty Print Prüfung vornehmen,
sondern die Quellcodes lesen, Pretty print im Speicher durchführen und mit
CALL FUNCTION 'RS_CMP_COMPUTE_DELTA'
die Unterschiede ermitteln.
Aber Vorsicht, es gibt Ecken, wo der Pretty print nicht funktioniert.
(z.B. In user-Exits mit Include-Coding, oder in Modifikationen.)
gruß Jens
Rezept zum erweitern des Codeinspector
https://blogs.sap.com/2006/11/02/code-i ... new-check/
Ich würde aber auch keine Erweiterung für eine Pretty Print Prüfung vornehmen,
sondern die Quellcodes lesen, Pretty print im Speicher durchführen und mit
CALL FUNCTION 'RS_CMP_COMPUTE_DELTA'
die Unterschiede ermitteln.
Aber Vorsicht, es gibt Ecken, wo der Pretty print nicht funktioniert.
(z.B. In user-Exits mit Include-Coding, oder in Modifikationen.)
gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ich würde mal behaupten, weil der Pretty-Print benutzerbezogen einstellbar ist und daher bei der Prüfung uU unterschiedliche Varianten verglichen werden.SaskuAc hat geschrieben:Wieso?black_adept hat geschrieben:Nein - und das ist auch gut so!
(siehe auch Antwort von Jens bezüglich RS_CMP_COMPUTE_DELTA)
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Weil SAP von Zeit zu Zeit den PP überarbeitet - und wenn dann Codestrecken im Transport sind, obwohl an ihnen keine Änderungen vorgenommen wurden ( bzw. diese wieder zurückgebaut wurden, sie aber damit auch im Transport stehen ) meckert die Prüfung . Desweiteren gibt es manchmal gute Gründe eine andere Formatierung als die vom PP zu verwenden - einfach weil es dann schöner aussieht.SaskuAc hat geschrieben:Wieso?black_adept hat geschrieben:Nein - und das ist auch gut so!
Wenn man so weit geht einem Entwickler zu unterstellen Code abzugeben, der durch den PP lesbarer würde, kann man auch gleich vorschreiben Datendeklarationen oder WHEN-Anweisungen in alphabetischer Reihenfolge durchzuführen...
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Daniel
http://www.tricktresor.de/blog/series/c ... erweitern/
Speziell zu Pretty Printer fällt mir auch nur der Ansatz von Jens ein.
Speziell zu Pretty Printer fällt mir auch nur der Ansatz von Jens ein.
Also ich weiß, wie ich eine eigene Prüfung schreibe, ist ja nicht meine erste 
( danke dennoch! - achja, durch Tricktresor habe ich es auch ursprünglich gelernt, verfolge den block sehr gerne 
)
Okay, zur Info, ich hätte sowieso nur den geänderten Code getestet, dafür habe ich meine Methoden - aber die Bedenken sind natürlich war, daran habe ich nicht gedacht, dass theoretisch jeder seine eigene Einstellungen für den PP hat ..
Das der PP auch häufiger nicht Ideal ist, ist mir auch bewusst, allerdings müssen insbesondere die Entwickler die von unserem Uralt ERP System ( auf dem sie COBOL programmieren ) auf SAP wechseln lernen dass man den Code formatiert.. ich habe programme bei denen gesehen, mein gott .. da wird einem ( wenn's um Formatierung geht ) schlecht.. deswegen sollte das zumindest eingebaut werden.
Was man eventuell einbauen könnte, wäre eine Prüfung ob der User die Rechte zum Entwickeln schon über einen gewissen Zeitraum ( z. B. 3 Monate ) hat. - Wenn ja, soll die Source nicht auf PP geprüft werden.. könnte eine Idee sein... aber da muss ich mir nochmal Gedanken machen und das abklären, was da am besten ist.
( danke dennoch! - achja, durch Tricktresor habe ich es auch ursprünglich gelernt, verfolge den block sehr gerne ) Okay, zur Info, ich hätte sowieso nur den geänderten Code getestet, dafür habe ich meine Methoden
- aber die Bedenken sind natürlich war, daran habe ich nicht gedacht, dass theoretisch jeder seine eigene Einstellungen für den PP hat .. Das der PP auch häufiger nicht Ideal ist, ist mir auch bewusst, allerdings müssen insbesondere die Entwickler die von unserem Uralt ERP System ( auf dem sie COBOL programmieren ) auf SAP wechseln lernen dass man den Code formatiert.. ich habe programme bei denen gesehen, mein gott .. da wird einem ( wenn's um Formatierung geht ) schlecht.. deswegen sollte das zumindest eingebaut werden.
Was man eventuell einbauen könnte, wäre eine Prüfung ob der User die Rechte zum Entwickeln schon über einen gewissen Zeitraum ( z. B. 3 Monate ) hat. - Wenn ja, soll die Source nicht auf PP geprüft werden.. könnte eine Idee sein... aber da muss ich mir nochmal Gedanken machen und das abklären, was da am besten ist.
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
@SaskuAc: Wenn dein Problem die Dinos sind: Macht lieber am Anfang einen monatlichen Codereview und schnapp dir halt die Deliquenten, die tatsächlich völlig unleserlichen Code abgeben, der durch den PP hübscher wird. Bin zwar im Grunde kein Fan des Prangers - aber wenn's hilft....
Pranger ist nie gut!
Aufklärung und Problembesprechung sollte man ohne Pranger machen.
Entweder im 4-Augen-Gespräch oder anonymisierter Code in größerer Runde.
Da ist es dann hilfreich, wenn man wirklich gute Beispiele hat.
Mit "Das sieht einfach besser aus" kann man niemanden überzeugen.
Ich habe mir z.B. angewöhnt immer alle nicht verwendeten Parameter aus der Mustererzeugung komplett zu löschen (Aufruf von Funktionsbausteinen oder Methoden).
Es nervt mich tierisch, wenn diese sinnlosen, auskommentierten Zeilen im Quelltext sind. (die im Übrigen das Verhalten des PP negativ beeinflussen).
Andere (viele andere) scheint es nicht zu stören...
Aufklärung und Problembesprechung sollte man ohne Pranger machen.
Entweder im 4-Augen-Gespräch oder anonymisierter Code in größerer Runde.
Da ist es dann hilfreich, wenn man wirklich gute Beispiele hat.
Mit "Das sieht einfach besser aus" kann man niemanden überzeugen.
Ich habe mir z.B. angewöhnt immer alle nicht verwendeten Parameter aus der Mustererzeugung komplett zu löschen (Aufruf von Funktionsbausteinen oder Methoden).
Es nervt mich tierisch, wenn diese sinnlosen, auskommentierten Zeilen im Quelltext sind. (die im Übrigen das Verhalten des PP negativ beeinflussen).
Andere (viele andere) scheint es nicht zu stören...
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
1027
Views
Views
Code Inspector - Eingabeparameter nicht möglich
von SaskuAc » 22.05.2018 14:59 • Verfasst in ABAP® Core
von SaskuAc » 22.05.2018 14:59 • Verfasst in ABAP® Core
2
Antw.
Antw.
1895
Views
Views
Code Inspector mit Prüfvariante S4HANA_READINESS_1909 spinnt
von PeterPaletti » 02.03.2021 12:25 • Verfasst in ABAP® Core
von PeterPaletti » 02.03.2021 12:25 • Verfasst in ABAP® Core
4
Antw.
Antw.
2802
Views
Views
Code Inspector erweitern durch neue Checks
von SteveOh » 20.08.2010 11:29 • Verfasst in ABAP® für Anfänger
von SteveOh » 20.08.2010 11:29 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.