Author Archives: Jeanne Boyarsky

null checking in the extreme

Posted on by
17

In Java, we’re told to check for nulls to avoid unexpected null pointer exceptions.  This can be taken too far though.  Consider the following code:

StringBuilder builder = new StringBuilder():
if ( builder != null ) {
builder.append("data");
}

When did builder have the opportunity to become null? By definition, a constructor creates an object. We just called the constructor. We know builder isn’t null. Having extra code around just invites confusion. It leaves the reader of the code wondering if they are misunderstanding something. Worse , it is a form of dead code. The if statement will never be false so it serves no purpose.

When universities teach programming, they often leave out the parts about how to make code readable and easy to maintain for others. Whether that “other” is yourself in six months or someone else, it is still professional to make the code easy to maintain.

The extra null check certainly isn’t anywhere near the worst example of unmaintainable code I’ve seen. I’ll blog more examples of this in the future.

how to view source code generated by dojo

Posted on by
2

Dojo abstracts alot from you when creating widgets.  So how do you see the real source?  The source is important when testing certain types of requirements.  Accessibility is one of those requirements.

Normal code

As an example, I wrote a simple line of code to display a Dojo widget for currency.

<input type="text" id="amount" name="amt" dojoType="dijit.form.CurrencyTextBox" constraints="{fractional:true}" currency="USD" invalidMessage="Invalid amount format." />

When I do a simple “view source”, I see exactly what I have here.  However, I’m interested in the source code the browser is rendering.  I installed the Firefox Web Developer extension to find out.  It was a simple as going to my web page and clicking view source –> view generated source.  The result is at the bottom of this post as it’s a bit long.  [I’m curious what other/better ways there are of seeing the source.  Feel free to add a comment if you have one.]

This is really interesting.  A few things jump out at me:

  1. Dojo takes care of quite a bit a code for us!
  2. Dojo creates a Dojo input element that does all the work and wraps a hidden input element representing what I actually wrote.  This lets me use the name I specified in my own code while letting Dojo add everything it needs.
  3. IBM did a good job adding accessibility support to Dojo.

Error messages

I was also interested in what was generated when validation pops up that you did something wrong.  I was able to use the same steps – enter an invalid amount, tab out and then view source –> view generated source.  Dojo generated a single exra div for that.  It also generated the ARIA/WAI alert roles so a screenreader knows the validation has popped up.

<div role="alert" class="dijitTooltipContainer dijitTooltipContents"
dojoattachpoint="containerNode" wairole="alert">Invalid amount format.</div>

The following is what gets generated for the one line input tag:

<div widgetid="amount" value="NaN" role="presentation" class="dijit dijitReset dijitInlineTable dijitLeft dijitTextBox" id="widget_amount" dojoattachevent="onmouseenter:_onMouse,onmouseleave:_onMouse,onmousedown:_onMouse" wairole="presentation">
<div style="overflow: hidden;">
<div class="dijitReset dijitValidationIcon"><br></div>
<div class="dijitReset dijitValidationIconText">?</div>
<div class="dijitReset dijitInputField">
<input aria-invalid="false" aria-valuenow="NaN" value="" tabindex="0" id="amount" class="dijitReset"       dojoattachpoint="textbox,focusNode"
dojoattachevent="onfocus:_update,onkeyup:_onkeyup,onblur:_onMouse,onkeypress:_onKeyPress"
autocomplete="off" type="text">
<input name="amt" style="display: none;" value="" type="text">
</div>
</div>
</div>
</div>

“code sense”

Posted on by
Reply

“Clean Code” by Robert C Martin uses the phrase “code sense” when describing a developer’s relationship with clean code.  I like this phrase.  It represents the intuition that goes with looking at code.

He writes about how most people can identify messy code.  The problem comes in how to make it better.  This “code sense” lets people “see options” and “chose the best variation.”  This whole passage comes from a section subtitled “The Art of Clean Code?”.

I find it particularly interesting the comparison to art.  Especially because art is part talent and part learned.  The talent part comes from having the ideas and certain skills.  The learned part helps one know what tools are available.  A painter learns about the types of paint available.  A developer learns about refactorings.  These are all tools in the toolbox.  You still need a human to figure out when and where to use them.

—-

This week, we are hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum.  Come on in, ask him a question or join the discussion.  You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.