“In the long run, it’s a bad idea to drop the brackets and put a conditional or iterator on a single line.”

Essentially sort of thing:

public function testResults(score:Number):void
{
    if(score < MIN_PASS) sendNotification(YOU_FAIL)
    else sendNotification(YOU_PASS)
}

Should always be this:

public function testResults(score:Number):void
{
    if(value < MIN_PASS)
    {
        sendNotification(YOU_FAIL)
    }
    else
    {
        sendNotification(YOU_PASS)
    }
}

Even when writing in a language that doesn’t use brackets, i.e. so called pure block languages like Python and Visual Basic, proper formatting should be used rather than single lines. If a language does use brackets, there is no excuse not to use them.

My argument follows this logic:

“Since debugging code is 20 times harder than writing it, by that definition you won’t be smart enough to find errors in clever code.”

Single line conditionals are essentially clever ways to save line space and avoid using brackets. As such, they cause an extra level of structured complexity that can be unfamiliar and confusing in a fully realized code based.

There are a lot of coders who might disagree with this, but I have good reason for taking this approach. First of all, one line statements are dense, hard to read and uncommon enough to be awkward.

That’s not to say they don’t look great, because they do. But they are a guilty pleasure to write because they belie the complexity of the code. And as a number of seasoned professionals might tell you, readable code always super cedes pretty layout.

Certainly the instance above is a modest example, but think of what happens when these are spread freely in classes or routines a couple hundred lines long. The logic is literally packed into dense statements whose size hides the real length of the program.

The reader tricks themselves into believing that because line-for-line the statement is smaller that it is easier to read. However, in reality the layout removes all visual cues that tell a programmer they are dealing with a control structure.

To state it firmly, the number one objective of any coder should be to reduce complexity, and this does the exact opposite.

I was attracted originally attracted to the single line approach because the extra lines and brackets can be annoying. I even started using it for looping statements*. But I noticed what was happening to my code, and even my own behaviour.

Brackets in this instance act as a natural defense to the proliferation of ugly, unplanned, haphazard code. Single line statements, because the mistakenly feel concise actually encourage bad coding practices.

Conditionals are twisting logic that arrest the normal intellectual flow of a program in the writer’s mind. They are necessary to be sure, but should be used as sparingly as possible to help simply the code base.

Because single line conditionals are so easy to write, they create an easy road that is often all to tempting when the logic gets tough, and you begin to realize you’ve been writing too many conditional control structures.

My new favourite quote is Anonymous:

Code as if whoever maintains your program is a violent psychopath who knows where you live.

*Side Note: Interestingly enough, Flex or Eclipse will not provide code completion for lopping variables not included in brackets.

oculart:      hows it going with you these days
ghostmonk:  good man
ghostmonk: busy
oculart:     that’s the word on the streets isn’t it
ghostmonk: Myron and I are making this crazy ass site
oculart:     sweet, for who
ghostmonk: same one we’ve been working on for the last 8 months
ghostmonk: for this at risk women’s group in Winnipeg
ghostmonk: funded by ***
oculart:      ah cool, is an interactive story?
ghostmonk: no
ghostmonk: it’s a content site
ghostmonk: interactive story would be awesome
ghostmonk: nice idea
ghostmonk: I can show you
ghostmonk: beta.**********.com
ghostmonk: runs completely off a cms
ghostmonk: that’s why there is dummy content in there right now
ghostmonk: there is still a ton of work left to do
oculart:     alright let me check it out
oculart:      i like the resizing browser animation snap thing
ghostmonk: There’s more there than meets the eye
ghostmonk: the content is completely managed
ghostmonk: there is a back end
oculart:     do they have a lot of content they are going to be adding
ghostmonk: I guess so
oculart:     i don’t really believe in having cms for a lot of sites
oculart:     seems like a waste of programming time unless content is updated hourly
oculart:      I think it’s foolish when more resources are used on building a back end application when its just as easy to republish updated content unless it needs to be dynamic content
ghostmonk: well… depends on how long the thing will live
ghostmonk: you want to extract as much of the changing data that is possible
ghostmonk: that’s just good sense
ghostmonk: If I make more than one of these sites
ghostmonk: I don’t want to constantly republish every time content changes
ghostmonk: and as the thing moves forward, there is opportunity to add new modules, and the possibility of abstracting more business related rules
oculart:     yeah buts its also taking 8 months to make it
ghostmonk: well it is and it isn’t, the whole project is taking 8 months, not 8 months of coding time
oculart:      but will there be money for them to add extra features?
ghostmonk: let’s just say that I’m working extra hard to have a code base I can resuse
ghostmonk: so they get more functionality, but we own the code
ghostmonk: when you program sites that hard code business related rules
ghostmonk: like content
ghostmonk: you basically create throw away code
ghostmonk: or rather
ghostmonk: encourage throwaway code
ghostmonk: that’s fine for current clients
ghostmonk: may even speed up things on a client by client basis
ghostmonk: but in the long run
ghostmonk: you shoot yourself in the foot
oculart:      that’s a fair argument, but i think clients waste too much on cms work
ghostmonk: well… that’s a different argument
ghostmonk: does a client need a cms?
ghostmonk: that depends if they are publishing regularly
ghostmonk: weekly is probably a good measure
ghostmonk: If over my career I deploy 100 sites with clients that want to update even on a monthly basis
ghostmonk: I might drive myself crazy trying to maintain sites that could otherwise maintain themselves
ghostmonk: in this case… honestly
ghostmonk: I’m thinking about the code base when it’s all done
ghostmonk: and the lessons learned
oculart:     but how is building a cms like that going to be useful for future clients going more mobile
ghostmonk: well, unless flash blows up, I have a code base that is easily deploy-able in a variety of online environments
ghostmonk: I think the idea is more about the experience
ghostmonk: certainly the argument that flash sites are redundant can be made
ghostmonk: but people still want them
oculart:      i think reactive content management systems are the future
oculart:      content that reacts emotionally to people’s behavior
ghostmonk: that doesn’t even make sense
oculart:     emotional intelligence
ghostmonk: what in the hell are you talking about
ghostmonk: that’s fine when speaking about technology that is stil 50 years from common use
ghostmonk: but that’s a future beyond ours
ghostmonk: touch screens are still not main stream
ghostmonk: unless you talk about iPhones
oculart:      i think instead of managing content, we need to manage how to absorb content
ghostmonk: ok that makes a little more sense
ghostmonk: but what you are talking about is still a decade away from being mainstream
ghostmonk: no client in their right mind would budget a project that only has the potential to reach the most technically savvy of the population
ghostmonk: tech savvy and rich
ghostmonk: iPhones are a sort of exception
ghostmonk: but they are still drastically limited
ghostmonk: you are basically banking on the mainstream peripherals to be different
ghostmonk: in our generation, and probably the next
ghostmonk: you are looking at touch screens, keyboards and the mouse
ghostmonk: there are tons of other theoretical ideas and prototypes out there that are awesome
ghostmonk: but right now they are more suited to museums and installations (maybe special scenarios)
ghostmonk: not feasible to the mainstream
ghostmonk: .. the only mainstream touch screen right now is the iPhone
ghostmonk: and that doesn’t capture too much real data
ghostmonk: it certainly doesn’t replace the keyboard and mouse…. yet of course
ghostmonk: and I still can’t see how a touch screen will grab too much in the way of emotional content
ghostmonk: gestures are cool
ghostmonk: but they don’t say a hell of a lot about the emotional state of a human being
ghostmonk: unless you are adding a really representative GUI
ghostmonk: which is cool
ghostmonk: but still not mainstream
ghostmonk: anyway… I’m just trying to make software that is as flexible as possible
ghostmonk: if i have to rewrite this one day for a mobile application… at least I will have done it once… so I can do it again
ghostmonk: and i can start gathering those gestures, and building data bases that can begin to infer their meaning
ghostmonk: you still with me?
oculart:      jesus you talk a lot when i turn my head
oculart:      haha
ghostmonk: I think what i said makes sense
oculart:      man, let me read this, im multi tasking, arguing with you and working at the same time
oculart:      hold on a sec
oculart:      feel like god damn batman
oculart:      but i love arguing with you more than anything so i will for sure get too it