Personal Insights
Are Your ABAP Guidelines Misguided?
Folks,
Every SAP customer that employs ABAP developers has some sort of internal development guideline document. In over 16 years of SAP career, I have seen many of them and most are… how do I put this? Rather misguided. While preaching code optimization, reusability, keeping up with new features, the guideline documents themselves are not following those principles.
Reusability
How can I tell the guidelines are bad without reading them? Easy: they are more than 20 pages long.
We all know about “best practices” in SAP world and every developer (and even some IT managers) are aware of the advantages of reusing common code libraries, open-source solutions, etc. But when it comes to ABAP guidelines, SAP customers seem to insist on reinventing their own special bicycles.
Every SAP customer wants ABAP programs of the best quality. So, why the way to achieve that for you would be significantly different from thousands of other SAP customers? There is no “why” because it is not different. As someone who recently switched sides from customer to consulting, I will let you in on a secret: 90% of the corporate ABAP guidelines repeat the same information.
Lead by example and consider incorporating these public resources by reference rather than by value:
- SAP ABAP Programming Guidelines (use Google search to find these for your ABAP version, this example is for 7.53)
- DSAG Best Practice Guidelines for Development – in my opinion, this remains one of the best resources for ABAP developers
- Clean ABAP – ultimate and ever-expanding open source ABAP style guideline
Devsplaining
“YOU sHOUld noT puT SELECT iN A lOoP”. Gee, thanks for the tip.
It does not matter how valid this rule still is. Development guidelines are not a replacement for baseline training and ABAP 101 material does not belong here.
These days, ABAP keyword documentation explains quite well how the commands work (believe me, it is a huge improvement from the early 2000s when documentation was randomly sprinkled by text in German). The examples of optimized code provided by SAP are available right in the ABAP Editor. If this is not enough, SAP Press and other publishers offer the books for a wide range of ABAP developer audiences: from complete beginners to experienced ones looking for latest and greatest.
One might ask: but Jelena, what do we do if the developers we employ just keep doing these silly things, such as placing SELECT in a LOOP? Simple answer: this is not the issue that will be solved by copy-pasting ABAP documentation into the internal development guidelines.
Every developer needs to have some ground knowledge before they can begin work. This is not different from any other profession. The ABAP beginners and Junior Developers need to have guidance, mentoring, and support available to them while they are still learning. If more experienced developers are having trouble, we have tools (such as ATC) that perform baseline code quality checks and can be executed automatically. And in the extreme cases, well, as Ron White said, “you can’t fix stupid”.
Ghosts of ABAP Past
“Thou shalt not JOIN more than 5 tables”, “terrible things happen to those who write lines longer than 72 characters”, “BINARY SEARCH is great” (puh-lease), and other ABAP urban legends fill the pages of too many corporate guidelines. Right next to them, lie the great relics: recommendations on proper practices in creating module pools and functional modules. Indiana Jones would have a field day here!
ABAP guidelines should guide the developers how to write programs today, not in the last century. The only guideline on functional modules should be that they need to be created only in a few cases and should call a class method. And if you are still creating module pools, well, then quality of guidelines is probably the least of your worries.
This is The Way
As Leonardo da Vinci said, “simplicity is the ultimate sophistication”. KISS principle in development is one of my favorites and there is no reason why the development guidelines should not follow it too. With this in mind, I present to you Jelena’s Nice and Simple Corporate ABAP Guideline Template ™.
- Introduction (1-2 pages). Outline your company’s strategy, principles, what your guidelines are meant to achieve and how they add value.
- Naming conventions. Note any peculiarities (for example, some companies use special IDs in the package or object names). If this section takes more than 2 pages then you are doing it wrong.
- References (links) to SAP / community guidelines and a reminder to RTFM. 1 page
- Developer tools. Do not copy from SAP Help, only note anything specific to how your organization uses them and if any third-party tools are also in place. 1-2 pages
- Any requirements specific to your organization. This can include industry-specific compliance, accessibility requirements, and such. Up to 3 pages.
Total: 10 pages maximum
Business Value
This section is for the IT managers who might have trouble understanding specific benefits of Jelena’s Template and how exactly it translates into value for the stakeholders.
- Stating the obvious here but compare 100 pages vs 10 x how many consultants you engage x reading time x billable rate = pure, quantifiable cost reduction.
- By referencing SAP and community guidelines and best practices, you do not only make your own document shorter but also get coveted “automatic updates”. Community keeps the guidelines fresh and updated for free. The only part that your team may need to review is the 10 pages of the template. So, 90 pages x time it takes to review and discuss x hourly salary… You know the drill.
- Simpler rules are easier to check automatically and enforce. This leaves more opportunities for the development teams to work on innovative design, collaborate, and share knowledge instead of having a quarrel about a variable prefix that is not in compliance with the rules from page 63 of 156.
Conclusion
I hope that one day the corporate ABAP guidelines will do what their name suggests: guide, or even inspire, the developers to create better programs instead of serving as the ABAP Penal Code equivalent. In the meantime, whenever you encounter a monstrosity of a guideline, discreetly slip this link to the person in charge: https://github.com/Jelena-P/NiceABAPGuidelineTemplate Hey, it’s open source and free, so how could it possibly be bad? 😉
Disclaimer: this blog represents author’s personal opinion and not an opinion of SAP or my employer. This post is not based on any single organization and any resemblance of real guidelines is purely coincidental.
A nice blog post and I totally agree with you that the most developer guidelines are not worth reading. But I'm afraid, I have to disagree with you in in some points:
First of all, SAP guarantees backwards compability. That means anyone is (technically) allowed to program as in 1995. And even then ABAP wasn't the most progressive language. I've met many developers, doing their best, but are not motivated enough to learn "new" types of programming. "Object oriented programming? That's just a hype that will disappear!" is a quote, I've heard a lot. See https://open.sap.com/courses/wtc1/question/8ec09eb5-4028-4784-afa8-9ec47a0f80a6 - a course on ABAP Unit Tests and the feedback is: "yeah, thanks for the course, but why do you only use eclipse and ABAP OO?"
If even object oriented programming is seen as a "fancy new thing", that "is a hype", the problem is not the developer guideline, but the training. And if there is a lack of training, you simply need ABAP 101 rules.
Neither the language, nor the system forces any developer to stay trained (unlike most of the other programming languages!).
I won't disagree on the fact that some developers just continue doing what they've been doing and have 10 times 1-year experience. But let me ask this: how exactly adding this to internal ABAP guidelines helps? How does this solve the issue?
This kind of reminds me about our local Reddit sub where people regularly go on the rants how other drivers don't turn on their headlights or use high beam and blind everyone. This has been going on for years and solved absolutely nothing.
Technically it doesn't.
But in my filter bubble this is the most efficient/only way, that is broadly accepted, if you want to force a certain type of coding. Untrained people dont want to read multiple documents. The sentence "It's (not) in the developer guidelines!" ends most discussions if something is useful.
You said, that you wanted to add a page of references for SAP / Community - guidelines. In the first glance, I thought that was a good idea. But as I thought closely about my expirience in the last years the number of references grew.
I worked for add-on software providers most of the time. Most of them had to support very old systems (4.6C or 7.00 mostly was the basis). So lets take a fictional addon software and base it on 7.00, and see what happens to the references:
We structure our software as the SAP Guidelines for 7.5X define, so lets set a reference to it.Transactions pointing to classes. Function modules only for dynpro screens and reports are used to provide batch services. But in our document we either have to explain, that some parts of the SAP guidelines are unfulfillable or we set a dozen references to each subside. The same goes for unit tests. They behave slightly different in 7.0 and other classes have to be used. Then we have to get to the "obsolete" parts. Some things, that became obsolete in 7.5 can be substituted within 7.0, other things can't.
I think your idea is a very good one, if the team of devs is well trained, motivated and open to new ideas. But in all other cases I would spend my time to implement some of Ennos points, rather than changing the developer guideline:
New programmers should use the newest available paradigms and constructs. Certainly they should never use obsolete constructs. However, as the Clean Code github says - they may need guidance from older programmers should they encounter them in legacy code.
You won't find old stuff in current SAP training courses (well, you're not supposed to!). I'm pretty sure some people are being trained from very old training notes. The developer guidelines are should be company specific additions to the relevant ABAP documentation. As such, they constitute part of the knowledge that developers in the company need.
It seems to me it follows logically from this that the only mention of obsolete constructs or old fashioned techniques should be in the negative. I.e.
Any programmers who've not moved on from use FIELD-GROUPS will find their code being failed during quality checks. PERFORM is covered by 1 (with a very few exceptions) - which is fine as you can do procedural stuff perfectly happily with STATIC FINAL CLASSES.
* For systems where you can't JOIN and internal table: or c) you are processing a provided internal table along with the select.
Hey Jelena Perfiljeva I partly agree. A document named guideline should not have tons of naming conventions. On the other hand the naming conventions must be written down even though they might be checked by ATC (and even could be automatically corrected in many cases). They might not be named guidelines maybe...?
A guideline in terms of encouraging developers will not fit on some pages. In my opinion the key to encouraging people to write better software is working together (pair programming), educating (courses, workshops, code-dojos and so on) and individual coaching/ assistence by the leaders and company.
About devsplaining: you cannot know everything and things change. So it is no fault to write down some basic rules and (basic) knowledge.
Thanks for the comment, Enno! Naming conventions are fine, it's not really an issue with most guidelines.
Not sure I understand your other points... "A guideline in terms of encouraging developers will not fit on some pages" - why? "Use OOP. Read Clean ABAP. Always do your best" - boom, done. 🙂
I completely agree with you that team work and education are the key but what does this have to do with the guideline document? One could write in "we encourage knowledge sharing" and include some specifics, e.g. team lead to schedule a monthly session.
I guess we'll have to agree to disagree on the basic rules. To me, it seems similar to copy-pasting the API code into your program instead of calling the API. Basic rules are not really different for each customer.
Hey Jelena Perfiljeva
you asked what guidelines have to do with team work and education.
I don't think that a guidline can do what you wished it could:
It's not sufficient to define what should be done and what not. Encouraging or inspiring people will come from team work. Unless we have a completely different opinion of what these words mean... 😀
To borrow from Graham Robinson , I think we're violently agreeing. 🙂
Naming conventions of object - i.e. class names, data elements etc. - need to be mentioned. For naming conventions of variables, refer to the ABAP style guide for when prefixes are a good idea and when not. Where stuff is written that is documented elsewhere (SAP style guide, DSUG style guide, Clean Code initiative) - just refer to those in your documents and make them part of your guidelines.
That's perhaps somewhat contradictory. No of course you cannot know everything and things change. But basic knowledge... well that's be definition something you darn well should know!
Matthew Billingham How do you define "basic knowledge"? where is the line to "not more so basic knowledge"?
To clarify what I said.
If you define basic knowlege as that which everyone should know then it is immediately clear that it should not be in any guidelines.
Hence what you wrote appears contradictory - to me.
In response to your question, determination of what is basic knowledge is not necessary for my statement above to be true.
Also, to my mind, your question is identical to asking "How do you choose what goes into guidelines?". There is no definite answer - it's a values question. I think it's reasonable to assume somethings are good to into a guideline and others are not.
For me, basic knowledge and repeating what it published elsewhere (so long as it is referenced with a requirement to read and follow), is not necessary. Reminders of a few of the most important anti-patterns (don't use this, use this) are a good thing. As are a push to use newer technology (In my job 2002-2004, I enforced the use of the control technology over list processing. I just told my team "not optional"). I also failed the program of a very senior developer there who was still using FIELD-GROUPS).
Concerning Clean Code - that really needs to be discussed and agreed locally. The style guides just are current best practice as considered by senior members of the ABAP community. But Clean Code is rather more subjective. I'd still make it required reading.
thanks for clarifying Matthew Billingham
I'm going to sound like a broken record here. I mostly agree. A common constantly changing and updatable code standards sounds like a great idea. I try to follow them - most of the time. When it is something beyond my personal skillset, I may/maynot have time to learn it. So it depends on the project, deadlines, etc.
How many people read this once a month? Once a year? So to expect consultants to keep up with it will most likely fail. Me - personally - I try to keep up with it. It's probably a quarterly thing for me.
Each company is a bit different - not only in what they have available, but also in the skill set of the developers. Sometimes that skill set is constantly changing based on the consultant brought in. Also there could be old programs out there that just don't follow today's guidelines. So you want to make sure that nothing is changed that isn't broke. (depending on your company) Yes, someday the entire thing will be rewritten, but there has to be time and/or money to do that.
I've often thought of project vs. consultant. So if I just want a PDF written, I would bring in the best person that knows PDF. If I wanted a UI5 program then the best at UI5. Sounds good, right? That's not always the way things work. They might be brought in for PDF and have to work on UI5. In that case basic knowledge needs to be in the guidelines. (Also keep in mind if I am working with a consulting company, it becomes a mixed bag. Some are amazing. Some are just learning.)
So with this long reply. I agree in principle. Also totally agree 20 page documents won't work, unless they come with a one page cheat sheet. I'd love to point them to clean ABAP code. But when I myself don't keep up with it, it would be hard to do.
BTW - I hope by now the training classes have gotten beyond select - do something even loop - endselect. That was my training way back when. I quickly learned that would kill our system. Now with much more advanced ways of getting to the information you want, it should be easier. Right?
I love these blogs that make me think. Thank you!
Thank you for the thoughtful comment, Michelle!
I wouldn't be writing these recommendations if I didn't follow them myself. The guidelines I wrote myself years ago (I was the only developer back then and the guidelines were mostly needed for assorted consultants) were 4 pages long.
They went something like this: here is how we name the programs / objects, you should write good code optimized for performance and here are the tools you can use to ensure that, don't do stupid stuff, when in doubt - read DSAG guidelines, have fun.
I feel most comments are missing my main point. Those same recommendations that customers are writing into their guidelines are already written elsewhere. Repeating them will not force anyone to learn. If someone can't read / find / understand DSAG guidelines, for example, then it doesn't matter how many times you repeat the same information. It's like screaming when no one is listening. ¯\_(ツ)_/¯
😉 Gotcha. Yes, it is a problem when they can't find the answer themselves. Other internal resources to your company, it would be worth a little hand holding. External resources - you expect them to be rock stars or at least able to find the answer. So I agree with the main part of the blog. Find your own best practice guide and stick to it.
I'm thinking - when we code that is NOT best practice.
The why - might be specific to my company:
Hence a ABAP guideline strictly for that program. And an explanation of why we do it that way. And just specification do not work. Why? Because very few programmers read those first. (I learned that the hard way)
Or it could be general:
Some of the pragmas are just plain stupid in my book and they do nothing for the code. I would rather have the stupid warnings. I should dig into clean code again, maybe it has something about these. And yes, unchecking field attributes gets rid of most of them.
So in summary I think you are right - and maybe only the exceptions should be in the guidelines. You and I should talk off line about naming standards. Do we need them? I don't think we do when we can navigate to them.
Great blog - you've gotten people thinking. My brain is going one hundred miles a minute. I am the only internal developer / programmer left.
If developers were uniformly smart, educated, responsible, hard working and conscientious, you could have a guidelines document like this Jelena suggested ""Use OOP. Read Clean ABAP. Always do your best"
Or even more simply.
Do no evil.
Really an excellent post, can not agree more to the general direction it is going to.
Maybe just a small addition to the point
Ghosts of ABAP Past
I can imagine that some customer developments still need to be done on an existing system which is not on the latest Netweaver version(like the usual R3 systems 🙁 ) .
Also custom development/extension on modules which were originally anyhow developed by SAP in a procedural style, and/or use classical Dynpros(they are actively used and developed as of now).
But of course you are absolutely right, i would say what i miss in the guidelines is the WHY part - why do we want or not want to use actively functional expressions, for example, and so on.
So that we don't see "Ghosts(or guests?) of the Future" as well:-)
Thanks for the comment!
Yes, legacy code vs new development is definitely something that guidelines should address, if it's applicable to the customer. It's helpful to have guidance on when the old code needs to be refactored and when it's more practical to just let it be. The exceptions will need to be made in the code check tools as well. And, of course, refactoring is the whole other (exciting) subject. 🙂
You're exactly right about the "why" part. "You should use OOP" but why? What's in it for me / company? If there was more "why" then it would be also easier to purge the old relics during the review. E.g. "no more than 5 JOINs" rule was spurred by some issue in MS SQL DB long time ago. The DB issue has already been resolved by Microsoft since then but the legend lives on.
Clean ABAP and SAP guidelines cover most of "why" questions too. It's yet another reason to reuse them instead of writing your own text.
For those legacy applications, I'd say
Well most of the things I had to say has been posted by All the other wise people here.
Just one thing to add: at least with my company these guidelines are sort of a contract. Yes, many things don't belong there and a skilled Developer knows that. But there are a lot more Code producers than skilled Developers. So with these guidelines we have an argument to block developments from import to production. Or request overhaul.
I am currently configuring ATC and had a lot of feedback . Many questions were like "how can I get rid of Findling xyz?". And the answer: "Stick to the guidelines". Most of the people don't even think of a possible reason or read the help. Because hey it works, that's all the customer requested!
In short: I would really like to shorten those guidelines but you have to deal with the stupidity of people.
Thanks for the comment!
Regarding this point: "with these guidelines we have an argument to block developments from import to production" - yes but I'm confused why is it not possible to achieve the same by simply referring to publicly available guidelines? (Some examples were in the blog.)
What is happening now is something like this:
DSAG: "Do good stuff"
Customer 1: "Do good stuff"
...
Customer 99999 "Do good stuff + <random nonsense>".
What is more productive:
DSAG: "Do good stuff"
Customer 1... 99999 "See what DSAG says".
(To clarify, DSAG is just an example here.)
As a developer (I assume), if you saw the same code repeated many times, you'd think "wow, this is silly, we should put it in a global class!" Why the same can't be done with the guideline documents?
I went through our guidelines. In fact there are mainly things different from DSAG or else where. Thanks to the creators!
Still we are over that page amount as we e.g. have a list of frameworks written in Z-Code that should or must be used. Additionally naming by Module etc. And of course forbidden constructs (e.g. Form.. Endform)
What we are still lack is the Intention Part. I will discuss that.
List of custom frameworks - well, it's a good point. OK, I'll allow few more pages for that. 🙂
Lucky you to have such good guideline document!
I did development in an environment where several times I got findings that I initially sought exemption - but then I reread and reconsidered, and changed my code. They were right! Now that's a well-configured ATC!
How, I did development in another environment and got findings that I couldn't ignore, like I'd not prefixed my internal table customer_orders with an lt_. That made me sad. 🙁
Great blog thanks!
I agree majority of the points. One thing i want to add on top of expectation would be a proper design pattern and principle in the guide. Well, naming standards, Do's/Don'ts, best practices are very important but sometimes i feel it is micro-managing the development and does not see the big picture.
Majority of the issues and the code smells we are facing are caused by lack of design principle documents. Lets say namings are perfect, no 5 join in a select statement, no select inside the loop but code is unreadable. This is a common problem i am facing every single time.
An ABAP developer might not know OO ABAP which is not a problem but everyone need to be aware of design principles. Majority of SAP developers, experts or SMEs are not aware of design patterns and design principles. They don't even know the difference between software architecture and software design.
They are simply taking the advantage of isolated SAP ecosystem by implementing their "own" style and ignoring the best practices.
Any design pattern or design principle which is applicable for JAVA, Python or C++ is also applicable for ABAP.
Single responsibility principle should be the first principle to be followed by an ABAP developer or let's say strategy design pattern should be implemented whenever is required.
Any javascript style guide (i.e. AirBnB) can also be followed by a SAPUI5 developer. Developers should have a very strong case for not following design principles and also should also have a very good case while implementing a design pattern.
For my projects which i am responsible for entire technical layer, i don't allow anyone to use select statement in a method which contains business logic. DB related selects, updates, inserts should have a concrete class which they are responsible for one thing. I don't also limit them using
lr_objectorlo_objectwhen declaring a data reference. As long as it doesn't break the design and not extreme variable names, it is fine. I don't encourage developers to have more than 100 lines of code in a method. Definitely it is breaking single responsibility principle and doing more than 1 thing.Another thing would be several pages of PDF or Word documents. It is nightmare. No developer want to read that documents. I think physical documents are not developer friendly at all. For all the guides, i am using https://docsify.js.org/#/ which supports markdown documents and can be deployed as BSP to the system(via eclipse). Both user guides and developer guides existing in the system in a user friendly way. Full text search capability also makes it easier to find anything. If we want to update the document, it is updated from Azure DevOps and automatically deployed to the system. A web-based guide is always easier to reach and easier to refer.
Thanks for the comment, Bilen! I agree that design is usually the issue and I'm definitely not a fan of micromanaging either. "Not seeing forest behind the trees" is definitely an issue with many guidelines and, consequently, with a lot of custom development. Meticular prefixes in terrible programs.
What we need more of is basically templates. When I'm looking at SAP guides for Fiori and UI5 development, I keep thinking: why can't we have the same nice guides for classic ABAP? Well, it's kind of rhetorical question because we all know why: SAP moved on to new shiny toys and ABAP was left behind. SAP might be like "why are you still using old-timey ABAP, LOL, you should use RAP/CAP". Every ABAPer knows how disconnected this is from reality. We still develop in ECC systems that don't have 7.4 or 7.5.
There have been some community effort on GitHub to share just that: templates of typical simple reports. But there are very few of them and in many cases the developers are still left to their own devices. We say that ABAPers need to move from procedural to OOP development but I don't think ABAPers were given good support to do that efficiently.
Like you said, no one wants to read long PDFs. I'd add then I don't even want to read a long book or take a long course (it's nice to have such luxury but it's just not always possible). Give me a good ABAP template I can copy and adopt easily to my use case and now we're talking.
It is sad that developer guidelines are the way they are, and not the way Jelena suggests.
It is sad that there are arguments for development guidelines to include "basic stuff" to compensate for the fact that not all ABAP developers know, bother or understand the "basic stuff".
It is sad that these arguments are actually valid.
It is sad that there seem to be so many developers that are not passionate about what they do and the systems and businesses then work in.
In the perfect world, ABAP developers would be passionate professionals always doing the best they can and have the best intentions for the code, the maintainability of the code, and for the core business of the system where their code is implemented.
Just like any professional need to stay up to date with evolving standards and practices, so should ABAP developers. It may be a stupid analogy but my car is a electric/diesel plug-in hybrid. When I need service for it, I take in to the shop and expect them to know what to do with it. I expect the professionals there to do what needs to be done in the best way for my car. If there is something wrong with the diesel engine, I expect them not to try fix it with a carburetor because that's the way they have always worked with engines. And I shouldn't need to put that in a guideline to give them along with my car.
Now, the worlds is not perfect, and people are people. It's perfectly fine for people to just have development as a job and not as a passion of course. There wouldn't be enough of us if we only allowed the passionate professionals. Maybe the guidelines DO need to include what should be "basic developer knowledge" for these individuals, but does that help? Is in enforced? Is it reviewed? Is it being taught and mentored?
I have no source, but "they say" that the number of developers in the world doubles every 5 years. That means that half of all developers in the world have less than 5 years of experience. Regardless of the exact numbers and what adjustment need to be done for ABAP in particular, the majority of developers are inexperienced. Guiding, training and mentoring should be a priority. If the new developers are learning to program "the old way", then there will be fewer and fewer of us doing it "the new way"... How do we fix that, so we can fix our development guidelines?
Thank you for the thoughtful comment, Jörgen! I'm glad you picked up on the overall developer skilling and upskilling theme. And you are right to point out that "Emperor has no clothes": we need to openly admit that too many ABAP developers simply enter the profession either untrained or trained using bad/old practices. Even worse, too many just keep drifting with the same knowledge for years. I believe most of these developers still can be helped. But I also believe some should be leaving the profession if they find themselves unable to change how they create programs.
As you said, it's perfectly fine to not be super-passionate about development. It can be just a job. But that's a thing: that job still needs to meet some basic quality requirements. And the problem is that quite a few developers (empowered by quite a few managers) still believe that basic quality standard is "my code does what it's supposed to do". But that's not enough. It was never enough and it's even more so these days when we work on smaller APIs rather than jumbo reports.
One of the specific issues here is lack of verifiable credentials for developers. Professions like electrician or plumber require licensing. Development has always been one of those open fields where anyone can apply themselves. I think it's great and I hope we don't lose this advantage. Also SAP certification comes with a lot of issues, such as cost and developers using "dumps" to answer multiple-choice questions without having any real knowledge. So I don't have an easy answer to that, unfortunately. But something needs to happen.
Well, this is the story for the whole another blog, if not a book. 🙂
Perhaps oddly but I have yet to find a customer having such guidelines, however dated they may be.
True, I pull helpdesk duties across many different customers but oftentimes we're in the loop regarding procedures, security, naming conventions and the like. Not one peep on coding style or anything close. Zilch. Nada.
Makes me wonder if this is a country-specific issue, indeed.
Preach sister, preach!
Mostly, ABAP guidelines are a lengthy outdated nonsense document which nobody cares much.
We've been using this "new approach" on ABAP guidelines for a couple of years now. Our guidelines documents reusable code (to avoid reinventing the wheel), performance tips, small bits and pieces of best practices with links to external documentation and books. No extensive naming conventions! Everything enforced by ATC standard and custom rules.
Advice: if one's company wants to enforce naming convention, the ABAP guidelines is not the place for that. Just use ATC to enforce it. But to be honest, prefixing stuff with LV_ LT_ and the likes doesn't guarantee a meaningful name. One should probably spend his/her energy in performance and security rather than wasting time on how to name variables.
People say "why do I need to learn this new hype stuff? My 10y old code works just fine". William Shakespeare's English works just fine and you don't see people speaking like that on the streets. Everything evolves and so should you and your code. Think about an S4HANA project using only FOR ALL ENTRIES and internal tables with work areas...
PS: how could you forget to mention the CHANGE HISTORY HEADER LOG in all ABAP programs?!? This is the biggest BS in all ABAP history and it's still used everywhere
Amen to that. How would I like to have that. We could reduce our guidelines even further. Sadly there are some "But"s:
As to "working code": Well there are people that would really love to use Shakespeare english nowadays if they were able to. And there are people that have absolutely no interest in change at all. Just think of some people just shy of retirement.To achieve even minimum change you have to force them. And ATC is not enough because the ATC findings are only accepted because the guidelines say so.
Talking about change history header log: Tell that the auditors. Noone wants them but them. And they don't have to read the code. Our should I write SEARCH the code (after change history header log)?
For the auditors, I feel you might need the same conversation as I had about dead code. Only version control can show the exact changes. Comments and logs are not the reliable audit items.
Funny story. At certain company, I found the header change logs all over the place using the misspelled word "amendments" (I think it had double "m"). I mean if you feel like you're a Founding Father of Constitution or something, at least check your spelling.
No one dared to correct the typo for 10+ years.
Funny you mention that, ALL the programs in my project have the label "Descritpion" in the header and everyone just copies it over. Just shows that no one reads that stuff.
I loathe program headers with passion, but have had no luck eliminating them from my current project. Unfortunately I'm not the lead in this one and leads are resisting changes a lot, cause "that's the way it has always been done".
Thanks for the blog!
Made me think of my "ABAP campfire" horror story: https://blogs.sap.com/2020/07/13/abap-restrictions-keep-it-to-72-characters-really/ 🙂
(als also it's sequel https://blogs.sap.com/2020/07/13/maxing-out-on-available-characters-maybe-not-when-providing-enhancement-options-72/ )
LOL. Thanks for the comment, Joachim! Added a link to your blog to the post. Imagine someone running S5 in Cloud in the year of 2100 running into this. 🙂
Update in 2022: DSAG moved the guidelines document, so the link has been updated. Please send any future inquiries about that document directly to DSAG. 🙂 https://twitter.com/_DSAG
This is the blog that I hope will eventually become obsolete. These are the tools that should be used to maintain good code quality.
I'm not a huge fan of the actual pair programming but I find it very beneficial to show the code to other developers and discuss it with them. I like "code share" (tm) as a non-intimidating name for this process.
Go write some ABAP and good luck!