abaplint rule for field-symbols naming

[sbcgua]

@larshp
I think we discussed it before but just to give it another try :)

Can we remove mandatory prefixes for field symbols ?

field-symbols <i> like line of lt_tab.
" instead of <ls_i>
loop at lt_tab assigning <i>.
  ...

field-symbols <tadir> like line of lt_tadir.
" instead of <ls_tadir>
loop at lt_tadir assigning <tadir>.
  ...

• field symbols are always local and very distinctly separated by the syntax (<>)
• field symbols are usually iterators - their short name usually make code more readable (not always).

It's just so much cleaner without prefixs inside those brackets

"No" would be OK, just wanted to rise this discussion again.

[mbtools]

For me, it's an all or nothing decision: All variables have prefixes in AG.

PS: I have projects without any prefixes and generally like that better now, but AG has a different history.

[sbcgua]

I wouldn't mix it together. At least it is not so for me. Below is just my own opinion.

For the variables I'm quite neutral. Sometime I do this or that way. And I can justify it: there is no clear way to distinguish outgoing vars in abap. And also members access is possible without me-> (which was a bad idea imho). And so if I name returning values r._ and members m._ maybe keeping prefixes for others is not super bad. And so it is not annoying. For me.

But field symbols are annoying :) because they are local. And used a lot in loops. With multiple access. So I desire to reduce the clutter. And prefixes are clutter here. I just see not any reason to use them in FS.

IMO of course. Just to clarify my perspective.

[pokrakam]

Personally I think local prefixing is the least useful in short modules, prefixing non-local elements is less offensive but then too I think scope prefixing has the most relevance. loop at m_items is sufficient, mt_items is not needed.

I think one way to migrate or have multiple naming standards is to mandate everything consistent within a class, but abapLint can't check that.

As to me-> I think that's fine as is. In short methods anything non-local is assumed an attribute. Less typing, less reading, less clutter. If we really want to distinguish then I much prefer m_.
I like using g_ regardless as globals are to be avoided and it makes them stand out (and the German word 'Gefahr' means danger, which makes it an even more appropriate prefix).

If returning variables are always called result then no r_ prefix is needed.

Oh, and one bugbear I have is projects that insist on calling them <fs_item>.

[larshp]

all or nothing, keep all or remove all, dont add more coding standards into the same codebase