basis-entwicklung allg.

Teile Dein Wissen oder 'tue Gutes und rede darüber...'!

Du hast einen bahnbrechenden Funktionsbaustein oder eine tolle Object-Klasse geschrieben, die zu schön ist, um unbeachtet zu versauern? Teile Deinen Schatz, in dem Du Ihn in die ...Reuse-Library einstellst (Transaktion SLIB bzw. SE83). Vergiss dabei die Dokumentation nicht, aber die hast Du ja sowieso schon erstellt, gelle? Du kannst hier aber auch Texte, Internetlinks oder sonst irgendwelche Dateien einstellen, von denen Du glaubst, dass sie auch andere interessieren könnten. Nimm aktiv an einschlägigen Internetforen teil (z.B. abapforum.com), teile Dein Wissen und profitiere vom Expertenwissen anderer.

Sei schlau, nutze ALV...!

Sofern es für die Art der Ausgabe Deines Programmes sinnvoll ist, nutze die ALV-Funktionsbausteine (REUSE_ALV...). In der Reuse-Library findet Du den Punkt 'ALV für Faulpelze', hierunter findest Du umfassendes Vorlage- und Anschauungsmaterial. Für Protokolle und Logs kann es sinnvoll sein, die Standard-Anwendungslog-Funktionalitäten zu nutzen (vgl. Demo Reports SBAL_DEMO*). Auch hierzu findest Du entsprechende Reuse-Komponenten.

Sei geschwätzig - Reden bzw. Schreiben ist Gold, Schweigen ist Blech...!

Informiere den Anwender über Dein Tun z.B. mit entsprechenden Fortschrittsmeldungen (FuBa SAPGUI_PROGRESS_INDICATOR) und geize nicht mit Statusmeldungen (Meldungstyp S) auch bei Batch-Programmen. Gib aussagekräftige und differenzierte (Fehler-)Meldungen zurück. Dies gilt auch für Ausnahmen bei Klassen oder Funktionsbausteinen ('AN_ERROR_OCCURED' ist so hilfreich wie 'Schutzverletzung an Adresse A4711783BC5'...).

Sei edel, gut und insbesondere hilfreich...!

Gehe nicht davon aus, dass ein Anwender (oder Entwickler) mit einer Fehlermeldung a la 'Fehler beim Lesen der Tab. XYZ' oder ähnlichem Zeug etwas anfangen kann. Hänge hinter Deine Fehlermeldungen eine aussagekräftige Dokumentation (Langtext) und vergiss dabei den Part 'Vorgehen...' nicht.

Hinterlege eine Programmdokumentation an Deinen Programmobjekten (F1-Hilfe). Sei hierbei so detailliert und umfänglich wie nötig, d.h. im Einzelfall kann auch ein Verweis auf ein bestehendes, dem Anwenderkreis zugängliches Word-Dokument völlig ausreichend sein. Sorge dafür, dass hinter allen nicht selbsterklärenden Oberflächenobjekten (Felder, Selektionsparameter, ...) eine F1-Hilfe hängt (durch Referenz auf ein [eigenes] Datenelement mit Doku bzw. durch Ausgestaltung des Zeitpunkts AT SELECTION-SCREEN ON HELP-REQUEST).

Nutze die Gestaltungsmöglichkeiten des Selektionsbildes, die ABAP bietet z.B. Subscreens, TabStrips usw. (vgl. SELECTION-SCREEN...).

Nutze die Verweisfunktion beim Gestalten Deiner Hilfetexte, z.B. aufs Glossar oder die Dokumentation von Datenelementen. Eine Auflistung aller hierbei zur Verfügung stehenden Objekte findest Du in der Reuse-Library oder auf tricktresor.de.

Sei hart im Nehmen, aber programmiere weich...!

Hoffe das Beste aber erwarte das Schlimmste. Frage den SY-SUBRC ab. Gehe davon aus, dass DB-Operationen auch mal schief gehen können. Informiere den Anwender in angemessener Form (vgl. Gebot 'Sei geschwätzig...').

'Verdrahte' nichts hart in Deinem Coding (IF KUNNR = '4711'.). Erstelle ggf. eigene Customizingtabellen/-objekte, die Du mit der Transaktion S_IMG_EXTENSION in den IMG an geeigneter Stelle modifikationsfrei hinzufügen und dokumentieren kannst. Hierzu findest Du eine ausführliche Anleitung in der Reuse-Library. Superprofessionell sieht auch ein Viewcluster aus (mehrstufiger Customizing-Dialog). Ein ausführliches Tutorial findest Du auf Tricktresor.de

Sei weltmännisch...!

Achte darauf, dass Deine Entwicklungen der Globalisierung standhalten, d.h. ggf. übersetzbar sind. Verwende deshalb keine Textliterale (WRITE: / 'Hallo Du da...'), sondern Textsymbole oder andere geeignete Objekte und achte auf Unicode-Fähigkeit.

Wenn Du eigene Tabellen kreierst, arbeite ggf. mit separaten Texttabellen (analog zum SAP-Standard, z.B. T003/T003T).

...