VFP 9 Hidden Gem: The Beautify Directive

VFP 9 has many major enhancements that make the justification to purchase it a no-brainer. Then there are the many little things the Fox Team threw in the product to make our development lives a little easier. The new beautify directive (note the singular) is not only one of the little things, but until recently it was one of the undocumented gems.

The Beautify feature has been in Visual FoxPro since the beginning. It cleans up code and makes it consistent. One specific function it provides is changing the case of VFP keywords. This works well in most cases and most of the time it does not matter what case the code is because VFP is a case insensitive language. However, there are exceptions when case does matter. For instance, DLL declarations can be case sensitive. If you are unaware of this issue you can break code accidentally by running the beautify feature on your code. The reality of this problem could be spending hours trying to debug code that worked fine until you went to the extra effort to make the code look consistent and meet your company’s coding standards. Not much fun.

In VFP 9 the Fox Team introduces a new directive (the case of the directive does not matter).

*# beautify keyword_nochange
*# beautify

You may notice something a little different about the beautify directive in comparison to a compiler directive. It has a comment character proceeding the “pound” or “sharp” character (#). This is required and has a nice side effect of making the code backwards compatible. What this means is you can include this new directive in any code, use VFP 9 to beautify it, and still compile the code in VFP 8 and earlier.

The directive lines bracket the code you want the beautify process to ignore. The rest of the beautify functionality (indenting comments, continuation lines, procedures and CASE statements, and converting annoying tabs to space) is still applied to the code. The only thing not applied is the casing of the keywords.

The code sample Microsoft provided is a very good example, and one of the more common ones developers could be burned by: the DLL call to ShowWindow. ShowWindow is both a common DLL Declaration and an intrinsic VFP property to specify if a form is a top-level form. If you beautify the code with the DLL Declaration it will respect your preference of upper of lower case and break the code. Here is a code example before beautification:

*# beautify keyword_nochange
PROCEDURE PleasShowWindow
LPARAMETERS tcFormName, tlDoIt
* This is a comment which could be indented or not

DO CASE
CASE PCOUNT() # 2
CASE PCOUNT() # 1
OTHERWISE
ENDCASE

if llSecurityClearance > 30
#DEFINE SW_MINIMIZE 6
DECLARE INTEGER ShowWindow IN WIN32API ;
INTEGER nHWND, ;
INTEGER nCmdShowShowWindow(_VFP.HWND, SW_MINIMIZE)
endif
endproc
*# beautify

Try it out in VFP 9 and one of the eariler versions to see the difference. This example also shows one of the drawbacks you have with this directive. You need to be careful where you place thedirective or you will find other keywords you want cased to your preference getting ignored.

This particular new feature is not documented in the released version of the VFP 9 Help file and was not included in the Hentzenwerke Publishing’s What’s New In Nine: Visual FoxPro’s Latest Hits (disclosure: I am one of the authors on this book).