Develop Good Coding Habits

Good coding habits are very important to the quality of the code produced as
well as to the quality of the final product which uses the code.  Nothing
earth shattering here, just learned behavior.  Some of the most important
habits I have learned are:

1. Initialize all variables to zeros.  If I declare an int I do this (int
   iValue = 0;)  if I allocate a char array I do this (char szTemp[20];
   memset(szTemp,0,20);).


2. Check the return codes of all function calls.


3. Catch all exceptions at an appropriate level and deal with them.  One
   of the bad habits I had earlier in my career was to setup an empty catch
   block and think I was going to fill it in later.


4. When defining function prototypes consider error conditions.  This
   means deciding whether to return a bool or an int (an int can return a set
   of predefined flags indicating what kind of problem occured.  A bool
   can only indicate success/failute.)  If there is additional info that a
   simple code can supply, consider passing in a string or other variable by
   reference to hold the extra error information OR consider throwing an
   exception.


5. Never pass objects by value unless ABSOLUTELY necessary.  (I can't
   think of a situation where this has ever been necessary, but there might
   be.)


6. Use GOTOs wisely.  The only place I have every used a goto (that I
   can think of) is in a lexical parser I had to write a few years ago.


7. Create more utility classes than program-specific classes.  


8. Think about how a piece of code might be used in another project and go
   ahead and develop for that.  (Don't take this to an extreme, though.)


9. Comment judiciously.  When I write code comments I try to comment on
   the architecture and purpose of a function/class instead of on the lowest
   level of details. 


10. The equality operator and the set operator are not the same DAMN@!#$#
    thing.  I can't remember how many times I have done if (x=y).  To
    avoid this I have created inline functions like FPSCompareString,
    FPSCompareInt, FPSCompareLong, FPSCompareFloat, FPSCompareDate, etc which
    have virtually eliminated this problem from my code.

I'm sure there are hundreds of other rules I could write up but that could
take whole books.  The bottom line for me is that there is no one to review
my code or help me when problems arise.  If I can eliminate the most common
problems I can spend more of my time working on the more serious problems.

programmers

web developers

designers

entrepreneurs

writers

What Every Software Project Needs to Know About Ajax

1.  The Browser Was Never Meant For Ajax.  About a week into your first Ajax serious application you'll discover that Ajax pushes the browser nearly beyond its limits and there are definite lower engineering tolerances to get used to. The fact is, without powerful 3rd party development tools, designing clean Javascript software of any size requires some genuine discipline and effort.  So too does Ajax debugging applications in multiple browsers (a real headache), and doing any serious background processing or threading can require heroic measures, particularly if you're mixing in other components that use the rather limited number of simultaneous timers available.  The good news: Simple Ajax -- sprinkling in a little DHTML -- is much less daunting than Ajax In The Large.  But be warned and be prepared to scale up your level of development and testing effort significantly with each doubling or trebling of your application size.
2. You Won't Need As Many Web Services As You Think.  I used to think that going the Ajax route required the development of a bunch of new Web services in order to feed the application data and provide a backing store.  In reality, I'm finding a great many projects are quite happy to scrape HTML and/or use plain old HTTP POSTs to existing service endpoints that have no formal Web service structure.  This is further turning the tide towards Ajax by making it very, very easy to "dip your toe" into Ajax development and reuse almost any preexisting HTTP service on the back end instead of SOAP or REST/WOA.  While this can encourage poor architectural choices, it does make very incremental conversion to Ajax almost effortless and turns out to be a natural thing to do, though it can certainly lead to headaches later.
3. Ajax Is More Involved Than Traditional Web Design and Development.  The loss of HTML user interface conventions, the almost limitless potential for hidden or latent functionality, the programmatic creation of page elements instead of declarative, and other intrinsic aspects of the Ajax approach throw out much of what we know about Web design and development.  Web designers must much more deeply understand the capabilities of the DOM, Javascript, CSS, and how the browser renders graphics, layouts, and elements.  Developers find testing both difficult and tedious.  Though tooling is continuing to improve across the board, it will take years for the industry to develop best practices, lore, patterns, and shared knowledge to make Web application development straightforward.  Huge kudos to folks like Yahoo!'s Bill Scott for trying to fix many of these problems -- particularly the loss of GUI standards -- by actually moving the state of the art considerably forward with things like the Yahoo! UI Design Patterns library.  The bottom line: Ajax development, at least for now, usually takes quite a bit longer than traditional Web development and requires a higher level of skill.
4. Ajax Tooling and Components Are Still Emerging and There Is No Clear Leader Today.  Though Dojo is getting one heck of a running start, the race is very far from over.  For instance, the Dojo framework itself is still just at version 0.3.  And close at its heels are an amazing range of tools, frameworks, and component libraries.  Though OpenAjax will make this mosaic of products play nicer, most developers will get deep experience with two or three of them and stick with them. For now, I would say deeply committing to a particular product is usually not the best idea.  Innovation, competition, and market leadership is likely going to bounce around for a while.  In the meantime, be sure to check out script.aculo.us, Prototype, Google Web Toolkit, Yahoo! UI Library, JackBe, Zapatec, Bindows, Nexaweb, General Interface, Backbase, ActiveWidgets, and last but not least Microsoft Atlas. There are many others and I encourage you to look at Max Kiesler's roundup of 50 Ajax frameworks, with many others in the comments (and growing).  Finally, Microsoft's Harry Pierson has diligently taken me to task for my Ajax spectrum comments, noting that Microsoft actually has more serious experience fostering an interoperable component community than just about anyone else.

• Good Ajax Programmers are Hard to Find.  Zimbra's Scott Dietzen has lamented recently about the real difficulty in finding good Ajax talent.  See point #3, but building sophisticated Ajax applications requires more computer science skills much more than it does Web design skills.  And I find that experienced programmers tend not to enjoy Javascript programming and debugging. This too shall pass, but not for a few years, and not for a good while in the Bay Area. :-)
• One Must Actively Address Ajax's Constraints of the Browser Model.  Though the final result can be very rewarding, Ajax is not a perfect Web development approach and it has a few genuine weaknesses.  One is that it tends to break the model of the Web including preventing users from bookmarking content, breaking the use of the Back button, and more.  Fortunately, smart folks like Brad Neuberg have addressed much of this, as long as you're willing to put out the effort and understand why it's important to recover this functionality.  Ajax also lacks much of what still makes desktop software a strong contender; the ability to run disconnected from the network and access to local disk storage, though Flash local storage and the upcoming Apollo platform can help address this.
• Ajax Is Only One Element of a Successful RIA Strategy. As I've written before, the addition of RIA platforms such as Flex, OpenLaszlo, and WPF/E to a RIA strategy is virtually required to properly exploit the range of capabilities you'll want robust online applications to have.  This is particularly true around rich media support such as audio and video -- which Ajax is virtually incapable of -- but even such mundane things as good printing support.  These are all things that the more sophisticated Flash-based RIA platforms really shine at and are easier to program in to boot.  Ajax will increasingly get a serious run for its money from these platforms, particularly as they provide back-end server support for things like server-side push, formal Web services, enterprise environments, and more.