Welcome!

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion

ColdFusion: Article

Improve Your Code Readability With Fusedoc

Improve Your Code Readability With Fusedoc

I'm writing this prior to the turn of the new year, so I trust that somehow civilization bungled through and that you're not reading this by the light of your last candle, alert to the strange sounds outside your door that are growing ever nearer.

With the new year we're introducing a monthly column dedicated to all things Fusebox. First, I want to thank all of you who attended the Fusebox session at the ColdFusion Developer's Conference in Boston. Over 300 people attended the session ­ and some were turned away for lack of room. While I'd like to attribute that to my galvanic oratorial skills, I suspect that it had more to do with how important the quest is for a methodology that works well with ColdFusion.

Why do we need a methodology? Let me reiterate a little of my presentation at the conference and draw an analogy between the state of programming today and that of rifle making 200 years ago. An odd pairing? Well, consider the similarities:

  • Skilled craftspeople are needed to create the product.
  • Each product is the unique work of its creator.
  • There's a shortage of skilled workers.
  • The quality of finished goods varies widely.
  • Maintenance of our products requires the user to go back to the creator or to employ the skills of a highly paid master craftsperson.
  • There's no ability to interchange parts from one product to another.
  • Division of labor is very limited.
  • The efficiencies of scale are few: making 10 products takes 10 times as long as making one.

    Into this highly inefficient situation stepped an American genius: Eli Whitney. Whitney had already achieved great fame (but not wealth) with his cotton gin. Assessing the situation, Whitney decided that he was just the one to solve the "rifle crisis" and proposed to the new national government that he be awarded a contract to produce 10,000 rifles at a cost of just over $13 each.

    The idea was preposterous ­ but Whitney had already proved his ability to effect miracles. Thus the largest single financial transaction in the young nation's history was agreed upon. Whitney's plan for meeting the contract was to standardize parts so they could be reused among different rifles. The rest, of course, is history. (Perhaps, however, Whitney should be the patron saint of programmers, as he delivered late on the contract.)

    Today we face a "software crisis." According to one magazine, two thirds of corporate software projects are never deployed or are declared failures. I think you'll agree those numbers are stunning. But what else could we expect with the situation outlined above?

    In other issues of CFDJ I've argued that one of the great reasons for Allaire's huge success with ColdFusion is the degree to which it masks complexity from developers, letting them get code out of the programming shop and into use. What we've lacked is a methodology that would direct our programming efforts to produce maintainable, reusable code. I believe that Fusebox goes farther along that path toward radical simplicity in our development efforts.

    If we're to get beyond the practice of "one-off" software, in which each bit of code is written one piece at a time, we need to agree on certain standards. We need to document our code with the understanding that it will be fitted into other applications and maintained by different coders many times during its life. And, as we've just recently seen with the Y2K issue, there's no telling just how long that life may be.

    This is nothing new, of course; we know documentation is good practice. Why, then, is it so rare? Perhaps we feel something like Mark Twain did when he was asked by a reporter whether there was anything he feared. Twain mulled the question over before drawling, "A blank piece of paper." It's intimidating to think we have to engage in writing a novella with every code file. What exactly should we put in it? What format should it have?

    You may already have a standard for documentation. If not, I suggest one for you to evaluate. I call this Fusedoc ­ an appropriate name as the idea was borrowed from its cousin, Java, with its Javadoc specification. Fusedoc was written to work with Fusebox, but it can be used with any code files. It's usually the first step I take when helping a new company implement Fusebox as it's easy to adopt and provides immediate benefits.

    The Fusedoc format I took out of one of my fuses is given in Listing 1. One of these goes at the top of every code file.

    Here's how to read the Fusedoc:

    <!-- actValidateUser.cfm -->

    The name of the fuse is set in an HTML comment, so if we do a "View Source" from within a browser, we can immediately tell what files are in play.

    <!--- || I make sure that the username and password given to me are valid entries in the USERS table. If they are, I will return to...

    This is the "Responsibilities" section of the Fusedoc. I write this in the first person (as if the fuse were speaking) and try to provide enough information for another person to tell immediately what's happening with the fuse. My goal is to provide enough for a CF coder, armed with a copy of the data schema, to write this fuse without any knowledge of the application in which it'll be used. The double pipe symbols (||) will be used by our "magic box" to extract individual pieces of the Fusedoc.

    || [email protected]

    You may want to keep historical information here about revisions, testing, etc.

    ||
    --> userName: a STRING
    --> password: a STRING
    --> RFA.successfulValidation: a valid FUSEACTION
    --> RFA.failedValidation: a valid FUSEACTION
    <-- [badlogin]: "yes"> <->
    ++> dsn: an APPLICATION variable ODBC datasource
    +++

    These are the various arguments being passed into and out of the fuse. There is a key to the meaning of the prefixes:

    --> an incoming parameter: the text following the prefix provides more information about the parameter
    --> [square brackets indicate that this incoming variable is optional]
    <-- an outgoing parameter
    <-- [same explanation as the square brackets above] <->

    a parameter that will be received by and sent from the fuse without being changed
    ++> a global variable not explicitly passed into the fuse, such as server, application and session variables
    +++ any file that is required by this fuse. This may include files, fusefunctions, etc.

    || FUSEDOC--->

    This just ends the Fusedoc section.

    I've found this system to be very workable; once used to it, programmers find it very helpful as it concisely communicates a good deal of information. Even pointy-haired managers and customers can look at the code and have a sense of what's going on.

    We can make it even more useful if we process this code through our "magic box" ­ a code file (fuseDocumentor.cfm) that parses the individual elements of the Fusedocs and outputs them on the screen. Fuse Documentor was written to be called as a custom tag. For parameters, it takesŠwell, let's just run the Fuse Documentor through itself to find out more about it (see Figure 1).

    If you want to see particulars on every file in a directory, you can write a little code that will loop through the directory and send each file to Fuse Documentor (see Listing 2). This will let you see very quickly what's going on in an entire code repository.

    Fusedoc is a small, lightweight system for seeing the structure of code. I've found it to be helpful in writing maintainable, reusable code. I hope you find it similarly helpful.

    You can download the Fuse Documentor file as well as a CF Studio template at www.TeamAllaire.com.

  • More Stories By Hal Helms

    Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.