Chad Perrin: SOB

25 May 2006

In Convenience

Filed under: Metalog — apotheon @ 08:37

I just composed about 95% of what would have been a lengthy post about fascism, socialism, a book called The Gulag Archipelago by Aleksandr Solzhenitsyn, intellectual property law, and sociopolitical systems in general. It was probably in the range of 1500 words of text before I accidentally middle-clicked to paste some text just about three pixels too far to the left, causing Firefox to try to navigate to a webpage by way of the text I’d pasted. The composition interface for WordPress apparently doesn’t allow the browser to cache text that is being entered, unfortunately, so the “back” button did not recover all that text.

It’s gone.

I might take another whack at writing it, later, or I might not. For now, the motivation went up in smoke with the loss of all that damned work. Suffice to say I swore a lot.

22 May 2006

In Pursuit of Grok: Multiple Returns

Filed under: Cognition,Geek — apotheon @ 04:07

There’s a rule of thumb that is peddled in some (many?) circles of programming that goes a little something like this:

No function should have more than one return.

I’m not sure I understand why that’s an effective rule of thumb. As far as I am aware, this rule of thumb was invented during the “structured programming” revolution, when it was generally decided that program design should be “structured”, long before the “object oriented programming” revolution came into its own.

As I said in Signs You’re Doing Something Wrong (Part One), I tend to follow rules of thumb as much as reasonably possible unless and until I fully grok them. Usually, such “rules” should not be strictly observed at all times — they are just good guidelines that, from time to time, definitely need to be ignored. In many cases, however, it takes an expert to know when and how to ignore them without screwing the pooch. If I don’t fully understand the reasoning behind a given rule of thumb, I figure I don’t know when or how it should be ignored, and as such I try to avoid ignoring it.

Of course, there’s a difference between failing to fully understand something and failing to see any value in it at all whatsoever. For many people, much of the time, utterly failing to see any value in something is a sign that the people in question are clueless idjits who aren’t able to reason their collective way out of a paper bag with a flamethrower in hand. I make an honest, diligent effort to understand things, however, in a reasoned manner — and as such, when I utterly fail to see any value in something even after scrupulously seeking out the value in it, I tend to guess it’s actually pretty valueless. Thus, once in a while, I come across something that someone would like me to believe is a good rule of thumb — but it is, in fact, nothing of the sort. It’s very, very rare for that to occur, however, and there is always some clear indication of why such a failure of reasoning came about in the first place that explains its existence.

I’ve been digging around for some indicators of the value of the rule of thumb stating that no function should have more than one return. I had some vague ideas all along for why that might be valuable sometimes, but not enough to know why it would be valuable often enough to serve as a rule of thumb. As such, I figured I should try to follow it (but not sweat it too much if/when I fail to do so).

Recently, I came up with the following notions as a result of some reasearch and thought (research being the act of searching for, and reading, discussions on the subject online):

  • The abjuration against multiple returns in a function may have originated with C programmers who released resources at the ends of functions. Subsequent additions of returns earlier in the function would have resulted in memory leaks. In many languages created since then (Perl comes to mind, as do Python, Ruby, and even Visual Basic) where it almost takes a conscious, concerted effort to create a resource leak, this isn’t really relevant.
  • A possible problem with multiple returns is that such practice creates an implicit else conditional structure — one that is “invisible” rather than explicit and easily recognized. In very short functions, this isn’t such a problem because the way the return affects the structure of the code is obvious, but in longer functions readability may potentially begin to suffer. There’s nothing to prevent using an explicit if/else control structure with your multiple returns, though, and this explanation for the objection seems weak and inconstant.
  • Use of a single variable, local only to the current function, that is passed to the return statement at the end of the function provides a more searchable decision path. Maybe.

Ultimately, however, I think the answer for which I’m searching might involve a reversal of the statement itself. It’s true that some of the above point at logical origins for such a rule of thumb that explain it, and some even apply somewhat to the present state of programming rather than being merely obsolete artifacts of a “distant” past, but none of them are compelling enough to really serve as justification for a still relevant rule of thumb as far as I can see. By reversing the causality of the statement in its phrasing, however, I arrive at something that looks at least initially relevant and true as a rule of thumb:

Each return statement should have its own function.

In practice, this would essentially manifest as an exhortation to examine a function (or subroutine, or method, or blah) with multiple return statements to determine whether they in fact indicate a need to turn the function into several functions.

What am I missing? Is there more to it than that? This, at last, strikes me as sufficient understanding of the concept to be able to make intelligent, educated decisions about when and how to use multiple return statements. Are there other components of understanding that I’m missing?

21 May 2006

Signs You’re Doing Something Wrong (Part One)

Filed under: Cognition,Geek — apotheon @ 03:47

This may not always be about programming, but it is mostly aimed that way right now, with Part One. There’ll probably be a Part Two before long.

There are a lot of programmers out there who just don’t know that they suck. Maybe this will help illuminate them a bit.

  1. Arbitrary Limits: When you create a system, you set limits. That’s a given. Systems require bounds and definitions so that they can operate with them and upon things that fit within them — and in the case of programming, those things are data. If your system’s limits are set arbitrarily, however, chances are good that you’ve screwed up somewhere. This applies not only to the system’s design itself, but also to the way you go about designing it. If you use an arbitrary number to limit the length of functions/subroutines and methods for instance (such as applying the common assertion that functions shouldn’t be more than twenty lines of code), you’re missing the point: rules of thumb are guides to good practice, but not hard and fast rules, and the real expert knows when to violate them.
  2. Productivity Metrics: Anything a corporate middle-manager uses to measure your productivity is more likely to be a sign you’re doing something wrong than a sign you’re doing something right. I still occasionally see job postings for programmers that indicate you should be able to produce foo number of lines of code per day, when productivity should be measured by the solid application functionality that is created rather than how many lines of code generated that may or may not actually accomplish anything. As EW Dijkstra put it, “if we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.” It’s not a universal truth that you should always “spend” as few lines as possible to achieve functionality, but it’s close enough to serve as a beneficial counter-principle to that which assumes a programmer that generates more lines of code is necessarily better. All else being equal, use fewer lines of code to achieve your ends — to measure productivity by lines of code is a pretty good sign you’re screwing up.
  3. Buzzword Compliance: If you require the use of buzzwords to describe the benefits of what you’ve done, something has gone seriously awry. If you’re a programmer, ask yourself this: Do you require terms like “enterprise”, “object orientation”, and “resource management” to describe the value of your work? Buzzword compliance might indicate that you can make an awful lot of money from your work, but it is close enough to irrelevant when measuring the quality of that work that it’s best to ensure that, when thinking about it away from the pressures of clients and bosses, you measure that quality entirely without the use of buzzwords at all.

When someone’s a beginner, it’s usually a good idea to stick to rules of thumb pretty much religiously, of course. That means that those arbitrary limits should be adhered to as much as you can manage. The reason, of course, is that most people before they become experts at something enough to know why these rules of thumb exist, and when they should be violated, would just screw things up if they tried to get creative. That’s why I, for one, try to avoid violating rules of thumb like the one about only having a single return from a function/subroutine or method: I seem to lack a true grokking of the reasoning behind it to the extent that I can violate that rule of thumb and be sure it’s a good idea.

I’m too lazy to do more today, so I’ll call Part One done.

« Newer PostsOlder Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License