This was at some point the very first issue of AbapcadabrA and it is about "Conventions in Programming" for good reason. Before getting involved in anything technical in SAP, check out these articles:
Before commencing with any development, there are several topics to consider: planning the development process, using naming conventions and the (often very general) killer complexity growers where it comes to an approach to developments. These articles are about all of that.
.. in comments. Having a good solid naming convention for your variables is a very good idea, which will help you building your coding and help the developer that needs to alter it in the future as well. Which may also be you ! A ready-to-copy comment block on naming conventions:
If you don't take some pride in your work, it probably shows - in that same work. Doesn't even matter what you do. In Abap, there's beauty prizes to be won too - even though the end customer may never get to see them. I found that the pretty printer is a nice way to produce readable coding, but it lacked a personal touch, so I've introduced the auto pimper.
What you should do and not do when implementing Conventions in programming:
- Do value your programming conventions
- Don't forget: naming conventions, quality assurance rules and development guidelines should be well thought through at the beginning of a project. They should be communicated to all involved clearly.
All developments go through the process of developing. A process which eventually needs to cover everything, but also a process which is regarded as a "work in progress" for multiple days. Even weeks. Here's a little trick I use to capture thoughts while developing a program. Very simple. Equally effective. The * HAZARD>/code> comments.
ABAP development is only required when changes are done to the SAP standard - right ? That depends: SAP can be used as turn key solution, where ABAP changes can be minimalized. Actual changes that may still be required are done in locations where SAP expects then and where SAP prepared for them. Ideally, the developer should look for those locations before starting developments. Some pointers (in a totally arbitrary sequence):
Please give the author of AbapcadabrA the chance and opportunity to explain why standard SAP should not be copied into custom developments...
Adapting a report is generally not a good thing to do. When making changes to SAP the developer should always try to find ways out or at least minimise the number of changes.
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.
The concept of re-using code is well known. But have you considered the scale on how this ever so powerful concept is applied ? Coding should be composed with re-use as a focus point. But tools which are available in standard SAP's suite of funtionality should also be in the developers visor. They too should be part of custom solutions.
Test results of a proper test is all there is between a development and a production problem. And testing is often one of those things for which no time is available. To present a state of mind about testing, consider the following:
Reading the signs: Has this ever happened on your project ? A few classic cases...
Whenever ABAP/4 developments need to be created, two questions pop up: Can it be done ? and What would it cost ?... Before these topics can be addressed, it's very important to define a basis for planning.