ABAP restrictions: keep it to 72 characters – really?
Once upon a time, long ago there where certain restrictions.
Like: Ram was precious. Disc space was scarce.
This led to some “best practices” or rules that probably still stick with people (maybe not even knowing the history), although they don’t make sense anymore.
One example is not using “speaking” naming, but encoding meaning into short, arbitrary codes. “Order Creation” is V45 (SPMV45A), “Delivery Creation” is V50 (SAPMV50A).
Makes sense to you? Well congratulation, then you are in the business from some time already, nice.
Anyways, I though the rule “a line of coding may not be more than 72 characters!” would be one of this arcane, neglectable rules.
Surely this doesn’t matter in a modern (say S/4HANA 1909, FPS2) SAP-system, right?!
Well, you guessed it – it does still matter! There are cases, that do hurt quite much (as in: dump!) if you use a character to much.
Wanna try it out?! Here’s my example:
I your sandbox got to RM07IMAT, put in a line with more than 72 characters.
MI22, F8, ctrl+shift+F12-> dump:
There are quit some SAP Notes for READ_REPORT_LINE_TOO_LONG – at least the ones I checke don’t solve that problem by just allowing more that 72 chars already.
They all alter the code to keep to this restriction.
So: how long are your ABAP code lines?
As a JAVA programmer I have two words for you: HAAA HA! 😉
That’s just cruel=)
C’mon it’s just gallows humor. Every programming language has it’s strengths and weaknesses.
Edit: ...and legacy burdens.
Do you have a sadistic and masoschist personality to read ABAP blog posts then? ?
Hopefully, any ABAP program developed since 2001 (ABAP 6.10) doesn’t have to be limited to 72 characters anymore. Only legacy programs eventually suffer this limit.
Actually I think any report - old or new - will suffer from that if it is put into FM K_KKB_FIELDCAT_MERGE (Like it happens in e.g. MI22 ).
So anything more the 72 char, this will give the mentioned dump. 🙁
DDIC-Structure RSSOURCE consist of Data-Element EDPLINE, Domain EDPLINE, and that's a CHAR 72. -> How about a filed length-extension here? That would be nice!
"Only legacy" doesn't mean that there are "few". But only those which call K_KKB_FIELDCAT_MERGE (and all derived FMs like REUSE_ALV_FIELDCATALOG_MERGE) with the parameter I_STRUCNAME are concerned. It's far from meaning all the calls to this FM. Hopefully, there is no reason to call this FM anymore since 6.10 as the field catalog is automatically calculated with CL_SALV_TABLE.
As a JAVA and ABAP programmer, my answer remains at - about 100 chars. Beyond that and it can interfere with readability.
The real question here should be why are you using FM K_KKB_FIELDCAT_MERGE?
Yes, I agree!
And the answer is: I'm not using it at all, but SAP is! (in RM07IMAT = MI22).
OMG (They killed the ABAP report. You bastards).
Doesn't note 2260803 - "MI22: Runtime error READ_REPORT_LINE_TOO_LONG" fix this issue?
And it it seems you're a little too overwhelmed. I have seen much worse SAP-standard ABAP code in my life 🙂
With that note, they “fix” it as in braking their lines down to < 72 c:
[SAP ONE Launchpad showing ABAP Correction of note 2260803]
SAP ONE Launchpad showing ABAP Correction of note 2260803
They don’t fix it as in: not using FM K_KKB_FIELDCAT_MERGE anymore (or better yet, giving a few more characters to DDIC RSSOURCE / EDPLINE ).
True, there is lots of bad SAP code.
Usually I don’t care that much – I’m ranting more when it hurts me in my work ;-p
Image for above post;
Sorry that I comment-spam my own blog! 😉
There's another one I hit with a SUBMIT from a BADI. But I forget the details.
Only now I see a spelling mistake (cant fix it, as I lost control over that user...), an "A" is missing:
Thats how it should read:
“Order Creation” is V45 (SAPMV45A), “Delivery Creation” is V50 (SAPMV50A).