Good ways to overcomplicate your code and slow down development

[Mark Wieder]

Josh-

Thursday, September 14, 2006, 1:07:20 PM, you wrote:

> Here are a few common ways I've learned to overcomplicate scripts and
> slow down software development.

<Josh no doubt learned these from me, so... flame suit on>

> 1. overhandlerize

In the general case you're probably right, and I wouldn't do this
every time I used a custom prop. But rev doesn't support private
custom props, so if you want local control over them you have to
implement get- and set- handlers. That way any other script goes
through a single point to access that custom prop and you have one
place to put in a breakpoint for debugging, etc. Otherwise the
situation can get to be as bad as using globals.

> 2. Capitalize the first letter of all your Handlers, Variables, and
> Stack, Card and Control names, etc. This will cost you hundreds of  
> keystrokes over a day's work and add to your carpal tunnel potential.

<g> u shd also limit ur variable nms to single lowercase letters and
abbrev when poss. Myb u cn gt rd f vwls...

> 3. Declare your variables
> Yes, yes, I know, this might be a religion to some, but I have

It is indeed. I won't argue with the folks who don't like to do this,
and I'm not going into the whole discussion of why variable
declaration is an *essential* part of my programming style, but I will
say that this:

allows me to see by glancing at the code whether a variable is local
to my handler or to the script

forces me to think logically about my variable use (do I need this
variable to be local to this handler or do I need to make it available
to other handlers as well?)

for that reason, makes my code more robust, scalable, and maintainable

keeps my bug count down by catching typos before they become runtime
errors

keeps me from accidentally reusing a script variable name as a local
variable name

If I'm going to use a new variable I will declare it at the proper
point. And then move on.

> If anyone else has common timewasters and app bloating techniques,
> let's hear 'em!

Comments. Don't put in comment lines - they only slow down trying to
read the actual code. Code, especially xtalk, should be readable by
itself. If your code needs comments then it isn't well written.

Josh - thanks for the well-thought-out arguments here. The fact that I
take issue with them in no way means you haven't presented them well.

<...flame suit off>

-- 
-Mark Wieder
 mwieder at ahsoftware.net