|
|
Posted by ^reaper^ on 07/08/05 14:05
While sipping absinthe, Onideus Mad Hatter heard a loud sucking noise
coming from alt.2600,alt.html,alt.php, and hastily inscribed the following
unintelligible Sanskrit in
<news:131dc1d2jl0hqpbj320r2isfc4s2og7ls0@4ax.com>:
> I do find your aversion to variables amusing, I'd like to see Reaper
> jump in and repost some of the edits she did of my code, that'd
> probably send you frothing at the mouth in frustration. ^_^
Hehe. Since I pulled teh edits otter... erm... teh air, and your buddy
appears to have anal retentive tendencies with regard to using precise
terminology on teh juicenet? Yep, it prolly would cause him to foam at teh
mouth at teh very least. ^_~
Nonetheless, he does have a valid point wrt your use of globals and teh
eval statement. For example, globals are nasty ladle creatures that can
bite you in teh ass if you're not careful. Or put another way, best
practices uses local variables and passes in those values which need to be
shared by multiple functions. Even so, there are times when globals make
sense. It all depends upon what you're attempting to do.
As for his gripe wrt your use of the eval statement, the eval is generally
used for computing dynamic strings containing js code and completely
unnecessary for known entities. For example, there's really no reason to do
this:
drags[o].y = eval(tempY-placeY+drags[o].y);
when you could just as easily do this:
drags[o].y = tempY-placeY+drags[o].y;
and achieve teh same result. By using the eval statement, you add a layer
of processing. In this case, an unnecessary layer. In addition, it
increases the face value of teh code for later debug (e.g., years later,
scratching head, asking, wtf did I do that?). Where eval can come in handy
however are instances involving say, building dynamic complex equations on
teh fly. Or, for example, say you want to reference a document object that
contains a variable component, you can do something like this:
eval('document.all.'+name+'.style');
though, this:
document.getElementById( name ).style;
would accomplish the same thing.
That aside, mr. a.r. appears to be stuck in "never do blah" land. When
designing and implementing code, the question should not be, "what does teh
book say?" rather "what are teh tradeoffs?" And there are always tradeoffs.
And these tradeoffs are dependent upon a number of things, including, but
not limited to target audience, app requirements, chosen technology, etc.
Understanding these, as well as the underlying execution (how code is
distilled into machine lang) is what differentiates poor to mediocre
programmers from sw engineers and architects.
--
"Beware of the man who works hard to learn something, learns it, and finds
himself no wiser than before," Bokonon tells us."He is full of murderous
resentment of people who are ignorant without having come by their
ignorance the hard way." -- Kurt Vonnegut, Cat's Cradle
Navigation:
[Reply to this message]
|