The problem with spaghetti coding is that it was build as proper development which turned into spaghetti with time. This article helps recognize the state of a (any) development...
The spaghetti test is a simple and straightforward manner which can help you identify the state of a development quickly. Please be aware that only a few common symptoms are checked (by you), an automated check is also available on your system: the code inspector (version 4.7+). Especially the "visual" checks will tell you more about the development (spaghetti) state:
Following these steps can clarify the state of affairs, but is can also work as a guide to the steps through an overhaul of the coding. Don't worry about overhauls: software is upgraded all the time and the overhaul is effectively an upgrade. There is an article on The overhaul as well.
| 1. | Run the code inspector or program check and focus on the following: - are there many unused variables ? Unused variables can indicate that the development has changed or the developer has experimented to get to a result. An unused variable poses no threat other than occupying a minimum amount of space and making the source code look more complicated for no reason at all. - any unused routines ? Like variables, routines can remain from experiments or copied coding. - the overall result of the code inspector should yield no errors, however when errors are listed this does not imply spaghetti coding, it merely implies the code inspector was not used. |
| 2. | Can a program skeleton (still) be recognized ? This is a tricky one for larger developments. Normally every program has a selection screen, initialization, database selection and then whatever comes next. This skeleton will normally be quite clear when the development was first implemented, and it will become more vague every time a spaghetti fix has been applied. A clear sign of skeleton damage is selecting data after all other data was selected. The developer needed more information to be processed, he/she finds the spot where the information is needed and selects the data right there. |
| 3. | Do the names of routines still reflect what the routines do ?The name of a routine is thought up when the routine is first created and often enough never changes. When applying quick fixes the routines named "fetch_data" will end up updating tables. Check a few routines and see if the name still covers the load. |
| 4. | Logic protection in place ? When a quick fix is applied it should only be applied in certain cases. Applying a quick fix often means working on a development without having the whole overview of what the development does. Thus quick fixes are often protected by checks to ensure they are applied only to cover the required case. This way the developer does not need to think about impact as it is limited to the very request. Protection logic (the checks that are done to ensure a quick fix is executed only when required) can be found (albeit not with ease). |
| 5. | Coding that seems "out of place" ? Check version management and compare transports with each other. They will show exactly the changes that were done, or in fact the additions that were done. Quick fixes are more often than not additions to the coding. The quick fix developer tries to find a place to put in the fix with minimum amount of impact and thus minimum amount of coding and preferably all coding is grouped together. Quick fixes are often additions only - no existing coding will be removed. To the semi-trained eye this will look like "out of place" coding. |
| 6. | Are there tables which are selected on more than once ?The quick fix developer may need a little extra information from a table that was already in the program's selection. Thus a second select statement could be added to fetch the additional bit of info. |
| 7. | Repeating logic Can you find logic e.g. a routine that looks remarkably similar to logic in other routines ? Is a BAPI call performed several times ? Through poor choice of what to put into a form routine and not addressing this poor choice, a program can grow exponentially. Spaghetti coding is the type of coding where keeping things simple was never the focus. It's very easy to copy a routine and change 2 lines in it to make it do something specific. |
Conclusion spaghetti coding is not hard - it's keeping things sweet and simple that is a challenge for the developer.