[aricb] Too often I find that when I write Tk code to do anything non-trivial, I end up with a sprawling disaster that is a pain to modify or even understand six months later.  As I'm sure other programmers have encountered this problem, I searched for some guidelines on the Wiki and on the web.  I'll share what I found below.  However, I came to the conclusion that much more could (and should) be said on this topic.

Here's what I've found so far (please add to this list):

Tom Tromey's style guide [http://cafe.colorado.edu/~tromey/tcl-style-guide.html] has an excellent section on Tk.  By contrast, Ray Johnson's [Tcl style guide] [http://www.tcl.tk/doc/styleGuide.pdf], which has become the de facto standard for Tcl, doesn't address Tk specifically.

A handful of wiki pages address this topic:

   * [Design patterns in Tcl]
   * [Writing Tk programs so that the user can do simple custimizations without modifying the application]
   * [Writing Tk programs so that the user can extend or interact with them without modifying the application]

   * [Tips for writing quality software]

----
Here's what little I currently do to make my code more readable.  Please share any reactions to these:

   * In all but the most trivial scripts, I create new toplevels instead of using .

   * I try to combine geometry management with widget creation when possible, i.e.

 grid [text .mytoplevel.text] -row 0 -column 0

However, when I have to specify lots of options for the widget and/or the geometry manager, I end up with long lines which IMHO look bad even if I break them up with backslashes.

   * I try to break things up into small procs, where (for example) one proc will create a frame and its children and another proc will create bindings for those widgets.

----
Please contribute any principles that help you write Tk code in a more readable, manageable, and/or reusable way.

----
[Category Design] | [Category Concept] | [Category GUI]