hints

Some hints and style tips:

• Use a high-priority trigger on yourself to prevent loops. Say I want to throw a tomato at anyone who says the word "tomato", and I write the following trigger:

    /def -t"*tomato*" tomato = :throws a tomato at %1.
  

  If Ben uses the word tomato, I will trigger, and then see the text "Hawkeye throws a tomato at Ben." That text contains the word tomato, which will trigger me again, creating an infinite loop. One way to prevent this is by creating a high-priority trigger on myself which does nothing:

    /def -p99999 -t"{Hawkeye|You}*" anti_loop
  

  Now, when I see "Hawkeye throws a tomato at Ben", the /anti_loop trigger will catch it before /tomato does, so I won't loop.

• Use multiple lines, spacing, and indentation in /load files. Normally, commands must be on one line. But in files read with /load, if a line ends in '\', the following line will have leading whitespace stripped and the two lines will be joined. This makes it much easier (for humans) to read complex macros. Compare the two identical macros below, and see which is easier to read.

    /def count=/let i=1%;/while (i<=%1) say %i%;/let i=$[i+1]%;/done
  

    /def count = \
        /let i=1%; \
        /while ( i <= %1 ) \
  	  say %i%; \
  	  /let i=$[i + 1]%; \
        /done
  

• Use comments in /load files. Complicated macros are much easier to read if you include a short comment describing the arguments to the macro and what it does. Lines beginning with ';' or '#' are comments, and are ignored during /load.

• Name all triggers and hooks. If you ever need to /load a file a second time, triggers, hilites, hooks, and gags without names may be duplicated. But if they are named, old copies of macros will be replaced with new copies of macros with the same name. Naming macros also makes them easier to manipulate with commands like /list and /undef.

• Don't use "weird" characters in macro names. Although any macro name is legal, some characters can have unwanted expansion effects. Weird characters are also harder to read. You should stick to letters, numbers, and '_' characters. In particular, avoid '~' characters, since they are used in library macros.

• Use local variables instead of global variables if possible. This avoids conflicts when two macros use a variable with the same name. If you're using a variable in an expression, use /let first to initialize the variable in the local scope. But remember, when you use a variable reference (by name, as opposed to a variable substitution using "%"), TF uses dynamic scoping (see: scope).

• Use variable references instead of %-substitutions in expressions. Because macro bodies are expanded, something like "/test %1" is prone to problems if %1 contains any special characters. But by using a variable reference you can avoid this problem; for example, "/test {1}".

• "/set pedantic=on" to make tf generate warnings about some potential problems.

• "/set mecho=on" to see what commands are being executed, or /connect to a "connectionless socket" to see what you're sending to the socket.

• "/set emulation=debug" and "telopt=on" to see exactly what the socket is sending to tf.

• Use the -n or -l option of /trigger to see a list of trigger macros that would match a given line.