Proteus, just like any other programming language, requires a little attention when writing programs; many concepts common to C and Pascal are also applicable to Proteus, being a structured language.

You should insert print instructions to display the values of significative variables at a certain point, since there is no debugger to trace execution step-by-step. An easy way to obtain the list of values for all public identifiers is using the method DEBUG, which prints all the values in the three possible interpretations (string, integer number, floating point number). You can not view local variables by using this method, nor the values of the items inside data structures (queues, stacks, arrays, etc.); to verify single values, use CONSOLE or CONSOLELN.

Since you can write endless loops, you should pay attention to exit conditions and consider an "emergency exit", like the one illustrated below:

; We are not sure that the loop always ends - we decide to exit the loop after
; 10 seconds anyway
ExitTime = ADD(CLOCK(), 10)
WHILE Test
  ...
  IF GT(CLOCK(), ExitTime)
    BREAK
  FI
LOOP

A common error is using the character '\' inside strings without considering the expansion of C-like constants; for example, the following Dos path is wrong:

PathName = "C:\DOS\ATTRIB.EXE"

It is actually interpreted in this way: C:[0]DOS[10]TTRIB.EXE, where [0] and [10] are the ASCII characters 0 and 10. The right path is the following:

PathName = "C:\\DOS\\ATTRIB.EXE"

Another common error is using string comparison functions in place of numeric comparison functions; the first have in their name the prefix STR: STREQ, STRNEQ, while the second don't have any prefix: EQ, NEQ.

Logical functions sometimes are also confused with binary operations (which all have the common prefix N); the binary AND of two numbers is NAND, the logical counterpart is AND; the same holds for or, xor, not.

Side-effects (collateral effects) are often a source of troubles; for example, if you call REXMATCH inside a UDF, you should consider that the predefined identifiers R_START and R_LENGTH are also modified outside of the function.

A common mistake for people writing their first Proteus programs is adding unrequired parenthesis, like in the following example:

IF (OS)
  CONSOLELN "Operating system: Ms-Dos™ or Windows™"
FI

When the script is run, Proteus reports an error on the line beginning with IF; the parenthesis are used in Proteus only when defining or calling functions, because the order in which operations are performed is implicitly determined.
IF, WHILE, SWITCH and FOR do not require parenthesis in their conditions, as opposed to C.

Another common mistake is using SET in place of PSET inside a UDF to update a public variable, or forgetting using PUB on a public identifier inside a user defined function.

Examples.

; Error! MONTHS, being SET, is a variable local to ONSTART; 
; the public variable MONTHS remains untouched, so the function ONSTART
; does not have any effect
FUNCTION ONSTART

  MONTHS = "Gen Feb Mar Apr Mag Giu Lug Ago Set Ott Nov Dic"
RETURN 


; Error! R_START and R_LENGTH are not inside PUB; since they were not
; initialized before being referenced, they will crash the program

FUNCTION GetTag(s)

  IF REXMATCH(s, "<.*>")
    RETURN SUBSTR(s, R_START, R_LENGTH)
  FI
RETURN ""

A few suggestions:

• to momentarily remove part of the source code, use the directives !bdoc/!edoc or, if you want to cut until the end of the file, !endprog;
• when doing maths, keep in mind the rules of calculus to avoid losing precision (e.g. it is no good to execute a series of operations that halfway reduce the working data to values which are way smaller or larger than the final result, in absolute value);
• if you want to evaluate the tokens inside a string, use the static tokenizer if all tokens are needed, the dynamic tokenizer if you need only one token;
• try using simple regular expressions whenever they are sufficient to determine a match, because they are faster and (usually) easier to use;
• if you need to work with large strings, try to split them in smaller pieces to limit memory consumption;
• use SYSTEM and EXEC only when strictly necessary, especially for security reasons;
• keep the code clean and well commented, to let other people easily modify it when needed;
• always check the values returned by the functions, to determine if an error happened (especially for file operations);
• use stacks or queues in place of arrays when the items are added one at a time and it is not necessary to sort the items at the end; in other cases, use AVL trees, that allow to extract the items sorted - these data structures have a reduced overhead for inserting and extracting items and are very useful.