Logo

Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.

Note, *, &&

All three of these symbols mark the beginning of a comment. NOTE and * can be used only at the beginning of a line (actually, as the first non-blank characters), while && can be used at any point in the line. Once && appears, the rest of the line is a comment.

Usage

NOTE cComment
* cComment
&& cComment

There’s one big gotcha involving comments. Like other commands, comments can be continued with a semicolon. So, in the following example:

* This is a comment;
USE MyTable

the USE is never executed. This gotcha got even more gotcha-like with the addition of syntax coloring in VFP 5. Continuations of comments aren’t colored like comments; they’re colored like code. We sure wish Microsoft would bite the bullet and get this one right.

There’s also a cool trick you can play on folks. Very few people are aware that NOTE starts a comment. Most people will be firmly convinced that the following will crash:

Note: This routine does absolutely nothing
FUNCTION DoNothing
RETURN

NOTE can be followed by non-alphabetic characters, like !@#$:, but not a letter, such as NOTES.

In certain places, you don’t need a delimiter for a comment. As part of the Xbase legacy, comments can be added on lines containing some of the looping and branching commands, including ELSE, ENDIF, and ENDDO. You’ll often see older Xbase code (or code written by those who’ve been using Xbase a long time) like this:

IF dDate>DATE()-30 
   DO something
ENDIF dDate>DATE()-30

Be aware that you can’t do this with ENDWITH—it doesn’t like extraneous characters.

Until VFP 5, you could even put comments on the IF line, in that example. As soon as something was read that couldn’t be parsed, VFP would assume it was a comment. This led to lots of code with subtle errors. To make matters worse, these items aren’t colored as comments by Visual FoxPro, making them confusing to the developer reading the code.

Omitting the comment delimiters on lines like DO CASE and ENDDO and so forth doesn’t seem to have the potential to do any harm down the road (unlike putting them on the DO WHILE or IF lines), but it just doesn’t seem like such a big deal to us to type && before the comment, so we always do.

Example

NOTE This is a comment
* So is this
USE MyTable  && Open the table