Purpose: to discuss the concept of ''best practices''. ---- The idea behind ''best practices'' is often to provide examples of code that show what one should do in the best (or perhaps better thought of as '''worst''') case scenarios. These examples would show proper error handling, consideration for variable naming, name space selection, package creation, etc. By providing these examples, one is in effect saying "I consider this code to be worthy of emulating in even the most critical applications". Should one code in this style all the time? I think many (most?) would state that the level of attention spent to error handling should be compared to the level of criticalness of the code. If one is writing a one time program to select some random lottery numbers, and then the code will be thrown away, then I suspect that the error handling could be less than code to be used to monitor the control hardware for a deep sea oil drilling rig... ''RS:'' Also, Tcl's default error handling is far better than your choice of SIGSEGV or "Bus Error" that you may get from an unguarded C program. Why bother catching an [[open]] if the standard error behavior (file not found) is just a clear message on stdout, or even in a Tk popup? ''DL:'' Two reasons: 1) It is often important to explain why the app was trying to open a file, particularly if it's a temp file with a completely meaningless name. So simply reporting "couldn't open /tmp/.exp38" isn't helpful. 2) Sometimes the underlying diagnostic is misleading. So I generally use an error handler that reports my best guess as to the problem along with the diagnostic that was returned by Tcl. ''DKF:'' Indeed; it is always important to make sure that any errors reported to the user are done so in a way that is relevant to them, even if it makes life a bit harder for yourself. A trick I use when writing code that uses assertions is to mark the error codes specially with some kind of ''errorCode'' setting that, when it hits my custom bgerror handler, triggers the sending off of a bug report directly to me. Like that, things that I genuinely do not expect to see get thrown in my face and other problems (like trying to open unwritable files for writing) get relegated to the black pit of oblivion that they so rightly deserve. Not all errors are created equal... ''RS'': Sure, gentlemen, I agree to both of your points. It's just for most code that I write, I am the only user... and I'm used to Tcl's standard error messages. Chimpanzee-proof software is of course very more demanding, but that's the real Best Practice... ''LV'': I'd offer another reason for writing specialized code. It may be that generating an error msg is NOT the correct action. For answer, if the user types the wrong file name, having the application stop with a message about 'file not found' isn't the most friendly solution - instead, catch it, and ask the user to try again... ---- '''Always brace expressions''' You should always surround expressions with {braces}, including expressions supplied to [expr], [for], [if], and [while] commands. Braced expressions can be compiled by the byte-code compiler, making your scripts faster, and they avoid the problems associated with [double substitution]. There is some discussion of alternative styles in [A Question of Style], but the best practice is still to brace all expressions. RS: ...except if operators are to substituted (see [expr] page, [Summing a list], [Additional math functions]). ---- '''Use [[list] to construct commands''' ---- '''Use a single [proc] handling the callback instead of multiple commands in bindings and callbacks''' You should create a proc for use in callbacks and bindings. It is faster, because procs get the benefit of byte compiling. It is safer, because you avoid going [quoting hell] in your code. It improves readability and maintainability of code. ---- [Arts and crafts of Tcl-Tk programming] - [Category Concept]