You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
Code should be as left leaning (no pun intended) and one dimensional as possible, enhancing its readability from top to bottom and not adding a left to right dimension to it.
This rule advises people to do the exact opposite, harming readability and split screen code editing possibilities (and often times contradicting the 80 or the, god forbid, 120 character limit).
It also harms Vim Motions users (and SE80 users who use two GUI windows) by forcing them to scroll through a row instead of lines to read what's there.
You often times have calling functions/methods on the left and called functions/methods on the right (in either different SAP GUI screens or ADT split screens), so this scenario should be familiar to a lot of people.
"Space efficiency" is cited as a reason to do this, but I fail to see how minimizing this miniscule amount of LOC efficiency amounts to anything (performance, readability, developer experience...in that exact order) and does anything for anybody. To the contrary, it makes code harder to read and work with, it has no technical meaning (in terms of performance or so), so why?
Line breaks should be seen as a feature, not a bug (if used correctly).
The latter example also has the benefit of not leaving satements "dangling in the air" (again harming readability), but closing them on the same logical and semantic level that they were started on. So it actually enhances readability (on top of code being as one dimensional as possible).
It also reduces horizontal width to its minimum, which should be prioritized over any LOC improvement at all times.
P.S the latter example also allows for smashing together multiple statements without harming readability, since there's the ). to give follow up statements some space to breathe.
Relevant sections of the style guide
#https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#close-brackets-at-line-end
and all the mistakes that follow from this rule.
Description
Code should be as left leaning (no pun intended) and one dimensional as possible, enhancing its readability from top to bottom and not adding a left to right dimension to it.
This rule advises people to do the exact opposite, harming readability and split screen code editing possibilities (and often times contradicting the 80 or the, god forbid, 120 character limit).
It also harms Vim Motions users (and SE80 users who use two GUI windows) by forcing them to scroll through a row instead of lines to read what's there.
You often times have calling functions/methods on the left and called functions/methods on the right (in either different SAP GUI screens or ADT split screens), so this scenario should be familiar to a lot of people.
"Space efficiency" is cited as a reason to do this, but I fail to see how minimizing this miniscule amount of LOC efficiency amounts to anything (performance, readability, developer experience...in that exact order) and does anything for anybody. To the contrary, it makes code harder to read and work with, it has no technical meaning (in terms of performance or so), so why?
Line breaks should be seen as a feature, not a bug (if used correctly).
The latter example also has the benefit of not leaving satements "dangling in the air" (again harming readability), but closing them on the same logical and semantic level that they were started on. So it actually enhances readability (on top of code being as one dimensional as possible).
It also reduces horizontal width to its minimum, which should be prioritized over any LOC improvement at all times.
P.S the latter example also allows for smashing together multiple statements without harming readability, since there's the ). to give follow up statements some space to breathe.
Examples
Since when did this:
Become more attractive than this:
The text was updated successfully, but these errors were encountered: