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: 
former_member194416
Contributor
52,518

Unfortunately It is not very rare to see sloppy codes in ABAP especially if you are working as a consultant. In this blog  you can see my  selection of worst ten examples. Some might be debatable but some are definitely not. It would  also be nice to discuss examples, cases you experienced in  comments section.

1. Complete program with no modularization blocks

Hundreds sometimes, thousands lines of code with no modularization blocks, no includes. Conditions with hundreds lines of codes. No readability, definitely,  It is my worst nightmare to be asked to correct or change this kind of code. It is not really different having only 2-3 modularization blocks with hundreds line of code.

2. Modification/repairs

Not all of them, but if any modification is done without enough investigation might cause big issues in time and I guess everyone would be agree it is not a good approach to modify standard programs without searching  any alternative solution. So I would suggest to think again if you are often doing modifications. And check first if it is possible to make enhancement instead of modifications.

3- Not considering performance

Codes with nested loops, one big loop with 30 select single, inside, select *, uncontrolled “read”s. They will decrease the performance more than you can imagine and should be avoided all the time. You can avoid some of them using proper design and  many alternative options are in place only if you search them.

4- Development in productive and quality assurance systems

Not very often, but it is not impossible to see such cases, no need to say it may cause big headaches and you are taking big risk if for any reason you are doing this.

5- No success and failure checks

I have seen few of these kind of program, probably it is thought that every single statement in the code will run smoothly but it is  not always the case. and If you  can not see any sy-subrc checks in a program this is not a good sign at all.

6- Not using exceptions

Very similar to point five, it is nice to consider all possibilities and implementing exceptions as described.

7- Copying big templates to every program

Especially for ALV, it is easy to prepare a template with all functionality and copying this template any time where ALV is used.Even it helps to save time, if any function is not needed for the copied programs they should be cleaned, if they are not they will cause issues.

8- Too many global definitions

Global definitions should only be used if they are needed by design, and in a good design they should not be needed too much. 

9- Lack of comments

Readability is very important, and where a complex logic is coded it is very helpful to put some comments to explain what is exactly done.

10-  Too many errors and warnings after SLIN and SCI checks in a recently developed program.

Things might change in time quickly in programming  and easiest way to see if we are on a good track in terms of development quality is  using automated tools like SLIN and SCI. It  is very easy to use, very explanatory and will save us from lots of mistakes. If you are not using this tools you might never know, if something that you have coded is right or wrong. Using these check tools will easily cure most of the mistakes mentioned above. 


It seems ten is not enough I am also adding other points should also have been in this list which are mentioned in comments section


11- Copying standard programs ( From matthew.billingham)

If you copy standard programs, in every upgrade there will be difference between  copy program and new version of the copied standard which is not a good thing. And it will require big efforts to adapt new functionality into copy program.

 

12- Writing code like 1999 ( From patrick.weber4 )

Using obsolete statements all the time it is very annoying.


13-  Badly formatted source code. ( From peter.inotai )

It effects readability negatively.


14- Avoid 'Hard codings' (From tuhin.das20 )

while displaying any text in the program. We should try and use standard text and text elements as much as possible.


15- Using exit and commit work statements in enhancements  (From johnson.ittyerah ).

The EXIT ensures that any new functionality that you add below doesnt even run because the EXIT is encountered. And the COMMIT WORK leads you on a wild goose chase when you encounter an Update error sometime later.

To keep all the troubles away ABAP programming guidelines  ( from  horst.keller )


I am happy to announce there will be a session based on this blog at TechEd Barcelona, You can check its details here.


211 Comments
horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

Thx :oops:

The book will never die!

But you find it even online .... :twisted:

And there are links from the reference documentation to the respective guidelines ...


StevenDeSaeger
Contributor
0 Kudos

Hi Horst,

Thanks for the online link ... it is great to see it is even included in the online help :smile:

And yeah ...the book's content is still so relevant nowadays ... 'unfortunately' I might add ... :wink:

0 Kudos

Good one, Gungor.

One more 'crime' I have seen is the use of the EXIT and COMMIT WORK statements in User exits and BADIs.

The EXIT ensures that any new functionality that you add below doesnt even run because the EXIT is encountered. And the COMMIT WORK leads you on a wild goose chase when you encounter an Update error sometime later.

kevinlumpan
Discoverer
0 Kudos

Agree!

If you have thought about it, it may already exist..

0 Kudos

Eish !!!!

I wish the programmer before me read this.

Unfortunately I have to clean all the mess.Its so annoying...

andrea_olivieri
Contributor
0 Kudos

Hello Gungor,

nice blog!

Other terrifying points that I've met were :

  • copying entire portions of demo programs ( i.e. SALV_DEMO_* ) into customer programs without removing original comments and/or useless subroutines

  • preserve tons of cobwebs (commented out source lines of code) , ignoring the existence of the version management

Cheers,

Andrea

0 Kudos

Additional points:

- No translation from local language to English

- No documentation available for the objects such as program, table and etc.

gasparerdelyi
Product and Topic Expert
Product and Topic Expert
0 Kudos

I would add:

+not caring about data consistency, lack of locking/update/commit concept

Ad-hoc UPDATE/MODIFY/DELETE, and then no COMMIT or ROLLBACK for a long while can be even worse than LOOP ... SELECT SINGLE ... ENDLOOP.

No care on implicit DB commits, baking updates on the database due to WAIT/RFC/HTTP, WAIT/RFC/HTTP called within update task without extreme care...

varghees_devasi
Explorer
0 Kudos

Good Points :cool:

dirk_wittenberg
Contributor
0 Kudos

Hi Jeffrey,

if it is appropriate, I use iterators. E.g. when I have to loop over a list in different ways ( forward, backward, building a hierarchy etc. ). Then I use different iterators implementing the same interface.

dirk_wittenberg
Contributor
0 Kudos

There is a lot of stuff about writing good code in the available in the web.

We only have to start learning from the non-ABAP world, e.g. the book of the gang-of-four or the principles like SOLID  https://en.wikipedia.org/wiki/Solid_(object-oriented_design)#Overview , Single responsibility https://en.wikipedia.org/wiki/Single_responsibility_principle etc. .

The examples you can find are mostly using JAVA as language or C# or Ruby.  But you don't have to know these languages in debth to understand how it works and to be able to transpose them into ABAP.

--

My proposals for the list of crimes:

- mixing up user-interface, business logic and persistence layer within the same modules.

- lack of tests

Regards,

alexander_kutz
Participant
0 Kudos

To me (to be honest) it is not a crime to not use "if ... is assigned..." ... I think it really depends on the model. Using always "if ... is assigned..." means automatically ignoring errors and sometimes an error message is useful if something is not working as expected :smile:

matt
Active Contributor
0 Kudos

I have removed all comments discussing FAE vs INNER JOIN. This has been discussed at length and I do not wish to see it being discussed again as it adds no value and has the potential to cause great confusion.

That's what I said just over a year ago, and I see no reason to change my stance. If you wish to continue discussing it, feel free - but do it here:

For All Entries is NOT better than INNER JOIN in most cases

former_member182873
Participant
0 Kudos

Nice one gungor.ozcelebi
Comments are Very Helpful and adding more points for your blog..Bookmarked it to follow :smile:

Regards
Manju

Clemenss
Active Contributor
0 Kudos

Never use global vaiables and/or tables.

0 Kudos

Hello

You may add the first one about BAD training: no training about ABAP and starting to work on a SAP project.

results:

- some functionalities have been rebuilt specifically, they existed in standard

- no idea about good ABAP statement

- no idea about performance issue.

- They had no idea about customizing, they tried to force the system by specific development.

On this SAP CRM project, people have learnt about ABAP on the same time they have coded. After many months of work, we have to rebuild everything. Fantastic.

former_member194416
Contributor
0 Kudos

Good one, I agree that it is a big problem, but it is a project management, resource planning issue,  not directly a coding crime in my opinion.

0 Kudos

Hello Gungor

Yes and no (:)).

Yes:

- fully project management issue,

- ressource planning issue,

No:

- no university training about ABAP

- no university training about performance issue (my remember about university, in 2003)

- ABAP is a very specific, very good statement, not learnt anywhere but on ABAP training.

I have written 4 books in abap, not for my pleasure:

- too many issues in project due to that (NO reasons)

- again on friday another project has stopped is SAP CRM implementation due to BAD ABAP implementation.

After having giving training in Middle East, in Europe, I have seen the missunderstanding of trainees how to do development in ABAP, Always the same issue: try to develop in ABAP like in PL/SQL, JAVA. It is why I have translated my books in differents languages.

In France, maybe this week, I will act  on a project to stop SAP CRM project and transfer data to a legacy system (you may imagine my desapointment). In 3 years, it is the 4 th project I hear about this way.

Best Reagards and Happy Easter.

Yann

Ps: I have writtenmy first book in French due to high level in English from French spoken (:)). I have seen the same issue in the world, It is why I have translated them in different languages. I have considered you may be good despite your english level, and degree. but you need follow a good training.

matt
Active Contributor
0 Kudos

But why should it be like that? I know many excellent ABAP programmers who didn't do ABAP at university, or even have any kind of computer science degree - they learned on the training courses provided by SAP and that was it.

When I was in charge of getting developers for projects (including one French implementation)), I didn't have enormouse difficulty getting the right people. I was simply very choosy about who I let on the projects. I rejected 2/3 of candidates from the outsourcing partner, and/or I selected independent developers who I'd worked with before or whom others could recommend. For internal recruitment, I just made sure I got the best people.

Is it simply that the quality of developers has sunk to an all time low, and so there are fewer and fewer good people about? Or is it simply you no longer have choice and have to use whatever the outsource partner deigns to give you?

former_member194416
Contributor
0 Kudos

There are many reasons I believe. One of the reason is speed of the developer is  overvalued by functionals and  sometimes by the clients, no matter what the quality is or how  complex the development. In the environment I currently work, competency of a developer often judged by the how quick the development is completed ( and with minimal functional support ) without assessing the quality and it is also often assessed by non technical persons. And when it is necessary to change that  program nightmare begins.

And about things are getting worse, conceptually quality of the code is not even being a secondary focus, unless you are working in a validated system. Usually only focus is cost, and without thinking what will happen in long term people are making false short term assessments which will gradually decrease overall quality in long term.

matt
Active Contributor
0 Kudos

What really needs to happen is a focus on and measure of the total cost of ownership of each development - tracking it through it's life-cycle. It would then become evident that quality reduces costs. Time spent during development, making sure it's right, saves multiples of costs if it has to be fixed once in production.

So long as the mentality of only costing the project and not considering the long-term maintenance and support costs continues, I can't see there will be an improvement.

I do know one very large SAP project that after 5 years of "get it in quick" started a remedial quality improvement program. That's good, but it's still way more expensive than building quality from the start.

On the other hand, fixing the mess left behind by projects provides me with years of lucrative work... :smile:

joao_sousa2
Active Contributor
0 Kudos
In France, maybe this week, I will act  on a project to stop SAP CRM project and transfer data to a legacy system (you may imagine my desapointment). In 3 years, it is the 4 th project I hear about this way.

Next time you should hire me! (joking, actually you can't). Two SAP CRM projects under my belt, two projects delivered on time and on budget. None on 7.0 unfortunately.

But what's the problem that's so serious it stops due to ABAP? Just curiosity, but one of CRM's problems is that the data model is completly different from SAP ERP. Try to do reporting in CRM and you will fail, badly. The tables are too narrow and normalized, it's designed so that you use BW for everything.

In one of my projects I actually had a ABAP report where I made an RFC call to the ERP to get filters more efficiently and only then would I get the CRM data.

joao_sousa2
Active Contributor
0 Kudos
It would then become evident that quality reduces costs. Time spent during development, making sure it's right, saves multiples of costs if it has to be fixed once in production.

The counterargument is that time is money, and the time business is waiting for a development is money lost through inefficiency.

Eight months ago I was doing QA on the implementation of new processes and my report basically said that the blueprint was rubbish and should be redone (because it looked like help.sap.com). After paying me to do QA, the business went ahead anyway because "we can't wait". 8 months have gone by and they had a go-live last week with only one process and a lot of headaches.

Most of the time, senior executives are to blame. They make stupid decisions based on ignorance, and junior executives are too scared to refuse to go forward.

matt
Active Contributor
0 Kudos

Not so much a counter argument, but something that needs to be taken into account. Unfortunately, it's not usually just taken into account, it's the be-all and end-all. The maintenance/support costs are ignored (because they only come to bite you on the backside later... by which time the (ir)responsible people have moved on to the next project/job/level up the food chain).

Thankfully, not all companies are like that. I know several multinationals that have a rigourous approach to quality and do track costs over the years.

Private_Member_7726
Active Contributor
0 Kudos

Indeed, and since the disastrous practice of copying seems to have been so prevalent, I can not help but wonder if this kind of guidance from SAP itself is partially to blame for it: 213751 - Programs: Copying versus modification...

Clemenss
Active Contributor
0 Kudos

Discussion drifts away from the original question. I think that doesn't really matter because new interesting aspects are coming up. I like the idea of regarding total cost of ownership which definitely implies tracking cost over years: There are realy contradictions: Currently I'm working for a quite huge family-owned company. A couple of years ago they introduced a ticket system to keep track of IT costs: operating department (business) creates a ticket, IT will make an offer, business will agree, IT will postpone and sometimes solve. Same procedure applies for bugs and all kind of new requirements, sometimes mixed. Administrative overhead sometimes clearly outweighs implementation effort.

There seems to be no planned training for developers. Everyone commits his personal ABAP crimes as used to as long as the program runs...

Recently I complained about a program of > 3000 code lines, no documentation and >130 versions over 5 years, none of the developers still in the company. And a new requirement has to be integrated. Business told me that a complete redesign might cost them 20 days. Nobody knows how many days have already been spent over time...

Are there any options for the developer except adapt to the process, close your eyes, ears and mind?

joao_sousa2
Active Contributor
0 Kudos

I think it starts inside the IT departament. Is there a guideline and code review process in place? At least in paper? Many people complain about the CEO, but don't have code reviews taking place.

matt
Active Contributor
0 Kudos

Working in a validated industry does have its advantages! Just say the magic words "FDA FDA FDA".

0 Kudos

Hello Clemens

In my mind, we discuss about the current status of a lot of projects.

I have read a lot of answers, I cannot answer to everyone, even if answer are very interesting.

If we have an ABAP crime, it comes from environment: it management, budget, traicking...

But like you may guess/say it, we need prevent the result of our work.

It is why I have created my own solution, to help to solve the situation you describe in your post.

SAP et SCRUM / AGILE

I do not invite you to buy it, I am not a good salesman (:)).

I invite you to think differently about ABAP coding way. and even about customizing (specific).

And what you propose, like others, is to prevent the ABAP crime.

Happy Easter.

Yann

PS: You are right: Discussion drifts away from the original question. I stop answer.

joao_sousa2
Active Contributor
0 Kudos

Fresh new one. Called in as an external consultant to solve a problem that was stalling all shipments of a company. Picking was failing and they didn't know why.

After some debugging I found out that a dinossaur ABAP (yes, one of the real ones) used RV_INVOICE_REFRESH inside a SD user exit that also tried to create an invoice during picking (actually during every single save....) and it was blowing up if the save was performed from a Webdynpro ABAP screen.

Don't use unreleased function modules, especially in save user exits.....

PS: I wonder if this counts as volunteer work that Linkedin is always telling me I should add to my CV. Help the dinossaurs.

matt
Active Contributor
0 Kudos

How much was that bit of coding costing the company?

I have a story of a badly written program that cost a company nearly half a million Euro. It calculated salesmen commission, but failed to include one type of payment. The program was so complex and badly written, it had to be rewritten to be fixed. The delay meant a deal with the unions of a fixed commission for that month - which turned out to be just shy of half a million Euro short of the actual due commission, and could not be clawed back out of future payments.

joao_sousa2
Active Contributor
0 Kudos

At least half a million, which is much more then the whole project cost. But it was a mix of errors, for one not doing code review since this is unexcusable, but I also found that the code that was blowing up was uncommented after the end of the integration tests.

But how do you explain to management that the error was caused by bad programming? They don't even want to understand what programming is.

matt
Active Contributor
0 Kudos

"This program was like a house of straw built on sand - programs that are brick built on solid foundations take a little longer, a bit more skill and require more initial care, but will last for years."

or "This program was like Vista..."

or (if they're Mac Fanboyz). "This program was like Windows - if you want one that just works you need a Mac version". Now, I know this argument is garbage, but if they're really Mac Fanboyz, then you know they're easily gulled. :smile:

bjoern_panter
Product and Topic Expert
Product and Topic Expert
0 Kudos

Guys, I summarized all of them in the main chapter of Development Guidelines for Greenfield Implementation in sync with SAP Custom Code Management

Going to HANA and cloud, the good thing is, that many of these old techniques will become obsolte and not compileable anmore.

* Don't use macros

* Don't generate code with any kind of generator

* Don't use memory commands

* don't use this "special variable assign" command. The experts knows what I mean.. 🙂

dellagustin
Product and Topic Expert
Product and Topic Expert
0 Kudos

Regarding (5), I see a lot of FIELD-SYMBOLS using prefix fs... (<fs_bla>), this is really useless...

dellagustin
Product and Topic Expert
Product and Topic Expert
0 Kudos

I don't know if I can say it is a crime, but I really annoys me when Text Elements are used where a T100 (SE91) message should be used. This prevents from creating long texts and the usage of BREAK POINT at MESSAGE (not message statement, but a specific message).

Also, when adding the message to a message list/container/handler, it is nice to have a MESSAGE ... INTO dummy_text_var where the error whas detected so that you have can use the Break Point and Where Used functions properly.

Regards,

GD.

Former Member
0 Kudos

Very useful.

Thanks a lot.

TuncayKaraca
Active Contributor
0 Kudos

What a nice blog post Güngör. Thank you so much.

As I always recommend the book everybody "Official ABAP Programming Guidelines" by Horst Keller and Wolf Hagen Thümmel.  Hey developers, read something and learn. Not just copy / paste codes.

0 Kudos

I liked it, but think that missed to approach the comments, sometime have very other none...

Former Member
0 Kudos

I have just read all the comments of this post during my fabulous day of sapscript maintenance...and let me say it's much more enjoyable then debugging SE71...

I like to read this blogs because as someone already told here, I am a developer and my goal is to develop the best solution I can with the tools I have available.

Beeing a consultant I do see some of the ABAP crimes mentioned here, and as an external resource I try to engage developers from the customer to look to the ABAP to the Future (the book I am currently reeding and suggest to anyone).

The frustration is that 90% of the time they just don't care about it. Even worse, is when you arrive to a project and hear: "We don't use Objects here!"

There are so many interesting techniques in the SAP toolkit, like ABAP Unit Tests, ABAP Test Cockpit, BOPF, BRFplus not to mention the new wave with HANA and UI5 that it's really disappointing to be in some client development team where ABAP OO concept is nothing more then a class with 200 static methods...

So I guess the biggest crime I can point out in fact is the mindset of the developer, and it's nothing to do with age!! Or you want to be better in what you do or you don't!

Thanks for the post, it really helped the painfull sapscript maintenance..

joao_sousa2
Active Contributor
0 Kudos

That ABAP OO with 200 static methods really hurts, but it's the reality in many places.

I think it's "everyone" fault in the end. Developers who don't want to bother, managers who want to play it same, etc.

With SAPUI5 one of the main warnings is "Make sure the customer accepts Javascript before you start hammering away", because many times they only have ABAP developers. How will they maintain your SAPUI5 applications? They need to invest... and that costs money.

Former Member
0 Kudos

I guess it will be a Darwinism process..,

Learning Javascript is in the future plans but there is still so many things to learn in the ABAP universe that JS is always postponed..for instance ABAP Unit Tests..do you use them? I am studying them and trying to start inject it in my devs because it really makes sence to me, but again, as an external coming to a client and starting using this tools when the manager do not really care is not seen with good eys..

I had the luck for the past 3 years to work with some curious colegues that shared the enthusiams to look deeper and learn something new in every dev assigned..

That makes things easier...but now that I was assign to a new client it feels like entering in some roman museum...

Fortunatly there are forums like this where people like you share their experience and knowladge and discuss things deeper!

Thanks

dellagustin
Product and Topic Expert
Product and Topic Expert
0 Kudos

ABAP Unit is great, the problem with the adoption is that in order to use it well people must master ABAP OO and OO Design Patters, which have an adoption problem of its own...

I come from a C++ background and for me OO is something natural, but people that have as background only procedural ABAP have a lot problems with it. Too much time in the comfort zone...

dellagustin
Product and Topic Expert
Product and Topic Expert
0 Kudos

By the way, I am also learning JS and it is very nice, having to develop using different paradigms such as functional programming is a very interesting challenge.

The good part is that there is an absurd amount of information regarding JS in forums.

Former Member
0 Kudos

Hey,

Can you please give me more insight on  "3) Using FOR ALL ENTRIES instead of a nicely crafted INNER JOIN"? I know that there are cases where the former is better but when?

Thanks

Former Member
0 Kudos

Hello Mohit,

matthew.billingham created a specific forum for this. You should look at it!

For All Entries is NOT better than INNER JOIN in most cases

Former Member
0 Kudos

Thanks for the share, got to know a lot :smile:

dairolozano
Contributor
0 Kudos

"  5) I remember once a dump was caused by uncaught exception error. The idiot programmers fix was

TRY.

...

CATCH cx_root.

ENDTRY.

Which led to database inconsistencies...  *sigh*  "

That reminded me a Simpsons chapter where Homer simpsons can't understand a Red Led on his car, so he covers it with tape and says "Problem Solved"..

Former Member
0 Kudos

Hi, I have one more suggestion...

When we use message handling using tables (Having all the messages, their types, variables and other information in the tables), we do not have where used list populated for a message class (SE91), in such scenarios, we can have a where used list with below statement-

IF 1 = 2.

     MESSAGE ID <MESSAGE ID> TYPE <TYPE> NUMBER <NUMBER> INTO <variable>...further additions.

ENDIF.

I have seen a lot of SAP code in which they have done it, so recommending the same (I too did it in my developments), let me know if its nice...

Thanks

dellagustin
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hello Mohit,

Please check my comment:

http://scn.sap.com/community/abap/blog/2015/02/24/top-10-abap-crimes#comment-589922

In my opinion it is much better to use just

MESSAGE ID <MESSAGE ID> TYPE <TYPE> NUMBER <NUMBER> INTO lv_dummy_text WITH ...


without generating unreachable code (IF 1 = 2).


This has the main advantage that you can use Break Point At Message to stop at specific messages, at the point where the error occurred.


Labels in this area