Umfrage
Hallo zusammen!
Gibt es im ABAP-Umfeld bei euch irgendwelche {Themen | Techniken | Praktiken}, über die ihr gerne mal einen {Leitfaden | Tutorial | Genaue Beschreibung} haben würdet?
Gibt es irgendwelche ABAP-Fallen, über die ihr oder eure Kollegen immer mal wieder stolpert?
Ärgert ihr euch häufiger über bestimmte "Programmierunarten" oder schlechte Umsetzungen bei Programmen, die ihr korrigieren oder warten müsste? Wenn ja, welche sind das?
Ich würde mich sehr über Antworten freuen!!
Herzlichen Dank und Gruß
Enno
Gibt es im ABAP-Umfeld bei euch irgendwelche {Themen | Techniken | Praktiken}, über die ihr gerne mal einen {Leitfaden | Tutorial | Genaue Beschreibung} haben würdet?
Gibt es irgendwelche ABAP-Fallen, über die ihr oder eure Kollegen immer mal wieder stolpert?
Ärgert ihr euch häufiger über bestimmte "Programmierunarten" oder schlechte Umsetzungen bei Programmen, die ihr korrigieren oder warten müsste? Wenn ja, welche sind das?
Ich würde mich sehr über Antworten freuen!!
Herzlichen Dank und Gruß
Enno
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi Enno,
ich koennte mittlerweile ein Buch schreiben.
Hier nur ein paar Stichworte.
Programmierunarten die mich stoeren und die hier in den USA STANDARD sind!!!:
Keine Errorhandling. Nach Aufruf eines FuBas laesst der Programmierer sich alle Fehlercodes zurueckgeben, behandelt sie aber nicht. Ich sah gestern noch als Dokumentation nur "Who cares?".
Programm sind nicht aufgeraeumt. Es sind Datadeclarationen vorhanden oder Unterprogramme, werden aber gar nicht benoetigt.
Anderseits wird sogut wie gar nichts in den Programmen dokumentiert.
Import from Memory und Export to Memory ist nicht dokumentiert. Keiner weiss wo das Gegenstueck vom Import/Export ist, ganz besonders in EXIT's.
Variablennamen sind total verwirrend. Z.B. Con_farbe_rot value 'Gelb' oder GT_itab ist gar keine Tabelle sondern nur eine Struktur.
Einige Programme von immer den gleichen Programmierer sehen im Hauptprogramm immer gleich aus, egal wie klein.
Sechs Zeilen mit INLCUDE ... TOPINLCUDE oder DATA, SCREEN, MAIN, FORMS, PBO, PAI....
Das war nur ein kleiner Vorgeschmack.
Gruss Jurgen
ich koennte mittlerweile ein Buch schreiben.
Hier nur ein paar Stichworte.
Programmierunarten die mich stoeren und die hier in den USA STANDARD sind!!!:
Keine Errorhandling. Nach Aufruf eines FuBas laesst der Programmierer sich alle Fehlercodes zurueckgeben, behandelt sie aber nicht. Ich sah gestern noch als Dokumentation nur "Who cares?".
Programm sind nicht aufgeraeumt. Es sind Datadeclarationen vorhanden oder Unterprogramme, werden aber gar nicht benoetigt.
Anderseits wird sogut wie gar nichts in den Programmen dokumentiert.
Import from Memory und Export to Memory ist nicht dokumentiert. Keiner weiss wo das Gegenstueck vom Import/Export ist, ganz besonders in EXIT's.
Variablennamen sind total verwirrend. Z.B. Con_farbe_rot value 'Gelb' oder GT_itab ist gar keine Tabelle sondern nur eine Struktur.
Einige Programme von immer den gleichen Programmierer sehen im Hauptprogramm immer gleich aus, egal wie klein.
Sechs Zeilen mit INLCUDE ... TOPINLCUDE oder DATA, SCREEN, MAIN, FORMS, PBO, PAI....
Das war nur ein kleiner Vorgeschmack.
Gruss Jurgen
Genau das habe ich vor...Unit605 hat geschrieben:Hi Enno,
ich koennte mittlerweile ein Buch schreiben.
Ja, die Sachen sind echt "unschön" und erschweren die Fehlersuche oder die Erweiterung der Programme enorm.
Danke!
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
hallo Enno,
kann mich den Punkten von Jürgen nur anschliessen. Spontan würde mir noch folgendes einfallen:
* in sich verschachtelte SELECT´s
* mehrere nacheinander folgende MOVE-CORRESPONDING in den gleichen Zielbereich
* Abfrage in SELECT-ENDSELECT ob SY-SUBRC = 0 ist
* es wird sehr oft vernachlässigt von dem Einsatz von CALL TRANSACTION zu prüfen, ob der Benutzer die Transaktion auch wirklich ausführen darf
* weiterhin kommen bei uns die internen Tabellen zu kurz. Sie werden entweder gar nicht verwendet, weil alles im SELECT-ENDSELECT gemacht wird. Werden sie genutzt, dann meistens in der Form einer STANDARD-Tabelle. Dabei lässt sich hier mit Einsatz von SELECT...APPENDING TABLE und FOR ALL ENTRIES einiges an Performance rausholen...
kann mich den Punkten von Jürgen nur anschliessen. Spontan würde mir noch folgendes einfallen:
* in sich verschachtelte SELECT´s
Code: Alles auswählen.
SELECT * FROM...
SELECT * FROM...
SELECT SINGLE * FROM...
SELECT SINGLE * FROM...
SELECT SINGLE * FROM...
ENDSELECT
ENDSELECT
Code: Alles auswählen.
SELECT SINGLE * FROM MARA...
SELECT SINGLE * FROM MARC...
SELECT SINGLE * FROM MAKT...
MOVE-CORRESPONDING MARA TO GT_ITAB.
MOVE-CORRESPONDING MARC TO GT_ITAB.
MOVE-CORRESPONDING MAKT TO GT_ITAB.
Code: Alles auswählen.
SELECT * FROM mara.
IF SY-SUBRC = 0.
"ich habe einen Eintrag gefunden und mache was...
ENDIF.
ENDSELECT.
* weiterhin kommen bei uns die internen Tabellen zu kurz. Sie werden entweder gar nicht verwendet, weil alles im SELECT-ENDSELECT gemacht wird. Werden sie genutzt, dann meistens in der Form einer STANDARD-Tabelle. Dabei lässt sich hier mit Einsatz von SELECT...APPENDING TABLE und FOR ALL ENTRIES einiges an Performance rausholen...
Folgende Benutzer bedankten sich beim Autor Alexander D. für den Beitrag:
ewx
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
Danke Alexander!
Am besten finde ich tatsächlich den SELECT - ENDSELECT mit der Abfrage auf SY-SUBRC! Sicher ist sicher!
Ich würde gerne die Diskussion noch mal eher in diese Richtung lenken wollen:
Gruß Enno
Am besten finde ich tatsächlich den SELECT - ENDSELECT mit der Abfrage auf SY-SUBRC! Sicher ist sicher!
Ich würde gerne die Diskussion noch mal eher in diese Richtung lenken wollen:
Also so nach dem Motto: "Ich weiß nie, welchen Tree ich nun am besten nehmen soll" oder "Wenn ich einzelne ALV-Grid-Zellen einfärben möchte bin ich jedesmal wieder am Suchen, wie das geht".ewx hat geschrieben: Gibt es im ABAP-Umfeld bei euch irgendwelche {Themen | Techniken | Praktiken}, über die ihr gerne mal einen {Leitfaden | Tutorial | Genaue Beschreibung} haben würdet?
Gruß Enno
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
eins noch: wenn man schon dokumentiert, dann sollte man i.d.R. nicht schreiben WAS man im Code macht, sondern WARUM es gemacht wird. Immer wieder stolpere ich über solche Codings wie
oder
da könnte man die Kommentare auch gleich weg lassen...
Code: Alles auswählen.
"Materialstamm lesen
SELECT * FROM MARA
Code: Alles auswählen.
" erhöhe g_count im eins
g_count = g_count + 1.
Folgende Benutzer bedankten sich beim Autor Alexander D. für den Beitrag:
ewx
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
für uns wird in naher Zukunft das Thema "Programmierrichtlinie für ABAP" interessant. Zur Zeit gibt es bei uns keine Vorgaben, dementsprechend sehen auch unsere Programme aus. Da gibt es sicherlich schon einiges im Netz, ich bin bs jetzt noch nicht zum Suchen gekommen...ewx hat geschrieben: Gibt es im ABAP-Umfeld bei euch irgendwelche {Themen | Techniken | Praktiken}, über die ihr gerne mal einen {Leitfaden | Tutorial | Genaue Beschreibung} haben würdet?
für so etwas sollte doch jeder Entwickler ein Wiki oder eine Sammlung von Code-Schnipseln habenewx hat geschrieben: "Wenn ich einzelne ALV-Grid-Zellen einfärben möchte bin ich jedesmal wieder am Suchen, wie das geht".
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
Zum Thema ABAP Programmierrichtlinien gibt es ein ganzes Buch von Horst Keller:
http://www.sap-press.de/katalog/buecher ... telID-1922
Lustigerweise heißt es auch noch genau so...
http://www.sap-press.de/katalog/buecher ... telID-1922
Lustigerweise heißt es auch noch genau so...
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
Alexander D.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich muss gerade in einem ALV-Grid (mit LVC-FuBau erzeugt) einzelne Zellen eingabebereit schalten (nicht ganze Zeilen oder Spalten, wirklich zellenscharf.....ewx hat geschrieben: "Wenn ich einzelne ALV-Grid-Zellen einfärben möchte bin ich jedesmal wieder am Suchen, wie das geht".
Wer hat den entscheidenden Tipp für mich?
Gruß und danke
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hi Ralf,ralf.wenzel hat geschrieben: Wer hat den entscheidenden Tipp für mich?
würdest du dafür bitte einen eigenen Thread öffnen?!
Danke!
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
ich könnte noch ein paar allgemeine Dinge beisteuern:
-Es wird nicht an Archivierung gedacht (weder Historientabellen, noch SAP Archivierung, noch Archvierung von irgendwelchen Projektverzeichnissen, Lotus Notes Datenbanken etc.)
-Fehlerbehandlung im Livecycle, uralte Abweichungen, wenn sich keiner hinterklemmt werden sie nie behoben, das Projekt ist ja zum Glück vorbei.
-Mangelnde Dokumentation nicht nur im Coding, sondern auch drumherum. Wenn man Changes hat, wäre es auch schön, was der Inhalt derselben ist. Gut wäre z. B. eine Verlinkung auf Progammiervorgaben, Fachkonzepte, Use Cases, Abweichungen, Tickets. Die Quelldokumente sollten natürlich auch so gepflegt sein, das der Leser (Tester, abnehmende Fachabteilung) damit was anfangen kann.
-Wenn man Fehler gefunden aber noch nicht behoben hat, ist eine gute Doku der Workarounds mittels Wiki oder ähnlichem für Support Leistende sicher hilfreich.
Das meiste hier erwähnte ist natürlich nich Abap spezifisch, aber bei der Archivierung hat mir ein externer Mitarbeiter gesagt, dass das generell sehr gern unter den Tisch gekehrt wird. Wenn die Performance Probleme dann kommen bin ich ja längst nich mehr da.
ich könnte noch ein paar allgemeine Dinge beisteuern:
-Es wird nicht an Archivierung gedacht (weder Historientabellen, noch SAP Archivierung, noch Archvierung von irgendwelchen Projektverzeichnissen, Lotus Notes Datenbanken etc.)
-Fehlerbehandlung im Livecycle, uralte Abweichungen, wenn sich keiner hinterklemmt werden sie nie behoben, das Projekt ist ja zum Glück vorbei.
-Mangelnde Dokumentation nicht nur im Coding, sondern auch drumherum. Wenn man Changes hat, wäre es auch schön, was der Inhalt derselben ist. Gut wäre z. B. eine Verlinkung auf Progammiervorgaben, Fachkonzepte, Use Cases, Abweichungen, Tickets. Die Quelldokumente sollten natürlich auch so gepflegt sein, das der Leser (Tester, abnehmende Fachabteilung) damit was anfangen kann.
-Wenn man Fehler gefunden aber noch nicht behoben hat, ist eine gute Doku der Workarounds mittels Wiki oder ähnlichem für Support Leistende sicher hilfreich.
Das meiste hier erwähnte ist natürlich nich Abap spezifisch, aber bei der Archivierung hat mir ein externer Mitarbeiter gesagt, dass das generell sehr gern unter den Tisch gekehrt wird. Wenn die Performance Probleme dann kommen bin ich ja längst nich mehr da.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich habe einen Kunden, der sein Versionsmanagement im Coding macht: Nie Coding löschen, sondern nur auskommentieren mit Hinweis auf die Changenummer. So wird Coding unlesbar.
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
ewx
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
mir ist noch was eingefallen:
Falls Automatisierung geplant ist (Scripte für Entwickler und Tester) sollte auch etwas in die Richtung konzeptioniert und programmiert werden. Beispiel Erfolgsmeldung. Nicht "Der Vorgang wurde gespeichert.", sondern "der Vorgang wurde mit Vorgangsnummer & gespeichert". Die kann man dann nämlich auslesen und an ein Folgescript übergeben oder in der Datenbank checken etc.
In Auswertungen sind Einschränkungsfelder für Vorgangsnummern etc. hilfreich, da man nur einen Vorgang angezeigt bekommt. Es ist in einem Script leichter, die eine angezeigte Zeile im Dynpro auszulesen, als sich aus fünf Zeilen die gewünschte herauszusuchen.
Gruß
mir ist noch was eingefallen:
Falls Automatisierung geplant ist (Scripte für Entwickler und Tester) sollte auch etwas in die Richtung konzeptioniert und programmiert werden. Beispiel Erfolgsmeldung. Nicht "Der Vorgang wurde gespeichert.", sondern "der Vorgang wurde mit Vorgangsnummer & gespeichert". Die kann man dann nämlich auslesen und an ein Folgescript übergeben oder in der Datenbank checken etc.
In Auswertungen sind Einschränkungsfelder für Vorgangsnummern etc. hilfreich, da man nur einen Vorgang angezeigt bekommt. Es ist in einem Script leichter, die eine angezeigte Zeile im Dynpro auszulesen, als sich aus fünf Zeilen die gewünschte herauszusuchen.
Gruß
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Tutorialwünsche -- Das ist ja Klasse.
Ich suche immer noch einen leicht verständlichen Leitfaden zur Verwendung des Dataproviders.
Ich suche immer noch einen leicht verständlichen Leitfaden zur Verwendung des Dataproviders.
Vergleichbare Themen
1
Antw.
Antw.
1128
Views
Views
Umfrage zum Thema EWM
von rreichl » 23.10.2013 07:41 • Verfasst in Material Management & Produktionsplanung
von rreichl » 23.10.2013 07:41 • Verfasst in Material Management & Produktionsplanung
35
Antw.
Antw.
7410
Views
Views
22
Antw.
Antw.
7444
Views
Views
Umfrage: ABAP Objects / Webdynpro vs. classical Dynpro
von zeWa » 21.07.2014 13:35 • Verfasst in ABAP Objects®
von zeWa » 21.07.2014 13:35 • Verfasst in ABAP Objects®
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.