Coding Practices at Large Companies

Software Development 5 Comments

I just had an interesting email exchange with one of my newer staff, a friend from university who worked for [insert name of company] for a number of years. Aforementioned anonymized company being a Fortune 500 company that is in the IT industry. I’ve got stuff with their logo on it in my office.

The conversation began when he asked if he could use a goto statement (in PHP code!) for error handling.

Bearing in mind that this is somebody who is extremely familiar with both Object Oriented and good coding practises, I realized that there must be an interesting story underlying this.

His response to my query for more info is informative:

Tease all you want — I’ll lean on the weight of nine years of experience at [big company name], where (gasp) gotos were ubiquitous (almost exclusively in error handling code, but still).

To clarify further: I actually wasn’t aware that PHP had a goto statement (see: php.net/goto – they have the nice xkcd cartoon in the comments). I’ve been coding in PHP for a long time.

There’s two methods that I usually use to handle errors in PHP code, in case you’re wondering:

1. Make sure that code that can crash is encapsulated in a nice neat function. Check return values of function calls inside the function. If necessary, stick an “@” before function calls that tend to crash in a messy manner. Then return useful info about the final state from the function itself, and check things out higher up in the stack.

2. Stick try/catch code around code that can crash. If necessary, subclass error classes and put in nice handlers for them.

In both cases, make sure that the error level for reporting is appropriate, and that we don’t output actual error messages back to the end user. Where useful, put in logging, and possibly put in code to email error reports back to admin.

Reblog this post [with Zemanta]

5 responses on “Coding Practices at Large Companies”

  1. Elie

    The XKCD cartoon is appropriate, and your new developer needs to learn about good program design as opposed to established program design. I’ll send over some appropriate readings if I can find them quickly – unless you’ve managed to convince him of the error of his ways and converted him to proper error handling.

    1. Jeremy Lichtman Post author

      Update:

      My friend responded as follows (slight editing):

      I’ve got no problem with it — but be prepared to get some interesting responses (not from me). In performance-intensive code (which [BIG PROJECT NAME] is), gotos are desirable. They’re a simple way to redirect processing, when used smartly (and PHP’s spec actually has some nice safeguards on goto which C doesn’t). They’re fast. And in terms of error handling, it’s a simple way to centralize error handling code (and short-circuit a whole bunch of flow control that would take extra CPU cycles otherwise).

      I’m not saying I’m going to introduce this kind of thing into our code — truthfully, I know I need to learn to work with exception handling — it was frowned upon at [BIG COMPANY NAME], but the rest of the world isn’t like that. And while performance is always important, I highly doubt this particular project (or almost any web page, really) is going to be dealing with the kinds of performance calculations that a high-end database needs to worry about.

      Just did a quick check, and there are some fascinating discussions out there on the subject of gotos: http://kerneltrap.org/node/553/2131

      1. Jeremy Lichtman Post author

        My personal response is as follows:

        1. I have little experience working on code that absolutely has to run as fast as possible. The kind of OO code that I was trained to write in university probably has little applicability in those kinds of scenarios.
        2. I once had to work on a large program from the 70’s that was written in Business Basic. Every other line was a goto, and there was no editor on the old minicomputer that the code lived on – we had to view/edit one line at a time. The very mention of “goto” brings back unpleasant memories of that.
        3. The kinds of web-based apps that I usually work on need to be maintainable more than they need to be fast. I’m not opposed to hackish code (as long as its small, obvious and documented), but I’ve never encountered a scenario where “goto” was better than if/else or select structures.
        4. The link that my friend sent (see above) has a bunch of comments from Linus Torvalds. I don’t think I want to step into a firefight between Torvalds and Niklaus Wirth. Out of my league.

  2. sol

    For everything a place.
    GOTO statements should be considered an advanced feature you turn to when you have the basics working and need to improve performance, and using a GOTO will actually make a significant difference. There might very well be cases where nothing else will work as well.

    1. Jeremy Lichtman Post author

      The way I was taught – and generally have practiced – is that if you see a big complex control structure like a nested if/else, a select/case, or a bunch of gotos, that probably means that you should have subclassed something better (hopefully in a polymorphic manner), or that you should look into refactoring your code into nice clean functions.

      But like I said above, I’ve not worked much (not in the past decade anyhow) on anything that was desperately in need of more CPU cycles in order to complete in a human timeframe. Business applications usually don’t need too much speed optimization!

      I’m somewhat fascinated by this whole thing. Its shedding some light on an aspect of programming that I don’t usually see too much of.