Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Close brackets at line end] rule is the root of all right leaning code in ABAP #356

Open
hansdampfinger666 opened this issue Jul 4, 2024 · 2 comments
Labels
Adjustment Of Rule The issue or PR proposes an adjustment of a rule or set of rules clean-abap

Comments

@hansdampfinger666
Copy link

hansdampfinger666 commented Jul 4, 2024

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:

modify->update( node           = if_fra_alert_c=>node-item
                key            = item->key
                data           = item
                changed_fields = changed_fields ).

Become more attractive than this:

modify->update( 
  node            = if_fra_alert_c=>node-item
  key             = item->key
  data            = item
  changed_fields  = changed_fields
).
@hansdampfinger666 hansdampfinger666 added Adjustment Of Rule The issue or PR proposes an adjustment of a rule or set of rules clean-abap labels Jul 4, 2024
@mAltr
Copy link
Contributor

mAltr commented Jul 5, 2024

Same as #353.

@mbtools
Copy link

mbtools commented Nov 27, 2024

Suggest closing since it's a duplicate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Adjustment Of Rule The issue or PR proposes an adjustment of a rule or set of rules clean-abap
Projects
None yet
Development

No branches or pull requests

3 participants