Mike Slinn

Connoisseur of Technology

Good Code is Beautiful

2008-10-15 / All Blog posts

First, I'd like to point out a few practical reasons why orderliness is important. Can you spot the bug in the following Flex code? This custom component is not as wide as expected:

<mx:TextArea  width="100" height="100%"
contextMenu="{cm}" xmlns:components="components.*"
creationComplete="init()" width="100%"
xmlns:mx="http://www.adobe.com/2006/mxml">
...
</mx:TextArea>

The bug occurs because two width attributes were provided, one with the value 100 pixels and one with the value 100%. Jamming a long list of attributes into an MXML tag in no particular order is an invitation to chaos. No error message is generated if an attribute is specified twice.

Long ago I adopted the convention of ordering all attributes in alphabetical order, one per line. I would write the above like this:

<mx:TextArea
    contextMenu="{cm}"
    creationComplete="init()"
    height="100%"
    width="100%"
    xmlns:components="components.*"
    xmlns:mx="http://www.adobe.com/2006/mxml">
...
</mx:TextArea>

Other people write certain attributes first, like id, width and height. Whatever convention you adopt, stick to it.

Here are the official ActionScript coding conventions, as published by Adobe back in 2011, prior to canceling the Flex product. I take some of it the way the characters of "Pirates of the Caribbean" consider the Pirate's Code: "Argh, it be more like a set of guidelines."

ANSI/Unix vs. Vertically Compressed Styles

I realize that this topic might make me flame-bait, but my experience has shown that the ANSI/Unix style of vertically spacing parenthesis increases the maintenance costs of a program.

Functions/methods should fit on a single screen; so should data structures. Because programs written in bygone days had to be editable on a green screen, 80 columns was the widest that a program could be written. In the 'bad old days', it was better to let a program run to more lines in order to avoid folding code. Here is an example:

private function GridContextEventHandler(event:GridContextEvent):void
{
   if (event.menuItem=='Edit')
   {
      EditGridItem(event.selectedIndex);
   }
   else if (event.menuItem=='Remove')
   {
      RemoveGridItem(event.selectedIndex);
   }
}

A vertically compressed style is much more easily read. Python initially made waves in part because code formatting enforces control structure. Python programs do not need parentheses as a result. Why not write ActionScript in the same manner, so parenthesis are virtually redundant? The Sun/Java convention is a good example of this formatting convention. The above program fragment would be written like this using a vertically compressed style:

private function GridContextEventHandler(event:GridContextEvent):void {
   if (event.menuItem=='Edit') {
      EditGridItem(event.selectedIndex);
   } else if (event.menuItem=='Remove') {
      RemoveGridItem(event.selectedIndex);
   }
}

Enforcing Style

Coding style conventions can be automatically applied by installing Flex Pretty Printer into Eclipse / Flash Builder. If you like, you can importing my formatting rules, which enforce the vertically compressed style above.

Complete Disregard for Style

Recently I examined a programming candidate's programming style. He didn't get the job. Here is how he wrote the above code:

private function GridContextEventHandler(event:GridContextEvent):void{
 if(event.menuItem=='Edit')
 EditGridItem(event.selectedIndex);
 else if(event.menuItem=='Remove')
 RemoveGridItem(event.selectedIndex);
}

The rest of his code did not work very well. Seems like from the way he wrote it that he didn't really care. No surprise that someone else got the job.


Contact Mike Slinn

Unless you are a recruiter, in which case you should not try to make contact!

  • Email
  • Direct: 514-418-0156
  • Mobile: 650-678-2285

Disclaimer

The content on this web site is provided for general information purposes only and does not constitute legal or other professional advice or an opinion of any kind. Users of this web site are advised to seek specific legal advice by contacting their own legal counsel regarding any specific legal issues. Michael Slinn does not warrant or guarantee the quality, accuracy or completeness of any information on this web site. The articles published on this web site are current as of their original date of publication, but should not be relied upon as accurate, timely or fit for any particular purpose.

Accessing or using this web site does not create a client relationship. Although your use of the web site may facilitate access to or communications with Michael Slinn via e-mail or otherwise via the web site, receipt of any such communications or transmissions does not create a client relationship. Michael Slinn does not guarantee the security or confidentiality of any communications made by e-mail or otherwise through this web site.

This web site may contain links to third party web sites. Monitoring the vast information disseminated and accessible through those links is beyond Michael Slinn's resources and he does not attempt to do so. Links are provided for convenience only and Michael Slinn does not endorse the information contained in linked web sites nor guarantee its accuracy, timeliness or fitness for a particular purpose.


comments powered by Disqus

© 1976-2020, Michael Slinn. All rights reserved.