Tcl mantras

Purpose: to collect a variety of commonly used phrases, often referred to within the Tcl community as mantras relating to Tcl.

Everything is a string

Tcl runs everywhere.

The preference of most is that the functions in libtcl should be, as much as possible, cross platform across at least Unix-like, Windows, and to a lesser degree MacOS, VMS, etc. Platform specific functions go into extensions, with those potentially being wrapped up into the same tar file as libtcl code.

Keep Tcl small.

The Tcl philosophy is to keep libtcl relatively small and to create add on extensions to provide extended functionality

Batteries Included

Use extensions, don't bloat.

The Tcl philosophy is to EXTEND the language via extensions when specific applications need a new feature - not to create a single library containing every imaginable function that every programmer since the beginning of the computer age ever needed. Developers should work on becoming more comfortable using existing extensions or writing their own rather than expecting an all in one language.

If you want something done, TIP it.

For something to be changed in the Tcl core, be prepared to recruit a developer (or gird your loins for battle) and submit a TIP providing details of what s/he plans to do to add functionality in the core, and be prepared to discuss/debate/argue your case.

Complete patches to Tcl include tests and documentation

When submitting changes to Tcl, the minimum amount of work to be expected would be updated test cases and documentation, along with the code changes.

Error messages are your friends.

Most of Tcl's error messages are so detailed and legible that they almost serve as an online help system. If you write error messages, try to write them so that a user is almost glad to see them.

Error messages tell what; errorInfo tells context.

[More info needed here]

Only catch when you know exactly why.

[More info needed here]

Only scratch if it itches.

Don't write code just to be writing it - it is hard to solve a problem which doesn't exist yet.

Everything goes into a namespace.

When writing extensions or even applications, placing one's procs into a namespace moves towards avoidance of name conflicts.

When in doubt, assume Tcl is simple.

Cameron Laird

Expect success.

[More info here]

Code what you mean.

Don't be cute or try to guess how to get around problems. Instead, code things the way you mean them, then, if that doesn't work, decide how to get around the problems.

If you want to know what Tcl/Tk would do in a situation, fire up tclsh and type it in.

Don't sit around waiting for someone to answer a usenet, web forum, or wiki question when you can just try it out and see what will happen.

Play well with others.

[...]

It only shimmers if you watch it.

[The contributor gets himself into such a fit of laughter every time he tries to explain this that he hasn't been able to do so.]

See also The Tao of Tcl