Goldene Regeln der Programmierung

Hinweise, Tips und Tricks, FAQs - keine Anfragen!!
50 Beiträge • Seite 1 von 4 (current) Nächste
50 Beiträge Seite 1 von 4 (current) Nächste

Goldene Regeln der Programmierung

Beitrag von zzcpak (Expert / 673 / 5 / 67 ) »
Es täte mich mal interessieren, was für euch als Programmierer als "goldene Regeln" der ABAP-Programmierung anzusehen ist.


Für mich wäre das z.B. folgendes:


Oftmals steht man vor der Aufgabenstellung, SAP-Standard-Tabellen zu manipulieren (z.B. um Drucker zu sperren o.ä.). Die Aufgabensteller, oftmals mit äußerst ungesundem Halbwissen gesegnet, haben dann auch gleich die passenden Tabellen nebst zu änderndem Feld gefunden, wo man mit "einem einfachen UPDATE die Einträge ändern kann".


Es kostet meist einige Überredungskünste, sie davon wieder abzubringen und davon zu überzeugen, daß es für die allermeisten Fälle diverse Funktionsbausteine gibt, die die gestellte Aufgabe zur Zufriedenheit erfüllen und bei denen man vor unliebsamen Seiteneffekten sehr viel sicherer sein kann.


Goldene Regel Nr. 1 für mich wäre also:
  • Niemals Standard-Tabellen direkt manipulieren, sondern ausschließlich mit den passenden Funktionsbausteinen, Report, Programmen (evtl. über BATCH-INPUT).

(Nebenbei bemerkt wäre es ganz nett, wenn man seine Texte hier ein wenig formatieren könnte. Ein solch spartanischer Editor ist mir in Foren nicht mehr untergekommen, seit ich mit meinem ersten 14,4 Modem einen Geschwindigkeitsrausch bekam)

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


goldene regel

Beitrag von joachim (ForumUser / 70 / 0 / 2 ) »
meine goldene regel no. 1 ist, niemals ein programm ohne


auswertung via se30 freizugeben


joachim

Beitrag von cosmo (Specialist / 175 / 0 / 0 ) »
Regel Nr 1: Verwende so wenig globale Variablen wie möglich!

Meine Erfahrung hat mir gezeigt, dass globale Variablen eine sehr bösartige Fehlerquelle sein können. Programme, die alle benötigten Informationen als Parameter an Unterprogramme übergeben und die Ergebnisse wieder als Rückgabeparameter übernehmen, sind dagegen viel besser zu lesen. Auch wenn man mehr tippen muss.

Regel Nr 2: Vermeide das Kopieren von Coding!

Sowohl das Kopieren von ganzen Sourcen als auch von größeren Bereichen in Programmen verursacht gefährliche Redundanzen. Wenn an der kopierten Logik etwas zu ändern ist, muss man mehrfach ändern. Versuche also immer, ein Unterprogramm oder wenigstens ein Makro zu nutzen!

Regel Nr. 3: Gehe sparsam mit Kettenbefehlen um (write: / matnr, maktx, ... )

Macht man sich die Mühe, z.B. write-Befehle oder datas jeweils extra zu codieren, fällt später das Umstellen der Reihenfolge oder auch das Einfügen einzelner Anweisungen viel leichter. Einfach die Zeile mit der Maus verschieben! Ich benutze auch "new-line" anstatt "write /".
Jörg Krause, Anwendungsentwickler und SAP-Betreuer MM/PP

Kommentare im Code

Beitrag von crayfish (ForumUser / 16 / 0 / 0 ) »
Für bestimmte Blöcke, Unterprogramm, Datenfelder, Historie Kommentar zu hinterlegen ist für mich eine goldene Regel:

Blöcke:
- was passiert in diesem logischen Block
- warum macht man manche Dinge so und nicht anders

Unterprogramm:
- Kurze Funktionsbeschreibung
- Parameter und mögliche Rückgabwerte

Datenfelder:
- halbwegs sprechende Namen (deutsch oder englisch)
- Namenskonventionen ('t' für Tabelle, 's' für Struktur/Workarea, Sichtbarkeit: 'g' global, 'l' lokal, 'p' parameter...)

Historie:
- im Kopf (wer hat, was, wann, wieso geändert)
- in den jeweiligen Zeilen (Zeilen nicht löschen, sondern nur auskommentieren ...)

uvm.

...

Grüße

Cray

Beitrag von cosmo (Specialist / 175 / 0 / 0 ) »
Regel Nr 4: Verwende Typdefinitionen!

Die vereinfachte Form von DATA BEGIN OF /END OF, und DATA ... LIKE TABLE erzeugen Datenobjekte, die sich nicht typisiert an Unterprogramme übergeben lassen. Damit kommen wir auch schon zur...

Regel Nr 5: Verwende möglichst Parameter in Unterprogrammen (FORM...)

Es macht das Programm viel besser lesbar, wenn z.B. anstatt

Code: Alles auswählen.

perform material_lesen
dasteht:

Code: Alles auswählen.

perform material_lesen using lv_matnr changing ls_mat
Die Routinen werden dadurch auch vielseitiger einsetzbar!

Regel Nr 6: Verwende Präfixe zur Verdeutlichung der Beschaffenheit von Variablen

meine aktuelle Nomenklatura ist:
GS_... Globale Struktur
GT_... Globale Tabelle
GV_... globale Einzelvariable
GC_... globale Konstante
LS_... Lokale Struktur usw.
US_... Using-Struktur
CS_... Changing-Struktur
Natürlich nur als Anregung. In größeren Teams ist allerdings eine einheitliche Festliegung sinnvoll.
Jörg Krause, Anwendungsentwickler und SAP-Betreuer MM/PP

Beitrag von ion ( / / 0 / 3 ) »
Regel Nr 6: die goldenste Regel : Kommentare

Kommentare an den richtigen stellen. Kurz und bündig. Einleitende Kommentare + Dokumentation der Inserts & Delets inkl. Namen/Datum/Changeauftrag etc. je nach Organisation, aber einheitlich.

aber : keine Kommentarüberlastung.

Regel Nr 7: Übersichtlicher Programmierstil

- Pretty Printer verwenden (sofern möglich)
- aussagekräftige, kurze Variablen benutzen
- Funktionsbausteine nach Muster überflüssige Zeilen löschen
- etc.

.. so dass auch Andere oder ich selbst nach nem Jahr schnell erkenne, welche Bedeutung diese Programmzeilen haben :)

Beitrag von M. Lahr (Specialist / 109 / 0 / 0 ) »
Eine kleine Anleihe aus einem Perl Buch: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

Beitrag von babap (Expert / 681 / 1 / 1 ) »
Hallo,

meine goldene Regel zu internen Tabellen:

Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.

Code: Alles auswählen.

DATA: lt_tabelle TYPE irgendeine Tabelle.
FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle.

* füllen
APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-Feld1 = ...

LOOP AT lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-feld2 = ...
* mach sonstwas
ENDLOOP.

READ TABLE lt_tabelle assigning <lt_tabelle>
index Zahl.
* oder 
...
with key feld1 = 'XX'
.
Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".

Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen

Code: Alles auswählen.

APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
Gruß
babap

Re: Goldene Regeln der Programmierung

Beitrag von cosmo (Specialist / 175 / 0 / 0 ) »
(meine) Regel Nr. 7: Klassen verwenden

Die Verwendung von Reports mit Form-Routinen wurde von SAP durch das wesentlich bessere Konzept von Klassen und Methoden abgelöst. Ich vermeide, wo es geht, überhaupt Reports anzulegen. Muss ich einen Online-Report schreiben, lege ich eine Klasse mit einer MAIN-Methode an, die ich direkt mit der Transaktion verknüpfe. Alles weitere mache ich dann in den Methoden der Klasse.

Da Hintergrundprogramme doch einen Report benötigen, lege ich in diesem Fall immer einen minimal-Report an:

Code: Alles auswählen.

report ...

parameters p_mypar as checkbox.

data go_myapp type ref to zcl_myapp.

start-of-selection.

   create object go_myapp.
   go_myapp->set_mypar( p_mypar ).
   go_myapp->main( ).

Das mache ich auch, wenn ich einen Selektionsschirm benötige (obwohl man den auch in eine function library packen könnte...)

Regel Nr. 8: Trenne Verarbeitungslogik von Bildschirmlogik

Ein Beispiel: In einem Programm soll eine Materialnummer abgefragt werden, für die daraufhin eine Anzeige von ausgewählten Materialstammfeldern erfolgen soll. In so einem Fall lege ich einen Funktionsbaustein an, der das Dynpro ruft:

Code: Alles auswählen.

* Eingabeparameter des FUBA: is_screen
* Ausgabeparameter: es_screen, ev_ucomm

* Die Funktionsbibliothek verwaltet die Bildschirmdaten als globale Struktur:
  gs_screen = is_screen.
  call screen 1.
  es_screen = gs_screen.
  ev_ucomm = sy-ucomm.

Das Dynpro 1 ist so gehalten, dass es bei jeder Benutzerinteraktion sofort einen set screen 0 macht. Die rufende Methode macht dann in etwa folgendes:

Code: Alles auswählen.


  do.
    call function 'Z_SHOW_THE_SCREEN'
       exporting
          is_screen = ls_screen_defaults
       importing
         es_screen = ls_screen_inputs
         ev_ucomm = lv_user_command.
 
    process_input( ls_screen_inputs ).
    lv_exit = process_user_command( lv_user_command ).
    if lv_exit = abap_true.
      exit.
    endif.
  enddo.
Der Vorteil? Auf diese Weise entstehen Klassen mit der Verarbeitungslogik, die man problemlos an anderen Stellen verwenden kann (z.B. für Webdynpro, RFC-Calls oder sonstiges).
Jörg Krause, Anwendungsentwickler und SAP-Betreuer MM/PP

Re: Goldene Regeln der Programmierung

Beitrag von Alpha (ForumUser / 25 / 0 / 0 ) »
Nr. 99

Verwende nicht immer die gleichen Funktionsgruppen und Pakete.
Gruss

Alpha

Re: Goldene Regeln der Programmierung

Beitrag von UserBC (ForumUser / 61 / 0 / 1 ) »
Meine Regeln:

Regel 1:
Verwende möglichst Klassen und Methoden statt Funktionsgruppen und FuBa's

Regel 2:
Manipuliere in einer Methode keine globalen Variablen, sondern nur Aktualparameter.

Regel 3:
Manipuliere Standardtabellen niemals direkt, sondern immer per Batch-Input.

Regel 4:
Übergebe Variablen soweit sinnvoll (und nicht zu riskant) immer per Referenz.

Regel 5:
Verwende Feldsymbole statt Workareas, es sei denn du benötigt noch eine Prüfung,
bevor du entscheidest, ob du die Tabelle aus dem Workarea updatest oder
ob du die manipulierten Daten aus dem Workarea verwirft.

Regel 6:
Verwende nie die Listenausgabe per write, sondern verwende immer eine ALV.

Regel 7:
Bezieh dich bei der Variablen-Deklaration immer auf auf eine Dict-Typ,
falls kein passender vorhanden ist; lege einen an und versorge Ihn mit den
entsprechenden Metadaten, Übersetzungen und Dokumentationen.

Re: Goldene Regeln der Programmierung

Beitrag von kotelna (ForumUser / 27 / 2 / 0 ) »
No 1. Hole aus der Datenbank nur das, was du wirklich brauchst.

Code: Alles auswählen.

SELECT COUNT(*)
statt

Code: Alles auswählen.

SELECT SINGLE *

Code: Alles auswählen.

SELECT ... field1 field2...
statt

Code: Alles auswählen.

SELECT *
No 2. Hole 1x ganze customizing Tabelle, als 100x das gleiche aus Datenbank lesen.

Code: Alles auswählen.

INITIALIZATION.
SELECT field1 field2
INTO TABLE gt_t...
FROM t...

FORM ....
READ TABLE gt_t...
No 3. Entsprechenden Tabellentyp nutzen.
Hashed für customizing.
Sorted für die Tabellen, wo ich ein LOOP oder READ TABLE mache.
Standard für den Rest.

No 4. Tabellenoperationen verwenden.

Code: Alles auswählen.

TYPES: BEGIN OF t_matnr,
             matnr type matnr,
           END OF t_matnr.
DATA:  gt_mara TYPE TABLE OF mara,
       gt_matnr TYPE TABLE OF t_matnr.
....
gt_matnr = gt_mara.

Re: Goldene Regeln der Programmierung

Beitrag von ereglam (Top Expert / 1829 / 2 / 7 ) »
kotelna hat geschrieben:...
No 4. Tabellenoperationen verwenden.

Code: Alles auswählen.

TYPES: BEGIN OF t_matnr,
             matnr type matnr,
           END OF t_matnr.
DATA:  gt_mara TYPE TABLE OF mara,
       gt_matnr TYPE TABLE OF t_matnr.
....
gt_matnr = gt_mara.
bei diesem Beispiel bin ich nicht der Meinung, dass es das Ergebnis erzielt, welches beabsichtigt ist.
Wenn ich es richtig verstehe, soll die Materialnummer von der GT_MARA in die GT_MATNR übertragen werden. Das kann aber so m.E. nicht funktionieren, denn die Struktur MARA hat als erstes Feld den Mandanten und dann erst kommt die Materialnummer.
Gruß
Ereglam


May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .

Re:

Beitrag von doceX (ForumUser / 4 / 0 / 0 ) »
babap hat geschrieben:Hallo,

meine goldene Regel zu internen Tabellen:

Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.

Code: Alles auswählen.

DATA: lt_tabelle TYPE irgendeine Tabelle.
FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle.

* füllen
APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-Feld1 = ...

LOOP AT lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-feld2 = ...
* mach sonstwas
ENDLOOP.

READ TABLE lt_tabelle assigning <lt_tabelle>
index Zahl.
* oder 
...
with key feld1 = 'XX'
.
Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".

Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen

Code: Alles auswählen.

APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
Gruß
babap

Ebenfalls auch eine gute Möglichkeit welche kein Modify benötigt sind Referenzen.

Code: Alles auswählen.

DATA: lt_tadir type table of tadir,

Re: Re:

Beitrag von doceX (ForumUser / 4 / 0 / 0 ) »
doceX hat geschrieben:
babap hat geschrieben:Hallo,

meine goldene Regel zu internen Tabellen:

Verwende Feldsymbold statt impliziter Kopfzeile oder Workarea.

Code: Alles auswählen.

DATA: lt_tabelle TYPE irgendeine Tabelle.
FIELD-SYMBOLS: <lt_tabelle> LIKE LINE OF lt_tabelle.

* füllen
APPEN INTITIAL LINE TO lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-Feld1 = ...

LOOP AT lt_tabelle ASSIGNING <lt_tabelle>.
<lt_tabelle>-feld2 = ...
* mach sonstwas
ENDLOOP.

READ TABLE lt_tabelle assigning <lt_tabelle>
index Zahl.
* oder 
...
with key feld1 = 'XX'
.
Man "fährt" direkt auf der Tabellenzeile rum und muß sie nicht "modifyen".

Man kann die Zeile auch komplett an eine gleich strukturierte Tabelle anfügen

Code: Alles auswählen.

APPEND <lt_tabelle> to LT_TAB2 (ASSIGNING <lt_tab2> "wenn man will").
Gruß
babap

Ebenfalls auch eine gute Möglichkeit welche kein Modify benötigt sind Referenzen.

Code: Alles auswählen.

DATA: lt_tadir type table of tadir,

Zusatz zum obigen Beitrag :) *Wurde zu früh gesendet 8)

Code: Alles auswählen.

DATA: lt_tadir type table of tadir,

Code: Alles auswählen.

          lr_tadir type ref to tadir.

Code: Alles auswählen.

DATA: l_obj_name type sobj_name.

Code: Alles auswählen.

LOOP AT lt_tadir REFERENCE INTO lr_tadir.

Code: Alles auswählen.

  l_obj_name = lr_tadir->obj_name

Code: Alles auswählen.

ENDLOOP.
Gruss doceX

Vergleichbare Themen

1
Antw.
1645
Views
Regeln für automatischen Ausgleich
von Buetzy » 06.08.2008 11:10 • Verfasst in Financials
2
Antw.
516
Views
SAP Entwicklungssystem und RFC Programmierung
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
1
Antw.
2032
Views
GUI Programmierung: Dynpro?
von fabis » 01.03.2012 20:35 • Verfasst in ABAP® für Anfänger
0
Antw.
1169
Views
0
Antw.
1296
Views
Unicodevorgaben bei der Programmierung
von JürgenFFM » 07.11.2007 11:29 • Verfasst in Dialogprogrammierung

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140