Chapter "Avoid abbreviations" about styleguides HOT 7 OPEN

Thanks for the contribution, but... 😉

Please use English for issues, pull requests, and discussions. Due to the wide-spread presence of English as a second language, SAP uses English as its common language to facilitate cross-culture communication.

from styleguides.

Done ! :-)

from styleguides.

and the title?

from styleguides.

Done

from styleguides.

The online help also provides some good guidance on when to abbreviate and when to remove vowels.

See under Descriptive Names:
You should avoid using abbreviations as name components wherever possible. Exceptions to this rule are abbreviations that are usually used instead of the complete term, such as GUI or XML. However, if the use of certain abbreviations cannot be avoided due to restricted space, you should initially use common abbreviations.

If no common abbreviation exists, you should proceed as follows: Vowels are omitted, unless they are the first letter of the word. They are of minor significance for the recognition value. If a word starts with a double vowel, both letters are kept for ease of recognition (for example, outbnd as the abbreviation for outbound instead of otbnd). If further abbreviations are required, you can replace double consonants with single consonants. Even after this step, the word is generally still recognizable.

Or in German here

from styleguides.

#253

from styleguides.

I think the suggestion in the guide is actually correct, but as so often not sufficiently explained. Here's my take on how getting rid of unimportant words makes more sense than abbreviating vowels.

For instance, in languages with unrestricted identifier length (which is, uh, all languages that aren't ABAP...), it's common to have long unit test names of the form given_X_when_Y_then_Z, where X, Y, Z can be quite elaborate identifiers themselves.

This obviously doesn't work in ABAP, but is the variant gvn_x_wn_y_thn_z, where x, y, z, are the vowel-reduced forms of X, Y, Z, really what we consider the correct and readable solution? I think it isn't - in this case it's much better to encode one of the three given/when/thens into the name of the test class, and the rest into the name of the test method. Then we have 60 characters to work with, which gives much more breathing room to not have to resort to consonant messes. And if the convention is given_X=>when_Y_then_Z, then we might as well omit part of this and just choose X=>Y_then_Z.

This is my interpretation of the "start with the unimportant words" suggestion - we got rid of the given and when without losing information or readability. In other common cases, such "unimportant" words are often get_ (is there really any danger of someone having a harder time interpreting data(customer_name) = customer->name( ). than data(customer_name) = customer->get_name( ).?) or repeating the name of the type in the method name (customer->set_customer_name( name ). is not better than customer->set_name( name ) .. If someone names their customer object instance in a way that they can't see it's a customer, that's their naming problem, not mine.)

Of course, you might not have any such unimportant words and still hit the character limit. In that case, I agree the vowels will have to go :)

from styleguides.