(page spawned from incr)
Martin Lemburg: I love readable code and using decr var 1 is more readable than incr var -1, or am I wrong?
RS In matters of taste, one self is mostly right, and everything else appears to be wrong;-) I think the philosophy for not introducing a decr command analog to incr was that incr <varname> -<increment> does the same job, and makes the language smaller. A smaller language may be better readable than a bloated one, because the reader can more easily have full grasp of the language. On the other hand, you extend the language everytime you write a proc... The tradeoff between personal requirements (which might lead one to write a decr proc) and simplicity (which tries to avoid too many extensions to the language, and also has to do with efficiency) has to be part of every design decision. I prefer (of course) shorter code without many extensions. When I started Tcl, I was very proud that I could create language elements like lassign, to spread a list to scalar variables, but over time I've come to think that
foreach {a b c} $list break
is readable (if one knows how to read it) and standard Tcl, while
lspread $list to a b c
(that's how my version looked) requires either reading or "intuiting" the definition of lspread, one costing time, the other possibly misunderstandings, so I don't do such things no more.
Variable names: While there is an understanding that variable names should convey some intention, it is still a matter of style whether one prefers
set fp [open $fn] ;# to set file_pointer [open $file_name] set filePointer [open $fileName] ;# or any other variant
For frequent concepts like file pointers, RS prefers short names like fp; rarer concepts are better fully spelled out.
Oh, fer crissakes. I coded decr the way I did because I have learned to use a structurally maintainable form; where error handling and output packaging can be bloated at will as necessary. I agree 100% with RS that his form is more better for, say, tcllib. And I think that 'decr foo' is easy for a brain-damaged c++ or java coder to understand, so that's why it's there. I also call the argument 'int' for the same reason that RS calls fp fp. I feel like a shmuck for feeling like I needed to explain myself.
RS: Oh come on.. we're just discussing... In C, checking and reporting errors is of course necessary. But in Tcl I only add error tests and message when I feel I can do it better than Tcl. My "unguarded" variant just runs into incr's errors:
can't read "j": no such variable expected integer but got "foo"
which I think tell it well enough ;-)
Until it's 15 levels deep in roguish dungeon of code and it comes bubbling up all unadorned from... where? And errorInfo is just too verbose. I create my own call stack by returning my own errors, i.e.:
foo: bar: baz: jimmy: decr: expected richard but got "attitude"
RS;-) A 15-level deep roguish dungeon of code probably isn't that readable either... One of my mottos is: Tcl was made to make things easy... go and do the same. I'm amazed when I read that folks write a 125k LOC app in Tcl - but I'm even more amazed when I see a half page of code that does an awful lot (and is, just by virtue of its shortness, better readable than a multi-pager). I'm tending towards a spirit of economy: use as little variables (procs, LOC) as possible to do the job. (That's why I'm also interested in functional programming, where assignments to variables is something like a cardinal sin ;-)