Documentation of technical objects is very important, but not always available, reliable or up to date. The one thing that a developer always has, is the actual coding itself. Whatever "the others" have build before you, any developer will point out things that should be done in a better way. Developments hold a sense of developer personality, which is exactly why developing is what it is. The source scanner can be a helping hand.

So what if you are asked to apply some changes to a development that holds 34 thousand lines of coding which has been around for 8.5 years and has 24 developers that "worked it" before ? It happened to me, it can happen to you.

Abap coding in numbers

The source code scanner effectively does the following:

1. The scanner report is started with the name of a main report or module pool
2. The includes of the report are "resolved"
3. The source is "scanned", for which the SCAN statement is used
   • Main events are listed, such as routines, modules, methods, classes and the report events
   • Global variables and local variables are listed and counted
   • Direct table updates (INSERT, UPDATE, MODIFY and DELETE) are counted and listed. Standard SAP tables are counted as well (and there shouldn't be any)
   • Exits are listed. An exit is effectively a call to other programs, through SUBMIT or CALL TRANSACTION
4. The results are listed in an ALV report, with a reference to the original location (INCLUDE or main report module pool)

The output is an ALV listing of report/modulepool relevant items, which projects a clear overview of the state of affairs with your coding. Mind you - the code inspector or extended program checker that SAP delivers standard should be used if you need to find out what state your coding is in. It's the first step to take, and this report would be the 5th step. When the code inspector states there are 241 unused variables, you will need to know how many variables are in the sourcecode to get a good assessment of the situation.

Source code in ALV report

The source code scanner is effectively an ALV report that shows the "subjects of interest" for your report (or the one you are potentially overhauling). ALV has filters, sort options, and it also has a "value=1" column that allows counting results. Have a play around. Create and store filter settings and monitor your overhaul progress by visiting the source code scanner report from time to time.

This is what a more serious overhaul candidate looked like...

Note the column Type, which can hold the following values

• DATA for data definitions, parameters, select-options and local data definitions
• TABLE ACTIONS for table update actions such as insert, update, modify and delete. Also import and export as well as commit work and rollback work are considered table actions
• SKELETON for the bone-structure of the report, it houses main events, forms, (screen) modules, classes and methods
• EXIT for the ways the report may have to call other reports or (function) modules.

Note that for each Type there can be multiple Level values - to narrow down what you want to focus on.

.

• Prev
• Next