Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

We suggest the following conventions / standards when working in FAB:

ABAP Code

For naming standards and conventions in ABAP, please navigate here.

Data model - naming fields

We recommend different naming strategies for naming data model fields, depending on the source/target of the data field in question.

  1. When using an OData Service, we recommend matching the name and case of data model field to that of the corresponding field in the OData Service.
  2. When using ABAP fields (imported from an SAP Function Module / Screen / BDC / Structure or Table) we recommend matching the name of the data model field to the name in the corresponding SAP source / target field. We recommend keeping the name in UPPER CASE.
  3. When defining these during development, we recommend capitalising the first letter of every word - something like:
    MyDataFieldName.

Data model - description fields

We often have two fields where the first field contains a code and the second field (used as a label, description or tool-tip, for example) contains the name / description for the code contained in the first field. To avoid variation (Name vs Description vs Desc vs Descr vs Text vs Xxxx) we recommend always using 'Name'. Therefore:

  1. In most instances, we recommend that the two fields should be named the same, but the description field has the word 'Name' appended to the end. For example:
    1. CostCenter and CostCenterName

    2. ControllingArea and ControllingAreaName

  2. In instances where a field is named XxxCode or YyyKey (or similar) we recommend dropping the 'Code' or 'Key' and replacing it with 'Name' for the description field, for example:

    1. CompanyCode and CompanyName

    2. CurrencyKey and CurrencyName

      Exception: where the word 'Key' is part of the name, as opposed to simply indication that the field contains a code/key, it may remain part of the description field name:

    3. PostingKey and PostingKeyName

Data model - explicit typing

It is important to remember that the data model is the 'area of exchange' through which data is effectively passed from the front-end to the back-end, and vice versa. During this process, conversion takes place between the data as it is declared in the front-end and the equivalent data as it is declared in the back-end (in ABAP).

...

The exception to this is where the field should be declared as a text-type field in both the front- and back-end. In this instance, FAB will assume both to be text in the absence of explicit typing.

Component / Element ID - naming 

Please remember that components / elements in your project do not always have to be named explicitly - if no ID is assigned, FAB will assign one at run-time. Where you do want to name these (for readability, for example, or to be able to refer to the component in code) we recommend a flexible approach, using a simple set of rules to determine a 2- or 3-character prefix:

...