''Here's a debate on strict vs. minimal bracing style that evolved on the [Graffiti] page. I moved it here for persistence -- RS'' ---- ''Look at the [Tcl] manpage and check out the "[[...]]" syntax (JC):'' if {[file exists $FILE] == 1} { DO_WHATEVER } '''RS''': as file exists returns a truth value, you can simplify this to if [file exists $FILE] { DO_THIS } else { DO_THAT } '''DKF''': but it is usually considered to be a good idiom for various reasons (speed and robustness mainly) to enclose the condition argument to [[if]] in {braces} like so: if {[file exists $FILE]} { DO_THIS } else { DO_THAT } '''RS:''' Yes, I know of cases where the bracing influences speed, but I think [[file exists $FILE]] returns the same result in constant execution time, whether called from inside or outside expr. Without the curly braces, the if receives 1 or 0 as argument, and this wouldn't cost much parsing time either ;-) '''LH:''' Thanks y'all, I've tested it out and I can make it work. '''DKF:''' The '''if {[[file exists $FILE]]}''' form is marginally faster (but the difference in speed is negligable, given that we need to context switch out to the OS) but the main reason for using that style of idiom is that it is a good habit to get into, so you don't end up using it somewhere where it jumps up and bites you (in either performance or semantic terms.) A bit like not playing ball on railway tracks... '''RS:''' Point taken. Or... Of course it's safer to always brace. But I prefer code that looks more natural, and when I have one pair of brackets, the extra braces somehow don't look good to me. You certainly gotta know what you're doing, and it's on own risk. But still, if $done break looks better to me (and is legal, even if against the style rules ;-) than if {$done} {break} '''LH:''' I think, for my needs, the more "style-correct' version is better. We're staffed with various levels of scripters, and the more standard we make it the better. '''DKF:''' Plus, many of us use editors that can provide better context highlighting support [http://www.man.ac.uk/~zzcgudf/tcl/tcl-font.el] to style-correct code... '''LH:''' What sort of editor, (asks the [vi] user)? '''DKF:''' I don't know too much about ''nvi'' and ''elvis'', but I think that they have highlighting of some form. How good it is (does it handle detecting where likely valid places for commands to start are, given that Tcl is a keyword-less language?) I just don't care! :^) '''LH:''' Hmm.... may have to go back to [emacs] for coding. Started with vi because it's more common on different unixes ([linux] and [solaris]). Did like the bracket matching of emacs. Are there any [IDE]s that handle [scripting] like tcl? '''PSE:''' Since you guys went here, I'll throw in my 2 cents: VIM has really excellent syntax hl, brace matching, etc. for Tcl. You can even get it to do syntax hl in console mode. See http://www.vim.org [AMG] I really like vim except that I'm frequently troubled by its Tcl highlighting. See [vim] for details. '''[JCG]:''' My editor is vile (VI like EMACS), a vi clone engineered on top of micro-emacs which, IMHO, provides the best of both worlds. Look at http://www.clark.net/pub/dickey/vile/vile.html and http://www.cmc.net/~bem/vile/ ---- [AMG]: Here's another question of style: whether or not to use [[[return]]] at the end of a [proc]. The proc's return value is the return value of the last command it executed, so in many cases explicitly calling [[return]] is redundant. Compare: ====== proc add {a b} {return [expr {$a + $b}]} proc add {a b} {expr {$a + $b}} ====== I like the latter form. Now, intermixed with conditionals and such, it's sometimes unclear what the return value will be. You have to know what the return value of [[[if]]] is, in order to understand the return value of the proc. [RS] 2016-01-20: My rules of thumb are: * one-liner [proc]s like above do not need an explicit [return] * longer [proc]s shall only have one [return], at the very end * if a variable's value is to be returned, I'll "invariably" call it ''res'', so the last line often is: return $res <> Discussion | Code Style