Penny Lane, there is a fireman with an hourglass
And in his pocket is a portrait of the Queen
He likes to keep his fire engine program clean
It's a clean ABAP machine – with apologies to the Beatles.
Here I am, sitting in a huge chair, ready to do a book review on the following SAP Press book:
https://www.sap-press.com/clean-abap_5190/
As a disclaimer I was given a free copy by SAP Press to review, in return for writing one or more book review blogs. It will in fact be several. I am definitely not going to write this blog in the rambling style of the late UK comedian Ronnie Corbett, going off on all sorts of tangents and shouting “My Producer! My Producer!” all the time. Anyway it wasn’t my producer who gave me a copy of the book - it was SAP Press.
I was first informed of the existence of the “Clean ABAP” open source GitHub “style guide” by Lars Hvam Petersen (inventor of abapGit) the day before SAP Inside Track Copenhagen 2019 whilst we were all out drinking at the “speakers’ dinner” the night before the event. Here we are at a brewery in Copenhagen:
In any event he directed me to the repository
https://github.com/SAP/styleguides/blob/master/clean-abap/CleanABAP.md
and told me he agreed with most of it (no-one is ever going to agree with all of it). I was over the moon; the very existence of this project was the best news I had in a long time. For so long people has been ignoring Robert Martin’s “Clean Code” because the examples were all in Java or what not, but now there was no excuse.
Have a look at part of my bookcase:
You will notice both “Clean Code” and “The Clean Coder”. The first is all about the code, the second is all about the person (you) who writes the code. I keep the “Enterprise SOA” book there as a joke. That came out in 2006 and was all about a glorious future that never happened. It was the SAP equivalent of books that predicted by the year 2000 we would all be driving flying cars and living off food pills.
After a series of crimes in the Glasgow area, Chief Inspector McTavish has announced that he’s looking for a man with one eye. If he doesn’t find him, he’s going to use both eyes © R.Corbett.
A short while after the ABAP Clean Code GitHub project was first created a series of automated code inspector checks were also released to enable static checks on some of the “smells” identified by the clean code guidelines.
https://github.com/SAP/code-pal-for-abap
I was happy about this as well, I downloaded it the first day and merrily submitted bug reports till the cows came home. As it turns out I ended up switching off half the checks because I don’t agree with them, and nor does my producer, but that is neither here nor there, the point is that those checks are available.
Next cab off the rank was an SAP Press book based upon the online style guide, which actually looks it was written before the “Code Pal” existed, which doesn’t surprise me, you can’t write a 340-page long SAP book in ten minutes. The obvious question is – if all the guidelines are available for free on the internet then why buy a book containing the exact same information? Well, let us see.
The main point is that generally anything online has to be as terse as possible. This is because – rightly or wrongly – it is assumed that people’s attention span in the present day has reduced to two or three seconds and anything that takes longer than that to consume will not be bothered with. That is why the videos on TikTok are only one second long and Twitter posts can only be a few words long e.g. “Storm Capitol Now!” or “I’ve been banned!”
Conversely I write at length. People always ask why my blogs on SCN are so long and it is because I am over 50, from a time when reading books the length of “The Lord of the Rings” was a normal thing to do, and when that came out in 1954 people complained to J.R.R. Tolkien it was not long enough.
Fun Fact – when the second “Lord of the Rings” film came out, naturally named “The Two Towers” after the second book in the trilogy, lots of people claimed it was a disrespectful title due to the bombing of the world trade centre. This despite the book “The Two Towers” being published in 1954 and construction on the world trade centre not starting until 1966.
Anyway, going back to attention span, in a book there are not the constraints that everything has to be as short as possible and therefore each concept can be covered in a lot more depth.
At this point my producer would like me to stress that the whole point of this clean code business is to increase the velocity of change – if code is “clean” then you can understand it, therefore you can change it faster, and more importantly if the code is wrong it looks wrong so errors are far more obvious, and so there will be less errors, so less time spent debugging when you could be doing something more value adding like drinking beer.
First off I would say that it is obvious right from the start this is a wonderful book and a pleasure to read. So go out and buy it, and read it, and then buy the real “Clean Code” and “The Clean Coder” and read them as well. You’ll be glad you did.
The rest of this blog, and the ones that follow are me rambling on at random, and nit-picking at tiny bits of the book I disagree with, but before I start on that exercise two important matters need to be raised.
Firstly, and most importantly on page 27 of the clean ABAP book the term PARADIGM SHIFT is mentioned; so it is time for a Mexican wave.
The second point is that often such “Clean Code” initiatives get killed off before they start due to no two developers ever agreeing on anything – you may disagree with that – so that any attempt to enforce a set of rules is futile.
I won’t argue that no-one agrees on anything ever, you get fist fights on the alignment of SELECT statements, or the use of ABAP_TRUE, but the point is at least you are talking about the concept of clean code with your team, most of whom would have never heard of such a whacky idea. The clean ABAP book quite rightly mentions that the exercise of getting the team to agree on a set of rules – or even the idea that any rules are needed in the first place – is 99% of the effort involved in “cleaning up” your code base.
My producer says that what will need to happen is that you lock all your ABAP developers in a cage in the middle of a large open space and issue them all with several bottles of vodka and an assortment of deadly weapons like axes and morning stars (A morning star is any of several medieval club-like weapons consisting of a shaft with an attached ball adorned with one or more spikes) and a copy of “Clean ABAP” each. Tell them they can come out when they have all unanimously agreed on a set of clean code rules they have all sworn to obey from this point on. After a short while the conversation will start to centre on vital points like whether to use the CHECK statement inside LOOPS, at which stage all hell will break lose.
You can sell tickets to the event so that the accounts and sales departments and so on can pay to watch the fight. This will make a fortune for the company, and thus prove to management that focusing on code quality is not a waste of money after all. Admittedly the downside is that all the programmers will be dead at the end of the process.
I would note that the actual clean ABAP book does not recommend this approach for some strange reason.
Let the Nit-Picking / Random Musing Commence
It sometimes seems like the book is aimed primarily at internal SAP staff i.e. “if you have a @Sap.COM email address then…”, and it describes things that are only available if you work for SAP e.g. transaction CHECKMAN. That is interesting on a sort of intellectual level, but very abstract for 99.9999% of the people who buy the book. However maybe SAP employees are the target audience, given that lots of new developers look at standard SAP code, presume it must be good, and copy the techniques they see being used.
Urban Myths
There is a phrase in programming, as in life, called “Show Don’t Tell”. As in - it is OK to tell someone to do something and then (hopefully) tell them the fact that underlies that advice, but it is a billion times better to prove to them that fact is true and let them draw their own conclusions. For example I could show someone a short dump in production caused by an empty FOR ALL ENTRIES table or not checking SY-SUBRC after a FIELD-SYMBOL assignment or whatever, and then run the code inspector right in front of them on that code and point out that the static code check highlights the errors that are causing the short dumps in production. Hopefully the lesson to be learnt is that if the original programmer had run the code inspector and took note of what it was saying those dumps would never have happened. The more important lesson is that the extended syntax check and code inspector are not some sort of joke or red tape for the sake of it, they can actually prevent problems, problems for you personally, because the IT department does not have to deal with angry users, and you do not have to waste your time debugging and then fixing your code.
The famous IT quite is “always assume the end users are eight-foot-tall psychopaths who know where you live”. If you take that attitude ten running static code checks suddenly becomes a lot more important.
The B side of that is not to take anything for granted. This is stressed in the clean book – don’t do anything just because the rule says so, find a way to prove if that rule makes sense or not. One example I would give is the urban myth at INTO CORRESPONDING FIELDS OF causes a huge performance problem, when it is so easy to do ST05 traces proving it makes either no difference at all or an incredibly small difference. Put another way in life you often have to follow rules that make no sense, at work or wherever, but for your development team you can throw a rule out of the window if you can prove it makes no sense whatsoever. In fact it is the other way around – rather than obscure rules being imposed on you for no logical reason due to management whims you can only add a code rule if it 100% makes sense to everybody with cast-iron proof to back up that reason e.g. dumps in production.
One of these things is not like the other
Object Oriented programming was introduced to the ABAP language at the tail end of 1999 with ABAP version 4.6. There was even a very cut down version of OO in the 4.5 language, and SAP Business Workflow has used OO terms since its inception.
However even after over 20 years the vast bulk of new ABAP code being written every day is in a procedural manner, or maybe even without procedures in one huge string of statements after START-OF-SELECTION. You would think if this was ever going to change it would have changed by now. This is why when I see a blog saying, “in ten minutes time every ABAP programmer will base their programs on CDS Views” I think to myself “good luck with that one”, and conversely when I saw a blog last year titled “having a hard time getting my head around anything OO” I was not surprised in the slightest.
I can only presume it is this prevalent “we have always done it this way” attitude amongst ABAP programmers that makes the authors of the clean book say “we’re no object orientation evangelists” as if some programmers started reading the clean book and then thought that OO was being shoved down their throat they would hurl the book out of the window there and then, having set fire to it first.
I am an OO evangelist, but there is one point I would mention. There is a big difference between OO as a concept and the use of “design patterns” (which could be described as templates for solving common problems using OO code). Put another way it is entirely possible to write a play in English yet not use iambic pentameters for all the spoken lines like Shakespeare did. Put yet another way OO programming as a concept and design patterns are not one and the same.
The clean book makes a big deal out of not blindly using design patterns just for the sake of it. I think most programmers don’t actually know what Design Patterns are, and this book gives some good definitions. I would say some design patterns are actually built into the ABAP language e.g. the observer pattern with EVENTS, the proxy pattern with transaction SPROXY, and the prototype pattern through the kernel level CLONE function. In addition with Web Dynpro and UI5 you are mandated to use the MVC (Model-View-Controller) pattern.
Police announced tonight that they wish to interview a man wearing high heels and frilly knickers - but the chief constable said they must wear their normal uniforms © R.Corbett.
My producer says the clean book gets a big green tick for saying TEST-SEAMS are useless. It does not go as far as saying they are an abomination (which they area) but does say they are “fragile” which is a polite way of saying the same thing.
When Verbose Comes In
ABAP is what is called a “fourth generation” language. Originally programs were written on punch cards and/or in machine code and were very short indeed and you could not decipher what they did by looking at code which was a string of hexadecimal characters. ABAP is often attacked for going too far the other way and saying things like “ADD 1 to MONSTER_COUNT” as opposed to the “superior” MONSTER_COUNT += 1. I would say the former reads like English and the latter reads like machine code. There is nothing intuitive about += at all, you have to be taught what it means, whereas it would be most surprising if you could not guess what ADD 1 TO MONSTER_COUNT means.
The book notes that programmers from other languages when encountering ABAP might get quite surprised at the concept of having verbose code that tries to read like English. I would say that is a goal worth striving for, it is the sort of “literate programming” that Donald Knuth aimed for – to a human the code reads like an English description of what the program does, to the computer that code is compiled into machine code which the computer can understand, so everyone is happy. This is one of the reasons I like OO so much, there is just so much more scope for having your code read like English sentences.
A lot of the “new” ABAP syntax that came in with 7.40 concentrates on making the code a lot shorter. I am all for that, providing that clarity is not sacrificed, and if the resulting code is not understandable then I stick with the old way. For example I am not convinced that FOR/IN is clearer to understand than LOOP/ENDLOOP, even though I have been familiar with FOR/NEXT loops and the LET statement since 1981 as that was the way the BASIC language on the ZX81 worked. To be honest when I first encountered ABAP 16 years later I thought the ABAP equivalents were much more like English and thus was quite surprised when a quantum leap backwards came along.
Comrade Death
“Comrade Death” was a science fiction short story about an arms dealer written in 1944 (before there were any professional arms dealers). It must have been 40 years ago since I read the story, but I remember the end clearly:
“We have invented a poison gas that can eat through any substance in the world! But there is a problem”
“And that is?”
“We can’t find anything to store it in!”
Thus the gas escapes and kills the inventors including the hideous Dr.Krok and anyone nearby like the arms dealer and the way it works is your brain is damaged and you start walking around in circles until you die.
“How in the world does ABAP remind you of this?” asked my producer. It’s all to do with Hungarian Notation. First of all a huge push was made to get rid of prefixes such that LD_VBELN should now only be VBELN. All well and good, but then the new rule comes along that it is obsolete not to specify a variable in an SQL statement without a @ at the front as in VBELN = @VBELN. Why do you need the @ at the start? To indicate that it is a variable – you can’t tell otherwise because it has no prefix! So add a pseudo-prefix. At this point I feel that everyone is walking around in a circle led by the hideous Dr.Krok.
OO, OO There is no need to laugh
I have to say chapter 3 does quite a good introduction to OO concepts, saying why assorted OO constructs are good, not just that they are. Once again the authors realise most readers are die-hard procedural programmers.
There are a big bunch of OO design recommendations given which – as per everything in the book – not everyone will agree with but hopefully it will make everyone think twice just in case the recommendations make sense. For example you have the ever popular two rules (a) declare all public attributes in interfaces and (b) don’t have attributes in interfaces. It is somewhat difficult to square that circle.
Without going into details some recommendations make so much sense I hope no-one argues with them e.g. that static classes are not classes in any sense and so need to follow a totally different set of rules. In fact the more I read of chapter three the happier I become with the recommendations.
West London police wish to alert local residents about the activities of the infamous cross-eyed burglar. If you see this man staring in your windows, warn the people next door © R.Corbett
I have sat in one of the chairs in the SAP lobby above with a huge hangover many times, looking at that big brown stone. Anyway that’s neither here nor there, now is the time to break off, and for the conclusion.
Conclusion
Cheersy Cheers,
Paul
https://www.sap-press.com/clean-abap_5190/
And in his pocket is a portrait of the Queen
He likes to keep his fire engine program clean
It's a clean ABAP machine – with apologies to the Beatles.
Figure 1 - Lots of Stones
Here I am, sitting in a huge chair, ready to do a book review on the following SAP Press book:
https://www.sap-press.com/clean-abap_5190/
As a disclaimer I was given a free copy by SAP Press to review, in return for writing one or more book review blogs. It will in fact be several. I am definitely not going to write this blog in the rambling style of the late UK comedian Ronnie Corbett, going off on all sorts of tangents and shouting “My Producer! My Producer!” all the time. Anyway it wasn’t my producer who gave me a copy of the book - it was SAP Press.
I was first informed of the existence of the “Clean ABAP” open source GitHub “style guide” by Lars Hvam Petersen (inventor of abapGit) the day before SAP Inside Track Copenhagen 2019 whilst we were all out drinking at the “speakers’ dinner” the night before the event. Here we are at a brewery in Copenhagen:
Figure 2 - SIT Copenhagen 2019
In any event he directed me to the repository
https://github.com/SAP/styleguides/blob/master/clean-abap/CleanABAP.md
and told me he agreed with most of it (no-one is ever going to agree with all of it). I was over the moon; the very existence of this project was the best news I had in a long time. For so long people has been ignoring Robert Martin’s “Clean Code” because the examples were all in Java or what not, but now there was no excuse.
Have a look at part of my bookcase:
Figure 3 - Part of my Bookcase
You will notice both “Clean Code” and “The Clean Coder”. The first is all about the code, the second is all about the person (you) who writes the code. I keep the “Enterprise SOA” book there as a joke. That came out in 2006 and was all about a glorious future that never happened. It was the SAP equivalent of books that predicted by the year 2000 we would all be driving flying cars and living off food pills.
After a series of crimes in the Glasgow area, Chief Inspector McTavish has announced that he’s looking for a man with one eye. If he doesn’t find him, he’s going to use both eyes © R.Corbett.
A short while after the ABAP Clean Code GitHub project was first created a series of automated code inspector checks were also released to enable static checks on some of the “smells” identified by the clean code guidelines.
https://github.com/SAP/code-pal-for-abap
I was happy about this as well, I downloaded it the first day and merrily submitted bug reports till the cows came home. As it turns out I ended up switching off half the checks because I don’t agree with them, and nor does my producer, but that is neither here nor there, the point is that those checks are available.
Next cab off the rank was an SAP Press book based upon the online style guide, which actually looks it was written before the “Code Pal” existed, which doesn’t surprise me, you can’t write a 340-page long SAP book in ten minutes. The obvious question is – if all the guidelines are available for free on the internet then why buy a book containing the exact same information? Well, let us see.
The main point is that generally anything online has to be as terse as possible. This is because – rightly or wrongly – it is assumed that people’s attention span in the present day has reduced to two or three seconds and anything that takes longer than that to consume will not be bothered with. That is why the videos on TikTok are only one second long and Twitter posts can only be a few words long e.g. “Storm Capitol Now!” or “I’ve been banned!”
Conversely I write at length. People always ask why my blogs on SCN are so long and it is because I am over 50, from a time when reading books the length of “The Lord of the Rings” was a normal thing to do, and when that came out in 1954 people complained to J.R.R. Tolkien it was not long enough.
Fun Fact – when the second “Lord of the Rings” film came out, naturally named “The Two Towers” after the second book in the trilogy, lots of people claimed it was a disrespectful title due to the bombing of the world trade centre. This despite the book “The Two Towers” being published in 1954 and construction on the world trade centre not starting until 1966.
Anyway, going back to attention span, in a book there are not the constraints that everything has to be as short as possible and therefore each concept can be covered in a lot more depth.
At this point my producer would like me to stress that the whole point of this clean code business is to increase the velocity of change – if code is “clean” then you can understand it, therefore you can change it faster, and more importantly if the code is wrong it looks wrong so errors are far more obvious, and so there will be less errors, so less time spent debugging when you could be doing something more value adding like drinking beer.
First off I would say that it is obvious right from the start this is a wonderful book and a pleasure to read. So go out and buy it, and read it, and then buy the real “Clean Code” and “The Clean Coder” and read them as well. You’ll be glad you did.
The rest of this blog, and the ones that follow are me rambling on at random, and nit-picking at tiny bits of the book I disagree with, but before I start on that exercise two important matters need to be raised.
Firstly, and most importantly on page 27 of the clean ABAP book the term PARADIGM SHIFT is mentioned; so it is time for a Mexican wave.
Figure 5 - Mexican Wave
The second point is that often such “Clean Code” initiatives get killed off before they start due to no two developers ever agreeing on anything – you may disagree with that – so that any attempt to enforce a set of rules is futile.
I won’t argue that no-one agrees on anything ever, you get fist fights on the alignment of SELECT statements, or the use of ABAP_TRUE, but the point is at least you are talking about the concept of clean code with your team, most of whom would have never heard of such a whacky idea. The clean ABAP book quite rightly mentions that the exercise of getting the team to agree on a set of rules – or even the idea that any rules are needed in the first place – is 99% of the effort involved in “cleaning up” your code base.
My producer says that what will need to happen is that you lock all your ABAP developers in a cage in the middle of a large open space and issue them all with several bottles of vodka and an assortment of deadly weapons like axes and morning stars (A morning star is any of several medieval club-like weapons consisting of a shaft with an attached ball adorned with one or more spikes) and a copy of “Clean ABAP” each. Tell them they can come out when they have all unanimously agreed on a set of clean code rules they have all sworn to obey from this point on. After a short while the conversation will start to centre on vital points like whether to use the CHECK statement inside LOOPS, at which stage all hell will break lose.
You can sell tickets to the event so that the accounts and sales departments and so on can pay to watch the fight. This will make a fortune for the company, and thus prove to management that focusing on code quality is not a waste of money after all. Admittedly the downside is that all the programmers will be dead at the end of the process.
I would note that the actual clean ABAP book does not recommend this approach for some strange reason.
Let the Nit-Picking / Random Musing Commence
It sometimes seems like the book is aimed primarily at internal SAP staff i.e. “if you have a @Sap.COM email address then…”, and it describes things that are only available if you work for SAP e.g. transaction CHECKMAN. That is interesting on a sort of intellectual level, but very abstract for 99.9999% of the people who buy the book. However maybe SAP employees are the target audience, given that lots of new developers look at standard SAP code, presume it must be good, and copy the techniques they see being used.
Urban Myths
There is a phrase in programming, as in life, called “Show Don’t Tell”. As in - it is OK to tell someone to do something and then (hopefully) tell them the fact that underlies that advice, but it is a billion times better to prove to them that fact is true and let them draw their own conclusions. For example I could show someone a short dump in production caused by an empty FOR ALL ENTRIES table or not checking SY-SUBRC after a FIELD-SYMBOL assignment or whatever, and then run the code inspector right in front of them on that code and point out that the static code check highlights the errors that are causing the short dumps in production. Hopefully the lesson to be learnt is that if the original programmer had run the code inspector and took note of what it was saying those dumps would never have happened. The more important lesson is that the extended syntax check and code inspector are not some sort of joke or red tape for the sake of it, they can actually prevent problems, problems for you personally, because the IT department does not have to deal with angry users, and you do not have to waste your time debugging and then fixing your code.
The famous IT quite is “always assume the end users are eight-foot-tall psychopaths who know where you live”. If you take that attitude ten running static code checks suddenly becomes a lot more important.
The B side of that is not to take anything for granted. This is stressed in the clean book – don’t do anything just because the rule says so, find a way to prove if that rule makes sense or not. One example I would give is the urban myth at INTO CORRESPONDING FIELDS OF causes a huge performance problem, when it is so easy to do ST05 traces proving it makes either no difference at all or an incredibly small difference. Put another way in life you often have to follow rules that make no sense, at work or wherever, but for your development team you can throw a rule out of the window if you can prove it makes no sense whatsoever. In fact it is the other way around – rather than obscure rules being imposed on you for no logical reason due to management whims you can only add a code rule if it 100% makes sense to everybody with cast-iron proof to back up that reason e.g. dumps in production.
One of these things is not like the other
Object Oriented programming was introduced to the ABAP language at the tail end of 1999 with ABAP version 4.6. There was even a very cut down version of OO in the 4.5 language, and SAP Business Workflow has used OO terms since its inception.
However even after over 20 years the vast bulk of new ABAP code being written every day is in a procedural manner, or maybe even without procedures in one huge string of statements after START-OF-SELECTION. You would think if this was ever going to change it would have changed by now. This is why when I see a blog saying, “in ten minutes time every ABAP programmer will base their programs on CDS Views” I think to myself “good luck with that one”, and conversely when I saw a blog last year titled “having a hard time getting my head around anything OO” I was not surprised in the slightest.
I can only presume it is this prevalent “we have always done it this way” attitude amongst ABAP programmers that makes the authors of the clean book say “we’re no object orientation evangelists” as if some programmers started reading the clean book and then thought that OO was being shoved down their throat they would hurl the book out of the window there and then, having set fire to it first.
I am an OO evangelist, but there is one point I would mention. There is a big difference between OO as a concept and the use of “design patterns” (which could be described as templates for solving common problems using OO code). Put another way it is entirely possible to write a play in English yet not use iambic pentameters for all the spoken lines like Shakespeare did. Put yet another way OO programming as a concept and design patterns are not one and the same.
The clean book makes a big deal out of not blindly using design patterns just for the sake of it. I think most programmers don’t actually know what Design Patterns are, and this book gives some good definitions. I would say some design patterns are actually built into the ABAP language e.g. the observer pattern with EVENTS, the proxy pattern with transaction SPROXY, and the prototype pattern through the kernel level CLONE function. In addition with Web Dynpro and UI5 you are mandated to use the MVC (Model-View-Controller) pattern.
Figure 6 - Rolling Stones
Police announced tonight that they wish to interview a man wearing high heels and frilly knickers - but the chief constable said they must wear their normal uniforms © R.Corbett.
My producer says the clean book gets a big green tick for saying TEST-SEAMS are useless. It does not go as far as saying they are an abomination (which they area) but does say they are “fragile” which is a polite way of saying the same thing.
When Verbose Comes In
ABAP is what is called a “fourth generation” language. Originally programs were written on punch cards and/or in machine code and were very short indeed and you could not decipher what they did by looking at code which was a string of hexadecimal characters. ABAP is often attacked for going too far the other way and saying things like “ADD 1 to MONSTER_COUNT” as opposed to the “superior” MONSTER_COUNT += 1. I would say the former reads like English and the latter reads like machine code. There is nothing intuitive about += at all, you have to be taught what it means, whereas it would be most surprising if you could not guess what ADD 1 TO MONSTER_COUNT means.
The book notes that programmers from other languages when encountering ABAP might get quite surprised at the concept of having verbose code that tries to read like English. I would say that is a goal worth striving for, it is the sort of “literate programming” that Donald Knuth aimed for – to a human the code reads like an English description of what the program does, to the computer that code is compiled into machine code which the computer can understand, so everyone is happy. This is one of the reasons I like OO so much, there is just so much more scope for having your code read like English sentences.
A lot of the “new” ABAP syntax that came in with 7.40 concentrates on making the code a lot shorter. I am all for that, providing that clarity is not sacrificed, and if the resulting code is not understandable then I stick with the old way. For example I am not convinced that FOR/IN is clearer to understand than LOOP/ENDLOOP, even though I have been familiar with FOR/NEXT loops and the LET statement since 1981 as that was the way the BASIC language on the ZX81 worked. To be honest when I first encountered ABAP 16 years later I thought the ABAP equivalents were much more like English and thus was quite surprised when a quantum leap backwards came along.
Comrade Death
“Comrade Death” was a science fiction short story about an arms dealer written in 1944 (before there were any professional arms dealers). It must have been 40 years ago since I read the story, but I remember the end clearly:
“We have invented a poison gas that can eat through any substance in the world! But there is a problem”
“And that is?”
“We can’t find anything to store it in!”
Thus the gas escapes and kills the inventors including the hideous Dr.Krok and anyone nearby like the arms dealer and the way it works is your brain is damaged and you start walking around in circles until you die.
“How in the world does ABAP remind you of this?” asked my producer. It’s all to do with Hungarian Notation. First of all a huge push was made to get rid of prefixes such that LD_VBELN should now only be VBELN. All well and good, but then the new rule comes along that it is obsolete not to specify a variable in an SQL statement without a @ at the front as in VBELN = @VBELN. Why do you need the @ at the start? To indicate that it is a variable – you can’t tell otherwise because it has no prefix! So add a pseudo-prefix. At this point I feel that everyone is walking around in a circle led by the hideous Dr.Krok.
OO, OO There is no need to laugh
I have to say chapter 3 does quite a good introduction to OO concepts, saying why assorted OO constructs are good, not just that they are. Once again the authors realise most readers are die-hard procedural programmers.
There are a big bunch of OO design recommendations given which – as per everything in the book – not everyone will agree with but hopefully it will make everyone think twice just in case the recommendations make sense. For example you have the ever popular two rules (a) declare all public attributes in interfaces and (b) don’t have attributes in interfaces. It is somewhat difficult to square that circle.
Without going into details some recommendations make so much sense I hope no-one argues with them e.g. that static classes are not classes in any sense and so need to follow a totally different set of rules. In fact the more I read of chapter three the happier I become with the recommendations.
Figure 7 - Big Stone in SAP HQ Lobby
West London police wish to alert local residents about the activities of the infamous cross-eyed burglar. If you see this man staring in your windows, warn the people next door © R.Corbett
I have sat in one of the chairs in the SAP lobby above with a huge hangover many times, looking at that big brown stone. Anyway that’s neither here nor there, now is the time to break off, and for the conclusion.
Conclusion
- “Clean Code” by Robert Martin was originally published in 2008. All the examples were in Java or C## and so most ABAP programmers ignored it.
- In 2019 a “style guide” was published as an open source project, initiated by SAP staff, to apply the same principles to the ABAP language.
- Later a set of Code Inspector checks were published as another open source project on GitHub under the name “Code Pal”
- Lastly an accompanying book on the subject was published by SAP Press, which is the subject of this book review.
- I have only got to halfway through chapter 3 (out of 14) so I will be publishing more blogs on the subject in the future.
- My producer turned to me and said, “So yesterday when you ate ten cans of baked beans – it caused one of the cows in Farmer Jones field to detonate!”
Cheersy Cheers,
Paul
https://www.sap-press.com/clean-abap_5190/
- SAP Managed Tags:
14 Comments
