Guidelines for Parser Cooperation

FORTPY: Parser Functionality

Although the parsers in Fortpy have been built to deal with lots of different coding styles, there a couple of things you might do that limit the effectiveness of the parsers. When the parsers deal with unexpected code forms, you may find that their analysis of your code is incomplete and certain methods or user-defined types are missing.

Adhering to the following guidelines will improve the quality of Fortpy's tools.

Suggested Coding Best Practices

• Add Names to End Tokens: when you declare a type, function or subroutine, add the name to end token for the code element. For example, instead of writing end subroutine, write end subroutine some_method. This requirement greatly simplifies the parsing of embedded types and executables (i.e. when you declare a subroutine inside of a subroutine, or a type inside of a subroutine).
• Don't use !! in Comments: the XML Documentation Standard in Fortpy uses !! to specify the start of a documentation string. Since the docstrings are interpreted as XML, if you use !! at the start of a regular comment, Fortpy will attempt to parse that line as XML, which generates warnings and slows down the parsers.

Add XML Documentation "on-the-go"

The greatest productivity boost for Fortpy comes from the real-time intellisense support. Although Fortpy will still give context-specific suggestions, a lack of XML documentation means that parameters won't be described and code elements with poor or ambiguous names will still slow productivity. It is most useful to write the XML documentation for a type or method as soon as you have typed its signature, before you actually write any code inside. Getting in the habit of doing that will ensure that you always have well documented real-time coding support. It also clearly defines what the code element is supposed to achieve before you get caught up in the details. This usually supports creation of modular code etc. because it forces you to write words describing what the code does before you actually create the code.

Take a look at the XML Documentation Standard for more detailed tips on quickly creating the XML docstrings.

Unsupported Constructs

The following constructs don't get parsed at the moment. They may be supported in the future.

• interfaces: since the individual methods that accept the different types need to be tested individually, testing the interface comes down to whether the compiler gets it right. It may be worthwhile to parse them out later for isense support.
• operators: just didn't get round to it. Custom operators are included seldomly and there were other more pressing features.