Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
hardyp180
Active Contributor
I read a book on Clean ABAP

That makes me such a Jolly Jack

I can tell that Trouble’s Brewing

Come on Monsters – START REVIEWING!

This blog is a sequel, as it were, of an ongoing book review of I am doing of a new SAP Press book all about “clean” ABAP code. The first two parts of this book review can be found at

https://blogs.sap.com/2021/01/10/clean-abap-book-review-part-01/

https://blogs.sap.com/2021/02/03/clean-abap-book-review-part-two-dirty-gertie-from-number-thirty/

Two down, two to go. In the first two I made references to various light entertainment shows that were shown in the UK in the late seventies and early eighties, references that made no sense at all unless you (a) live in the UK and (b) are above a certain age. Thus far we have looked at the Two Ronnie’s and Basil Brush. OK let us look at what was on TV on Saturday 10th November 1977. I was nine at the time.


TV Guide Saturday 10 November 1977


We have covered Basil Brush (5:40) already, and I already have billions of “Doctor Who” references in all the blogs I have ever written. At 6:10 the Dr. Who episode mentioned above is “The Image of the Fendahl” which was a good old horror story about a killer skull served by giant killer worms, all enabled by devil worshippers and a “Time Scanner”. None of that is relevant to writing Clean ABAP Code however so let us move on to 6:35 and “The Generation Game” hosted by Bruce Forsyth.


Generation Game Intro


Nice to See You – To See You Nice

Good Game! Good Game!

That was a game show by the way. Bruce Forsyth is mainly famous for having loads of different catchphrases. Please look at the conveyor belt – various ABAP keywords will scroll by. Afterwards only the ones you can remember are you allowed to use.

Anyway moving along to Clean Code in the Stephen King novel “IT” (which is about a Killer Clown as opposed to Information Technology) there is a school bully who, along with his two sidekicks, tries to make life hell for the “Losers Gang” who are the key characters.  Some years after they have all left school the bully sees one of their names in the paper and has an epiphany and it goes something like this:

“Bowers suddenly grasped that with each passing year all his former victims were somehow getting better whilst he himself was just getting older”.

Just this very day I was trying to explain to someone in Germany how to use something I had written in 2009. I looked at the code I had written then, and it was terrible. Loads of static methods, EXPORTING instead of RETURNING parameters and basically if I did it again starting today there would not be one line of code the same. Hopefully that’s a good sign – if I looked at something I had written ten years ago and thought it was fantastic then that is a sign I have been stagnating for ten years.

One theme that comes up again and again throughout this book is that clean coding and test driven development go together like rama lama lama ka dinga da dinga dong, shoo-bop sha wadda wadda yippity boom de boom, chang chang changitty chang sha-bop, dip da-dip da-dip doo-wop da doo-bee doo, boogedy boogedy boogedy boogedy. You have probably been thinking the same thing yourself, in those exact words. Do you know when I tried to put that in “ABAP to the Future” it got edited out for some reason?

Chapter 6 (continued)

  • Regular expressions are “not ideal” as they cannot be understood, and the performance is not very good, and you never know when they are going to throw an exception.

  • The following check is described as “simple and understandable”

  • DATA(IS_VALID) = XSDBOOL( MATCHES ( VAL = CLASS_NAME REGEX = ‘[A-Z] [A-Z0-9_/]{0,29}’ ) ).

  • I hate to think what a regular expression check that is not “simple and understandable” looks like.


Chapter 7 – Internal Tables

  • DEFAULT/EMPTY key – this is explained which is just as well as most people have no idea what these mean. They get added just to suppress syntax errors i.e. some of the new functional statements in ABAP do not work on an internal just defined as STANDARD TABLE OF X. As I recall a RETURNING parameter complains if you type it as a “generic” standard table. So people add WITH DEFAULT KEY at the end of the definition, and the syntax error goes away, but a bunch of unknown side effects can crop up.

  • There is not much in the internal table chapter that has not been around for ages. Having said that SORTED and HASHED tables have been around since about the year 2000 and some programmers still never use them.


Chapter 8 – Clancy of the Control Flow

  • As you probably know there are a bunch of automated code inspector checks (often known as ATC checks) you can download from GitHub and install in your development system to look for some of the problems highlighted in the “Clean Code” ABAP style guide.

  • https://github.com/SAP/code-pal-for-abap

  • That is constantly evolving (one new release a week at the moment) but there are just some things it is impossible to code a static check for, because the code needs to be analysed by a human to see if the rule has been broken, or if the rule is silly in a given situation.

  • There are some cases though where if a construct is considered to always be bad, and always need changing then an ATC check can be developed. In this chapter the contention is that a loop that starts with DO 1 TIMES is always bad and was only ever there because “new” features (like OO code) were not available at the time. I just created such a custom ATC check in my development system, and it took about ten minutes, if that. There is no reason not to encapsulate the code inside the DO 1 TIMES loop in its own method. As it stands the CHECK statements inside the DO 1 TIMES loop are in fact GOTO statements which make program flow hard to follow.

  • A discussion on IF statements is never going to be very exciting. I am reminded though of one of the best ever questions on the SCN forums which asked, in all seriousness, if ABAP had IF statements.

  • A recommendation is that if the clause in an IF statement crops up again and again all throughout the program then it should be encapsulated so if the rule changes you only have to change it in one place i.e. technical investment once again. For complex conditional logic this would be in its own method, for a single value or range of values I like to change them from hard coded values like “PSTYV = ‘Y063’” to instead using some sort of customising tables so you get PSTYV = NASTY_MONSTER, or even better ITEM_CATEGORY = NASTY_MONSTER.

  • Just last week an analyst told me she wanted to change the PSTYV value for a standard order item for Hong Kong only. I told her just add a new entry to the customising table for PSTYV / STANDARD_ORDER with the LAND1 set as HK and the new value, and all the ten thousand places in the custom programs where this is evaluated would all magically use the new value, but non Hong Kong countries would be unaffected. That is better than adding a new IF branch to the ten thousand places, and forgetting half of them, and then having to change them all back (and forgetting half of the ones you changed) if the new value doesn’t work out.

  • Apropos CHECK statements I used to love peppering my code with them, but I have reluctantly moved to only putting them at the start of a routine. A big thig is made about a CHECK statement not returning any information to the caller in the event it fails, and I have concluded that at the start of the routine you use a CHECK statement for things that quiet probably will fail e.g. you are in a sales order application and want to do a date based derivation but the user has not entered the date yet. That’s fair enough and expected – the user can enter the order data in any sequence as long as they fill on the mandatory fields. However something that is unexpected like the user entering the year 5000 as the planned delivery date should raise some sort of exception. That is a failed CHECK statement is nobodies’ “fault” but a failed precondition means the caller is passing in bogus data that the routine at hand cannot handle and so the caller is at “fault” and needs to deal with the problem.

  • There is a horrible, horrible, example of a COND statement with a WHEN / THEN / LET structure inside it plus inline declarations and it looks like nothing on Earth. It appears to be being shown as a “good” example, but I think it is more of an example of the “new” syntax making a program incomprehensible.

  • We are back to unit tests and clean code being two sides of the time coin – this time if you find you have to right half a hundred tests to get the test coverage up to 100% for one method that is a sign there are just so many branches and conditional logic that it needs to be decomposed somewhat into smaller methods called within one branch, which improves the design because it makes the code easier for a reader to understand as well as easier for the developer to test.

  • The ATC static check complains if the nesting depth is over 5. Robert Martin says it should only ever be one, this book notes that when it goes over three you start to have a geometric progression of possible situations. Also wrapping a piece of conditional logic in its own method can be viewed as a form of documentation, especially if it is tested.

  • Another highlighted benefit of “deconstruction” is that it makes debugging easier, as an IF statement with twenty conditions is executed as a single statement and in the debugger you can’t be sure which one has failed without clicking on every variable. A lot of the “new” syntax has the opposite effect to deconstruction i.e. it makes debugging far more difficult.

  • On a philosophical level if a calculation is in the same method as the conditional logic then the method has more than one reason to change i.e. it has to change when the calculation changes and it has to change when the conditional logic changes. Having more than one reason to change is a Bad Thing. Usually you can tell if your method is doing too much when someone asks you “what does this routine do?” and your answer has the word AND in it. It is a bit more difficult to frame the “what would cause that routine to have be changed” question but in this case any answer with the word OR in it is a big clue.

  • I came across this the other day and think it is an anti-pattern as I work directly opposite to the way the human brain works - IF 'ZQC;ZQT;ZQV' CS ls_vbak-auart.



Conveyor Belt


What do points make? PRIZES!

Cuddly Toy! Cuddly Toy!

Give us a Twirl!

Didn’t he do well?

Chapter 9 – Comments

  • In SAP Press books each chapter always starts with a paragraph in italics giving a quick introduction to what the chapter is all about. I use quotations myself in my book. In this case I read the introduction paragraph three times and could still not see what it had to do with comments. I wrote a big question mark next to it and left it at that.

  • I have found that if I have a problem and solve it by doing something really odd in the code and do not leave a comment saying WHY I did that strange thing sooner or later someone will come across it, presume it is an error, and “fix” the problem.

  • One day the XYZ stopped working in production all of a sudden. After an hours debugging I encountered some Z code containing the comment “If you are here the XYZ has suddenly stopped working. This is because the ABC configuration has changed and what you need to do to the code is such and such”. That comment had been written by me ten years earlier. That was the best comment ever, a time capsule method to my future self.

  • Going back to unit tests once again, the book notes that rather than a “War and Peace” explanation at the start of the program of everything that program is supposed to do, the unit tests should be conveying that information – and unlike a comment they can never go out of date, because they break if they do.

  • Another very true statement is that big blocks of text before the code begins are rarely read – this is because developers, or indeed anyone in IT, don’t read documentation, they just steam right in and try and work it out themselves.. This is why the houses of IT people are full of odd-looking IKEA furniture with things sticking out at strange angles.

  • When I first starting working with really old programs and trying to understand what the program was doing I would add a comment at the end of IF branches to describe the nature of the IF/ENDIF construct. This was usually because the IF was five hundred lines up from the ENDIF, and moreover there were six ENDIF statements in a row. This is treating the symptom rather than the cause, but I say it is OK – as a first step – so long as you then decompose the routine so the If/ENDIF becomes short enough you can see both on the one page and so do not have to guess any more. The little boxes in the ABAP editor where you can expand and contract IF statements serve the same purpose. The routine should be so short you should never need to use them.

  • Another bad thing I do is to put a comment in a “box” (with a line of *-------------- above and below it) whenever the routine starts doing something totally different, thus breaking the routine into sections. You can use the “region” functionality in the ABAP editor to do the same thing. Again really this is a clue I should be moving the next “section” into its’ own routine. However once again I say commenting the code into sections is OK – as a first step. You need to understand the code before you start messing with it.

  • The advice is do not add a comment above MESSAGE e093 saying what the error message is, because the error message definition can change, and the comment would not. The downside is you do not know what the message is until you navigate into it. In reality messages very rarely change but I see the point. I am waiting for some magic to happen in Eclipse where the text of the message appears as a “ghost” comment above the error message i.e. the comment looks like it is there, but it is dynamically generated. This already happens in Eclipse with error messages if you switch “code mining” on. The error message appears in the line before the statement in error appearing to look like a comment, but it vanishes once you fix the error.

  • There is a mention of FIXME / TODO / XXX comments to indicate some code needs writing/fixing. I would add that there was a great blog on SCN once saying write these as pragmas e.g. ##TODO. That way every time you do a syntax check they will pop up (as unknown pragmas) to remind you what needs doing. Eventually you will get so sick of this you will either write/change the code or decide it’s never going to happen and remove the fake pragma.

  • When it comes to “ABAP Doc” I have always been very dubious as I cannot see many programmers writing documentation unless they are forced to, kicking and screaming. The recommendation is to only do this for external things – which would mean global interfaces. If you were going to document the methods and parameters you could do this directly in the form-based editor in SE24, so I suppose ABAP Doc is aimed at development in ABAP in Eclipse. Even then it would be easier to go back into the SAP GUI and write the documentation in SE24 as that way you don’t have to remember to add all the funny symbols at the start of each line.

  • One thing I would not about pragmas which is not pointed out is that if you use a Pseudo-comment after a statement then you cannot have a real comment as well. A pragma goes before the period so you can have more than one pragma (you can only have one pseudo comment I think) and after the period you can have a real comment e.g. DATA SOMETHING ##NEEDED.”As it is accessed dynamically



Big Night Out


You’ll never compete with Bruce Forsyth on a Saturday evening because… He’s really chummy! Isn’t he really chummy?! Really, isn’t he?! I’n’ ‘e nice! I’n’ ‘e!! Come on, enjoy yourself! (laughing) Come on, Dudley, ha-a-a-a-a!!

Got Dudley on the show, let’s have a tune (random plonking on piano) Ah-ha-ha-ha!! Have a tune, come on!! Ha ha!! Have a tune!! Ha ha ha ha ha ha ha ha!!

Never mind! Anthea! Anthea!! Hello, love! Anthea, come over here, will you, ye-hes!!

(sings and plonks piano:) #Oh, I can’t sing and I can’t dance ‘n’ anything else as well!

Ah ha-ha ha ha-ha!

Never mind, let’s have some not very nice person from the audience – Hello! Not very nice person-from-the-audience, here, come in, make a fool of yourself.

(plonks piano:) #Deh de-deh-deh…

Chapter 10 – Formatting

  • You might think this chapter would read “Use the Pretty Printer. The End” In fact this chapter is far more general and deals with the myriad decisions you can make which would render your code confusing or unintelligible. The problem is that no two people would agree on what makes code readable or not.

  • I am lucky in that a fair few of the programmers where I work have been there twenty years just like me, so if I find something really confusing I can go up to them and ask them what in the world is this nonsense, and they can do the same back to me. Most people do not have that luxury though, often a consultant is told to get something working as fast as possible, so they write some cryptic spaghetti monster code that works and then roll off the project never to be seen again.

  • What I do at work is that when I find something that has a low-level bug or cannot be understood by man nor beast I sent it to all the programmers with a “What’s wrong with this?” subject line on the email. I have got my colleagues doing this as well now.


For example today this one came through:

AUTHORITY CHECK “XYZ”

IF SY-SUBRC = 0.

RF_AUTHORIZED = ABAP_TRUE.

ELSE.

RF_AUTHORIZED = ABAP_FALSE.

ENDIF.

RF_AUTHORIZED = ABAP_TRUE.

My colleague had presumed the last line was just there for testing and someone had forgotten to delete it before moving it to the test system. But no, it was deliberate – the idea was to pretend everybody was authorized “temporarily”.  I gleefully dug up a program that had been in use a long time and pointed out that at sixteen different places in the code was the comment “the below logic is only for the interim period”. How long has this “interim period” been going on? Ten years and counting.

  • In any event some people like upper case keywords, some like everything lower case and as one program can get worked on by different programs it seems unfair to the poor old program for the keywords to be uppercase one week, lower case the next and then back to uppercase the week after that. So about ten years ago we had a vote and upper-case keywords narrowly won. I recall one of the programmers saying he was not happy because now his keywords would be shouting at him, but he would accept the will of the majority. Everyone nodded solemnly, then went back to their desks and continued using whatever setting they had before, and to this day the keywords go up and down like a Mexican wave. That does not show up on the version management by the way, although many people think it does.

  • I’ve got my ABAP editor set up so there is a line down the right-hand side to tell me when a line of code is too long. For the life of me I cannot remember how I set that up. It doesn’t seem to be in the user specific editor settings, nor in the GUI options. The book tells you how to do this in Eclipse as well, that is a programming language independent setting which is a good thing about Eclipse i.e. improvements come which have nothing to do with ABAP per se, yet you still get the benefit.

  • Often in this book I will read something and think to myself “I had better start doing that”. For example often I will leave a blank line between a READ statement on an internal table and the line that evaluates SY-SUBRC. The recommendation is not to leave such a blank line because the two statements are tightly bound to each other. They are, according to Robert Martin “Vertically Dense”. Dense Fog? No, no, Dennis A blank line indicates the code is moving on to do something different.

  • I once read a blog trying to explain functional programming to ABAP programmers and apart from the “strange” concepts like not changing any variables once you have assigned them a value, and passing functions as parameters (it took me a very long time to get my head around that one) there was also some sort of psychological aspect to the syntax, it was supposed to magically draw the eye of the reader to the important bit of the statement. I never really got that bit.

  • In the same Robert Martin explicitly argues against lining anything up e.g. putting all the TYPE statements under each other in a data declaration block, or all the equals signs under one another in a block of assignment statements. This I supposed to be and because it “draws your attention away” and “obscures the intent of the code”. I am not convinced. To me it just looks neater and I cannot see why it is harder to understand.

  • Furthermore a little while later the book warns against “ragged” alignment of parameters in method calls. This time NOT lining them up is distracting. Because they are closely aligned. Well I say so can variable declarations and assignments be. Often they are not, but they can be. Anyway you can’t have it both ways, either lining things up is distracting or it is not, and I say it is not, and some people say it is.

  • A good recommendation is that if a method call has just a single parameter then do not put that parameter on its own line underneath the method call. Unfortunately the automatic code completion does just that.

  • Brackets are a huge source of emotion – you would not think an argument about the usage of brackets could lead to cold blooded murder, but it often does. As an example the book recommends not having the closing bracket on its own line and there is even an ABAP open check showing this as an error. I would tend to agree but it is a bit of a value judgement – after all having the closing bracket on its own line is exactly what you do in JavaScript. More ominously there is a programmer who always writes code like IF ( ( SOMETHING = 3 ) AND ( SOMETHING_ELSE = 4 ) ) or IF ( SOMETHING = ABAP_FALSE) THEN and if you tell him there are too many brackets he will tear out your heart with his bare hands and eat it in front of you and then rip your head off and kick it over the top of the goalposts thus scoring a conversion, and then throw the rest of your body on the bonfire and ignite the fire using a copy of “Clean Code” as tinder.

  • The chapter ends by recapping all the rules and referring to them as “best practices”. They might be but because of all these years working with SAP I imagine no-one can rake the term “best practice” seriously because of the way SAP has traditionally defined it.


Dictionary Definition:

plural noun: best practices

commercial or professional procedures that are accepted or prescribed as being correct or most effective.

Example : "the proprietors are keen to ensure best practice in food preparation, storage, and serving"

SAP Definition:

plural noun: best practices

A procedure that matches the way that SAP software was written, regardless of how well or not that fits your particular business. The computer tells YOU what to do, not the other way around with all that company specific configuration nonsense. You can’t run your business properly but it makes upgrades so much easier!

Example: For years a purchase order with multiple account assignment did not post to the profit and loss account until invoice receipt, whereas a PO with single account assignment posted to the P&L at GR time. That was “best practice” for years as SAP could not technically get the software working any other way, but in some sense for the company following that “best practice” that could be described as false accounting. Anyway after many years they fixed the bug, so now “best practice” has been updated to reflect the new (corrected) way the software behaves.


Play Your Cards Right


I’m the leader of the pack - which makes me such a lucky jack. And here they are, they’re so appealing, OK dollies - do your dealing!

It could still be a Big Night – If You Play Your Cards Right, Goodnight!

You don’t get anything for a pair – NOT IN THIS GAME!

Brucie Bonus!

What a lovely audience – so much better than last weeks!

The joke being that the same audience was used for multiple recordings.

Chapter 11 – Exceptions

  • I had never really thought about it but it gets pointed out that in some ways function modules are the opposite of “clean” in that many of them do a lot more than one thing, this is especially true of function groups with dozens of function module inside them, and why many BAPIs have such a ridiculously big signature. The recommendation is to create many methods to wrap such function modules and each method would expose one specific task the function module is capable of, with a simplified signature and proper error handling (i.e. exception classes rather than exceptions which set SY-SUBRC)

  • Another bad thing about the exceptions raised by function module is that you can add new ones at the end (or even in the middle) and every single program that calls that function module needs to be adjusted. I have seen this (new exceptions springing into being) happen at upgrade or support stack time with standard SAP function modules. I think this is one reason why very few standard SAP function modules are “released” – it gives them carte blanche to add new exceptions and change the signature and the customer cannot say boo as we were never supposed to be using that function in the first place.

  • The other funny thing I have noticed is that if a function module has more than 10 exceptions the ATC check asks you to replace the numbers greater than 10 with a constant!

  • I noted the comment “class-based exceptions are more common today” and in the margin I had scribbled “I wish!” . That just is not true in my experience. I was always really puzzled why SAP allowed “classic” exceptions in methods in the first place and even more puzzled that in SE24 the little box which says “class-based exceptions” is off by default.

  • Another statement – “the usage of classic exceptions in methods is uncommon”. Sadly that is not the case. I think round about 2000 the developers at SAP were paid a bonus based on how much code they code “convert” to OO, so they wrapped a load of function modules in static classes that just passed the function module “classic” exceptions into “classic” exceptions in the method. There are a whole bunch of GUI type classes/methods like that for file dialogs and the control framework and so on. Even worse lots of “customer” developers saw this and presumed that was how you did OO and so created lots of similar classes and methods all with classical exceptions.

  • One thing I did not understand in the book was when it talked about using enumeration classes when using the MESSAGE statement. I understand that the name of a constant makes it really obvious what the message is all about as opposed to 987(V1) or something, but it is claimed you can use constants and still have the where-used list identify all the places in the system where that message is raised. I just cannot see how that could work. The message that pops up to the end user would still say “978” or whatever and that is usually the starting point for the “where-used” search. If anyone can explain this (using enumeration class and still having the where-used search work) to me I would be grateful. Does the “where-used” see the value of the constant in the code it scans as opposed to the name?

  • One thing worth noting, because it is not as well-known as you would imagine, is that adding the predefined ERROR_MESSAGE classical exception to a functional module suppresses any such messages actually being shown in the GUI and just raises the exception whilst filling the SYST variables with the error details. This could be useful for a unit test for example. At one stage in life I was merrily adding the ERROR_MESSAGE addition to every function module I called, until I realised it totally stuffed up ALV processing i.e. function REUSE_ALV_GRID. There you want to show the user error messages.

  • Earlier in the book an “S” message was described as a “system message”. Here it becomes a “status message” also known as a “success message”. The latter was the way I have always thought of it, the little message at the bottom of the screen saying that you have just created sales order number 12345678.

  • With messages a suggestion is made to try and group them logically e.g. 100 to 200 for header messages, 400 to 500 for item messages or some. I like that idea but how many people really do this? Most people just add any new message by pressing the “next free number” button.

  • It is interesting that when playing with the IF_T100_MESSAGE interface in an exception class to add existing messages to an exception class the “form based” procedure in the SAP GUI using SE24 is so much easier than the equivalent in ADT which seems very clunky indeed.

  • Here is an interesting claim in the book: “It does not make sense to raise an exception and then catch it in the same method”. Really? What if you are doing some sort of dynamic SQL call which raises a catchable exception? Or the ever-popular divide by zero? Should the logic be in one method and the exception be caught in another?

  • A lot of people get confused by the interfaces in exception classes. This is because you can have your own exceptions where you build the “message” yourself, or re-use existing T100 messages, or convert the SYST structure dynamically using the IF_T100_DYN_MSG and thus convert any sort of system message e.g. the ones raised by function modules. Whilst I am here the claim is made that the SYST structure has five fields that contain the message details. I would say seven myself.

  • In the discussion of CX_NO_CHECK exceptions the book suggests using such exceptions will result in a short dump most of the time. I hope not, as this is the only type of exception class I use, and all my programs crawl with them. Thankfully my programs do not short dump constantly, I think the end users would tell me if they did.

  • The claim is that a RESUMABLE exception only works properly with a CX_NO_CHECK exception. I never knew that. I will need to do some tests to verify this.

  • Whenever I see a phrase like “SAP NetWeaver AS for ABAP 7.78/7.55 or higher” I have a giggle to myself. That is because for every release of ABAP there are three different numbers which all means the same thing – in this case 7.78 and 7.55 are equivalent, and there would also be a name like 19/02 which also indicates the same release. In SAP presentations the numbers are used interchangeably at random, often from slide to slide e.g. it is 7.55 at the start of the presentation and then 19/02 later on. Even for SAP that is the ultimate in renaming the same product, in such a presentation the product name can change three times in three minutes. If anyone can direct me to some sort of matrix where there is a mapping between all these numbers that would be great.

  • Going back to exceptions from ABAP 7.55 you can declare a CX_NO_CHECK exception in the signature of a method. This has no effect at all on the code, it is information only, sort of like putting up a “beware of the dog” sign so any callers are aware that such an exception can be raised but they do not need to handle it if they don’t feel they are able to do anything about it. This makes perfect sense to me – if no routine is able to deal with the problem then a dump is exactly what should happen, but in 99% of cases a high-level routine will be able to deal with the problem, if only by asking the end user.

  • Another thing which made me laugh was “dynamically typed exceptions are seldom used”. I am not laughing because the statement is incorrect, I struggle to find any possible use case for such an exception type. I laugh because when exception classes first came out I clearly recall the SAP documentation said, “these are the types of exceptions you will use most of all”.

  • The recommendation is not to use RAISE EXCEPTION TYPE but rather RAISE EXCEPTION NEW. Presumably that is to avoid having to use the word EXPORT before filling any parameters. However that syntax only works in ABAP 7.52 and up i.e. S/4HANA.

  • One good tip was when catching one exception class and immediately propagating the exception using a different exception class you have to remember to fill the PREVIOUS parameter of the new exception with the original exception. It is tempting to think that happens automatically by magic but clearly it does not.

  • I think I mentioned earlier about error handling code growing like a magic beanstalk and getting so big it obscures all the real code. One way around this is that if there is going to be more than one statement in a catch block to decompose this into its own method. Also bear in mind that error handling code grows and mutates ten times faster than normal code so if there is only one statement now before you know it there will be fifteen.

  • The recommendation is to try to avoid the CLEANUP construct (I have never used it) as it confuses the reader and forces the method to do more than one thing. The irony is that this means the use of CLEANUP is not “clean”.

  • Going back to unit testing the chapter ends by noting that error handling is usually an afterthought, but not if you do TDD. I find you will always need a positive and negative test before you can be sure most pieces of code work.



Slingers Day


“Slingers Day” has to be one of the worst sitcoms every written and that is a field crammed full of contenders for that prize. Anyway it was about a supermarket manager and because Bruce Forsyth was a game show host as opposed to an actor he addressed the “jokes” directly to the camera as opposed to looking at whatever actor he was supposed to be delivering the punchline to, and then laughed to the camera to try and prove the joke was funny even though it clearly was not. The characters in sitcoms are not supposed to laugh at the jokes which is why in the sitcom “On the Buses” I found it amusing that the actor playing the villain spent 100% of the time desperately trying not to laugh and not quite succeeding. In fact I found that funnier than the actual jokes.

Conclusion

Hopefully by now you will be itching to rush out and buy the Clean ABAP book for yourself, if only so you can use it to disprove some of the ridiculous opinions I have expressed in this blog.

On March 17th I have my latest ABAP book coming out, so the authors of the Clean Code book can have their revenge and rip mine to pieces, either literally or figuratively in a book review blog such as this one.

Anyway, that’s it for now - one more Clean Code review blog to go!

Remember – it could still be a Big Night – if you Play Your Cards Right!

Goodnight!

Paul

https://www.sap-press.com/clean-abap_5190/
1 Comment