QA: small name for a very relevant topic when programming (in ABAP). Assuring good quality of coding is of paramount importance. Even though it may not feel that way while coding... Quality assurance often entails adhering to naming conventions and standards, setting up report headers and making sure source code is documented well in and out of actual source code. It's quite a challenge to define (in text) what assured quality is or should be.
Truth in the matter is that every development is a thing of it's own and what is regarded as a Quality setup for a development is a useless setup for the next development.
So how can Quality be Assured ? To my opinion quality in coding all comes down to Common sense. More often than not, the compexity of a development grows when the development is done in phases, by more than one developer. Developing an add-on is an effective way to produce spagetti coding. The overall overview of the setup is very hard to keep track of when the development is done in phases. So the specification that's not quite finished yet, should really be left untouched by the developer.
[1] Clear functional specification technical issues need not be resolved in a functional specification, but required functionality should be clear before commencing with any coding. In practice this rule is often not obeyed as specs are not always clear and they are not always "written in concrete", which brings us to:
[2] Clear and modular coding set up the actual development in the simplest way possible. A good quality program is not a complex program, it's the art of keeping developments simple that really makes a developer invaluable. It's OK to assume your developments will need to be changed - at some point in time. And you may well be the person to perform those changes. Follow these simple guidelines and use them as a starting point:
- Use naming conventions on ABAP variables, it's good to see a variable is an internal table, just by seeing it's name.
- Declare your variables where they are needed. Counters used in a FORM routine should be declared and used in that same routine. Declaring a variabele as global data makes it very prominent. Global variables should only be used for global solutions.
- Think hard and well about variable names. A well-chosen name will help you and whoever follows you through your program. Name not well chosen ? Change it !
- Use parameters in FORM routines. It holds a lot of information about what the routine does. Perform something using this and that changing such and such is a lot clearer then just perform something.
- Even better: forget about FORM routines and utilize the Object Oriented approach that SAP Abap now supports
- Modular approach in selections: all table selection should be done in one "go", and once the selection has finished - no more selection should be done (ideally of course)
- Differentiate your "building blocks" in re-usable and not re-usable, make sure the re-usable stuff is set up in e.g. a function module, making it available to other developments. Visibility of your methods and the use of global and local classes are valuable tools in defining re-use.
- Comment your code - chose the level of detail of your comments and try to use the same level of detail for all comments. The moment you think "this is probably not the best way of doing this but... " make sure you add a comment line
- Lean on standard SAP when and where you can. BAPI's are golden. Building something that has already been build ? Just ask yourself why.
- Message i999(zz) where this message is set up as & & & ? YUK! Some end user will report the message number back to you some time - and you'll be wondering where to look... (where used will result in a list of all your developments).
- Use SAP tools to check your code (there's a code inspector which is used as code review tool on many projects. Your code should be code inspector error free.
- Performance tuning is never to be overlooked - don't wait until a tuning request arrives - a quality coding is performance tuned coding.
- The list of guidelines can go on and on - but really: isn't all of this common sense ?
[3] Stay on top For any development you are asked to do or change, you become the owner of the end result. Hence do not be afraid to change what is there. There is no valid reason to think that coding done by someone else should not be taken into account - the main aim should always be: "the result of my changes is a working product".
[4] Put on the end user's coat After developing your development - sit down and use it for 10 full minutes. You will do some very valuable changes after that.