1. '''Keep procedures short''' - ''Why you may ask?'' Would you rather see 200 lines of code that does X, or a command call saying do X.  If function/procedure calls you feel are too expensive, I suggest you keep in mind that machine coders used a similar argument when assemblers came around.  (Back then they thought that computer time was more expensive than programmer time, which isn't ''generally'' true nowadays.)

   2. '''Use descriptive names for variables and procedures''' -  Try to describe what you're storing rather than how it interacts with something.  Be consistent in the names you use.  If you want nTimes to mean "number of times" don't later use numTimes or nt.  Being lazy just wastes your time.  Also keep in mind that if you use variable names that are too short and use long comments to describe them you are wasting your time.  This can be taken too far and then the variable names clutter the pattern of the program.  A healthy balance between names like j and jumpPointStoresAPointerThatDoesX is needed.

   3. '''Keep a consistent pattern of object/memory management''' - Decide ahead of time if the parent of a procedure should manage a certain object, or if the child or called procedure should, and try to be consistent about how things should be managed.

   4. '''Use comments that describe how and why you are doing something''' - Some programmers may be confused by your code if the purpose is not known.  You may even confuse yourself when you come back to the code months later.

   5. '''Use comments when the pattern of what happens next may not be expected'''

   6. '''Look for patterns in your code, and minimize repeats by using proc or interp alias (see 1)''' or functions and macros in C.

   7. '''Don't make assumptions that a command or function won't return an error.''' - Check the results and catch if absolutely needed.

   8. '''Have a plan for each file before you begin coding.''' - It's all too easy to fall into the trap of staying up late coding massive amounts of code.  Often if you really think about the problem you can reduce the amount of code substantially.  By having a plan you also can work out potential problems before you invest time.  This is what separates a software '''engineer''' from a programmer.

   9. '''Use the interactive tclsh/wish shell if you aren't sure about how something will work''' - Don't assume

   1. '''Use a consistent pattern of capitalization or _ or - for classes of keywords''' - If you decide that you want all classes to be like BoxClass don't later change to ball_class type naming.  You will only confuse yourself and make it more difficult for your mind to parse your own code later on.  Obviously in the world of packages this may not be possible, but strive to keep your own code consistent.

   2. '''Don't rely on the interpreter/compiler to find bugs for you.''' - If you find yourself fixing bugs that the interpreter/compiler tells you about too often then you probably haven't planned it out well.  The same applies to execessive use of a debugger.  (See 8)

   3. '''When coding in C be careful with ==''' - Consider ''if (var = NULL)'' -- usually the intended usage was ''if (var == NULL)''.  The compiler accepts var = NULL, and you may wonder what is causing var to become NULL later on during runtime.  An easy solution is to use ''if (NULL == var)''.  This doesn't have the same problem, because the compiler will report it as an error if you try to assign a variable to ''NULL/0'' as in ''if (NULL = var)''.  Tcl/Tk could learn from this. 

'''Please append your own tips.'''