Function Group Vs Classes

  1. No instantiation : You cannot create multiple instances of the same function group.
  2. No inheritance : You cannot inherit from or let inherit function groups
  3. No interfaces : You cannot provide two implementations for the same function group. 
  4. No overloading : You cannot provide two functions with identical names but different parameters. (This is not possible in ABAP OO either, by the way.)
  5. No method encapsulation : While form routines allow you to organize your code, you cannot hide them from the outside world.

Recommended ABAP Syntax

1. MOVE 'A' TO variable.                 "OLD ABAP syntax
     DATA(variable) = 'A'.

2. TRANSLATE lowercase TO UPPER CASE.    "OLD ABAP syntax
    DATA(uppercase) = to_upper( lowercase ).

3. DATA(object) = NEW my_class( ).
   CREATE OBJECT object TYPE my_class.     "OLD ABAP syntax

4. result = VALUE #( FOR row IN input ( row-text ) ).
" LOOP AT input INTO DATA(row).          "OLD ABAP syntax      
"  INSERT row-text INTO TABLE result.
" ENDLOOP.

5.DATA(line) = value_pairs[ name = 'A' ]. " entry must exist
DATA(line) = VALUE #( value_pairs[ name = 'A' ] OPTIONAL ). " entry can be missing
" READ TABLE value_pairs INTO DATA(line) WITH KEY name = 'A'.  "OLD ABAP syntax

6. @ is used in the Select to say where a statement or variable belongs. Everything marked with @ in Select belongs to the program and is not part of the database statement.

This can be used to perform various actions in selects:

Definition of a table for the result (example above)
Transfer of parameters and select options
Usage of inline functions within a select 

# is also used as a new symbol in ABAP and describes the context-dependent data types, especially in the inline functions.

the @-escaped "host" variables in the following statement make a little clearer what's a program variable and what's a column in the database,

SELECT *
  FROM spfli
  WHERE carrid = @carrid AND
        connid = @connid
  INTO TABLE @itab.

as compared to the obsolete unescaped form

SELECT *
  FROM spfli
  WHERE carrid = carrid AND
        connid = connid
  INTO TABLE itab.

7. IF abap_type = cl_abap_typedescr=>typekind_date.
is clearer than

" anti-pattern
IF abap_type = 'D'.

8. Don't declare inline in optional branches

not correct
IF has_entries = abap_true.
  DATA(value) = 1.
ELSE.
  value = 2.
ENDIF.

Correct way

DATA value TYPE i.
IF has_entries = abap_true.
  value = 1.
ELSE.
  value = 2.
ENDIF.

9. Use the right table type

You typically use HASHED tables for large tables that are filled in a single step, never modified, and read often by their key. Their inherent memory and processing overhead makes hash tables only valuable for large amounts of data and lots of read accesses. Each change to the table's content requires expensive recalculation of the hash, so don't use this for tables that are modified too often.

You typically use SORTED tables for large tables that need to be sorted at all times, that are filled bit by bit or need to be modified, and read often by one or more full or partial keys or processed in a certain order. Adding, changing, or removing content requires finding the right insertion spot, but doesn't require adjusting the rest of the table's index. Sorted tables demonstrate their value only for large numbers of read accesses.

Use STANDARD tables for small tables, where indexing produces more overhead than benefit, and "arrays", where you either don't care at all for the order of the rows, or you want to process them in exactly the order they were appended. Also, if different access to the table is needed e.g. indexed access and sorted access via SORT and BINARY SEARCH.

10. Prefer INSERT INTO TABLE to APPEND TO

INSERT INTO TABLE works with all table and key types, thus making it easier for you to refactor the table's type and key definitions if your performance requirements change.
Use APPEND TO only if you use a STANDARD table in an array-like fashion, if you want to stress that the added entry shall be the last row.

11. Prefer LINE_EXISTS to READ TABLE or LOOP AT

IF line_exists( my_table[ key = 'A' ] ).

old syntax

LOOP AT my_table REFERENCE INTO DATA(line) WHERE key = 'A'.
  line_exists = abap_true.
  EXIT.
ENDLOOP.

12. Prefer READ TABLE to LOOP AT

13. Avoid unnecessary table reads

14. CONSTANTS some_constant TYPE string VALUE `ABC`.
DATA(some_string) = `ABC`.  " --> TYPE string
Refrain from using ', as it adds a superfluous type conversion and confuses the reader whether he's dealing with a CHAR or STRING:

" anti-pattern
DATA some_string TYPE string.
some_string = 'ABC'.

14. Use ABAP_BOOL for Booleans

Don't use the generic type char1. Although it is technically compatible it obscures the fact that we're dealing with a Boolean variable.

15. Use ABAP_TRUE and ABAP_FALSE for comparisons

has_entries = abap_true.
IF has_entries = abap_false.

16. Use XSDBOOL to set Boolean variables

DATA(has_entries) = xsdbool( line IS NOT INITIAL ).
The equivalent IF-THEN-ELSE is much longer for nothing:

" anti-pattern
IF line IS INITIAL.
  has_entries = abap_false.
ELSE.
  has_entries = abap_true.
ENDIF.

17. Prefer CASE to ELSE IF for multiple alternative conditions

CASE makes it easy to see a set of alternatives that exclude each other. It can be faster than a series of IFs because it can translate to a different microprocessor command instead of a series of subsequently evaluated conditions.

18. Keep the nesting depth low

Nested IFs get hard to understand very quickly and require an exponential number of test cases for complete coverage.

19. Prefer simpler methods to regular expressions