Style Tips 

This is a collection of GuiXT programming style tips. Generally speaking, good programming tradition (see e.g. Brian Kernighan's Programming Style Tips) applies to the writing of GuiXT Scripts and InputScripts as well.  GuiXT is not meant  to be a full programming language with all its capabilities and its complexity. Nonetheless, since GuiXT scripts and InputScripts deal with complex user interfaces (the SAP transactions) it is a good idea to avoid sloppiness with the scripts. It's not just a question of aesthetics! Completely unreadable code might work very well at first, but later on down the line it will boomerang back, producing much more sweat than you saved initially.

The following recommendations reflect our personal style. Please feel free to send us your own opinions and additional hints. We will incorporate them into this collection if appropriate.

Topic Date /
Examples /
Link to comments
1 Apply the style guide rules during script development Do not wait until the end of the project for cleaning up your scripts. Doing it right from the outset
  • will save you time during development
  • will allow you to find simpler solutions, since you stay in control of the code
  • will facilitate communication with others 

And it will also avoid a situation where the project ends before you have found the time to polish up your scripts.


Last update: July 4, 2004
2 Keep the scripts self-documenting This does not mean putting comments on each and every statement. On the contrary, the code itself should be understandable and self-explanatory without comments wherever possible. For example the line

del F[Distribution list number]

does not need the comment "Delete  Distribution list number". But in cases involving technical names 

del F[S004-DLISN]

it is reasonable to add the comment. And in cases involving absolute coordinates (avoid them if possible), it is a must to add a comment:

del #[12,74]   // Delete  Distribution list number

Often it makes sense to add a comment about why we are doing something. This typically precedes a block of code:

// Delete the fields that we moved to the main screen
del [Distribution list number]
del [Business are code]
del [Distribution list number]

// Disable input for critical fields if user is not authorized
if not Q[Role=SALES012]
   NoInput  [Amount]
   NoInput [Price]
endif

In this way you can structure your script, grouping related statements together. Put a blank line before each logical group, but only one line.

Last update: July 4, 2004
3 Use consistent and reasonable indentation This applies to a sequence of similar statements and to  if/endif statements. Example:

// Additional text input fields in case of order change 
if Q[Transaction=VA02]  
  InputField (11,1) "Proc. instruction"  (11,30)  name="VA02_text_proc"       size=40
  InputField (12,1) "Special shipment"   (12,30)  name="VA02_text_specship"   size=40
endif 

Last update: July 4, 2004
4 Define appropriate settings for development / test / production
  • Define the script directories that you use for development/test/production
  • Do you want to use a version control system, or just copy your scripts to appropriately named folders from time to time? Think about using a comparison tool that can show you what you have changed between different versions  
  • Define the general procedure of how to test the scripts (perhaps with a limited user group) and of how to go back to the old script version if necessary. Avoid "quick fix" changes in productive systems
  • Define an appropriate header for the scripts, e.g. consisting of: file name, purpose, creation date, author, change dates, change authors, change comments

Last update: July 4, 2004
5 Apply a consistent and descriptive naming scheme for your variables A variable that is used only locally within a range of a few lines, like a line index, can have a short name like V[i]. All other variables should have meaningful names.  It often makes sense to start with the transaction code  (capital letters) , an underscore, and a short descriptive name that uses upper and lower case letters:

Set V[MM01_MaterialType]     "&F[Material type]"
Set V[MM01_IndustrySector]   "&F[Industry sector]"

A different convention is to use only lower-case letters after the underscore, and to use an underscore as separator between the words:

Set V[MM01_material_type]    "&F[Material type]"
Set V[MM01_industry_sector]  "&F[Industry sector]"

Make a decision on which convention to use and then do not mix up the conventions.

When your script deals with several transactions, e.g. MM01, MM02, MM03, define a suitable group identifier (e.g. MM for material master transactions, VA for order entry, change and display):

Set V[MM_MaterialType]      "&F[Material type]"
Set V[MM_IndustrySector]    "&F[Industry sector]"

Set V[VA_Type]              "&F[Order type]"
Set V[VA_ShipTo]            "&F[Ship to]"

Be extremely careful with the naming of internal status variables. A coding like

if V[flag=X]
  Set V[flag2] "N"
endif

is next to useless when we have to deal with the script again a year later.  Instead, 

if V[MM_MaterialCopyDone=X]
  Set V[MM_DisplayCopyButton] "N"
endif

makes our work easier. A short comment is reasonable: 

// Suppress "Copy" button later on if copy already done
if V[MM_MaterialCopyDone=X]
  Set V[MM_DisplayCopyButton] "N"
endif

Last update: July 4, 2004
6 Avoid the expression "&[xyz]"  Use "&V[xyz]" if you address a variable, and "&F[xyz]" if you address a screen field. It is then easier to understand what you are doing. In addition, a statement like

Set V[MM_MaterialType]      "&[Material type]"

will fail, if  you have already set a variable with this name before:

Set V[Material Type] "..."     

GuiXT first looks for a variable with the given name, before looking for the screen field. The naming conventions in 5 exclude such problems, but they can nonetheless crop up during script development. Unless you really enjoy endlessly searching for such errors, avoid them by using the explicit notation at all times.

Besides,  the "&F[name]" notation is faster than  "&[name]", since the variable table lookup is not required.

Last update: July 4, 2004
7 Minimize using your own status variables  It is always better to make decisions based on fields on the screen, or on transaction code, GUI status, current tab page. The fewer status variables you have, the fewer problems you have in keeping everything in sync.  If you cannot avoid using your own status variables, add some text to explains where you set and reset the variable, where it is needed and which states are possible.  

Last update: July 4, 2004