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 [1] 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 IDEs 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/

bll 2016-1-20: Just put 'syntax off' in your .vimrc (I hate the bizarre colors these editors use). Of course you could make your own syntax file to adjust for what you want.

---

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 procs like above do not need an explicit return
• longer procs 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

---