[Javascript] Object reference usage (was Javascript and FF)

[Paul Novitski]

At 8/31/2009 11:54 AM, Mike Dougherty wrote:

>I also learned to code defensively and do preemptive checking for
>errors because earlier languages didn't give much choice, you either
>tested for bad input or you faced ugly run-time problems.  However,
>consider how much extra code your example required to test every step
>down the path.  To some, that extra verbosity isn't exactly readable.


For me it doesn't seem like any more work to code that precisely, it 
just seems like the amount of work it takes to code well. I'm lazy 
enough that I generally try to do things as efficiently as I can. 
Typing (or, more often, copying & modifying) if-tests takes me less 
time than debugging.

If I were very confident of the markup and didn't require much fine 
granularity of error reporting, I might code my previous example like this:
_______________________

var oHeader = document.getElementById('header');
    if (oHeader)
    {
       var aParas = oHeader.getElementsByTagName('p');
          if (aParas.length > 1)
          {
             var oContent = aParas[1].firstChild;
                if (oContent)
                {
                   var sContent = oContent.nodeValue;
                }
          }
    }
_______________________

That's a lot more concise, and it still leaves room for those 
error-handling statements to be inserted as else{} at the bottom of 
the nest. In real-world scripting, however, a deeply-nested structure 
like this might evidence itself as nested functions if it were part 
of a loop over many children, or might be avoided altogether by more 
strategic placement of ids & classes farther down the ancestral trail.

Skipping logical steps because they're too verbose is like omitting 
the fire escape on a building because it would adversely affect the 
architectural lines. I would say, a) get over it, and b) build a more 
beautiful fire escape! but don't leave your tenants to burn.


>How do you feel about the approach: assume success but handle failure?  ex:
>try{
>   var var sContent =
>document.getElementById('header').getElementsByTagName('p')[1].firstChild.nodeValue
>}
>catch(err){ alert("Something unexpected happened - developer
>assumption failure") }

I can't see any objection to coding like that, other than a visceral 
reaction that it feels inelegant. I don't know how expensive the 
try/catch structure is on the low level but, to make me eat my own 
words, if it does the job well then its low-level impact is of lesser 
concern. If that were my code I think I'd focus try/catch on one or 
two specific elements that I thought were dubious.


>The user is probably not interested in all the ways the assignment
>could fail, they only need to know that it did.

That's right, and I don't generally throw alerts at users when 
there's some sort of internal structural mismatch.


>Under normal
>conditions there is no need to do all the preemptive checking because
>the script was written for a known DOM structure.

Famous last words! If we could trust the markup we'd rarely need to 
test any of it. In dynamic, server-side-generated pages, in 
multiple-coder situations, and even in large sites that I code 
myself, I don't like to make too many assumptions about the markup 
because Things Always Change. Obviously markup and script are holding 
hands with interleaved fingers, but on those occasions when I have to 
change the markup significantly and the script keeps on working well 
with little or no modification I feel a little thrill of vindication.

It's my sense that this isn't just about trusting the markup. A 
script that's really light on its feet and that can handle missing 
elements intelligently is also easy to cannibalize and repurpose. But 
maybe that kind of ease of use depends very heavily on what scripting 
styles we're each accustomed to.

Another habit of mine that feels related to node-by-node drilling is 
that I never use document.write() and innerHTML because they 
encourage obfuscation of the document structure, are completely 
permissive of structural flaws, and promote the combining of 
structure with content in lines of code, something that gives me the 
heebie-jeebies. By relying entirely on DOM methods to read and write 
the document, I feel that I have much less proofreading to do, run 
much less risk of Death By Typo, and end up with what looks to me 
like beautiful code.

When I first entered the temp job market last century I tested at 78 
words a minute with no mistakes -- typing with two fingers. My first 
attempts to shift to touch-typing (which I knew how to do but had 
been too impatient to get comfortable with) were disastrous, not 
because touch-typing is less accurate or efficient but because I'd 
been pecking like crazy since I was a kid. Independent of any other 
judgement as to the wisdom of my technique, I could get the job done 
now, quickly and cleanly.

I teach JavaScript using DOM methods, adding write() and innerHTML() 
as postscripts primarily so that my students can make sense of legacy 
code. But if someone tells me they don't need to use DOM methods 
because they can write huge cemented slabs of HTML & text fragments 
with no problem, I'm not going to argue with them (TOO long). Hey, 
maybe they can make it work. Maybe separation of development layers 
is for wimps like I am. Maybe my compulsion to invest page structure 
with all the atomic intelligence I can give it is just my ADD 
talking. But it's how I work best, my scripts work and rarely fail 
once I've finished with them, and they're easy as pie for me to modify.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com