an ordinary blog — andr3.net

For the past week i've been busy with two projects – actually, more, but never mind. One of them, for PSD (Programming in Distributed Systems, 4th year), was building a system on top of Apache using a CGI written in C which was making Remote Procedure Calls (RPC) to a server on some other machine. On top of that, we had to make HTML form verifications in Javascript before sending any data to Apache. Sweet.

The other one, is not completed yet but it's moving along nicely. It's for the subject VIS (Visualization, 4th year), and we have to build a 3D representation of a college building (C2 @ FCUL) using Microstation (similar to AutoCAD, but way worse).

Needless to say that the for the PSD one i was in charge of – among other things – writing the javascript part. We ended up with a very robust form, which was being verified as the user filled it in, giving instant feedback to the user. One of the fields, the e-mail address, had to be checked whether it existed on the database or not, so for that i used a little AJAX magic. It was the first time i used it in a school project, and since this verification bit will also be evaluated, i'm waiting to see what the teacher has to say about it. ;)

Anyway, that's not why i'm making this post. During the coding of the RPC client (CGI) i was faced with a personal challenge.

If you're a programmer, you have probably been told the same as i was.

(Some) Golden Rules to write good code

• Basic's goto and labels are a bad system. Makes your code unreadable.
• Don't use breaks too often. (I only use them inside switch/case clauses.) Use stop conditions instead.
• Have only one return point per function.

There are (much) more, but since it was the last one that made me write this post in the first place, the others will just serve as an example.

#1
I heard the first rule very early, when I was starting programming in the 10th grade, around 1997. If you've read a piece of Basic code you'll know what i'm talking about. It's confusing as hell when your program is jumping up and down the code, specially to others. (This applies to every language that has goto statements.) This is quite unanimous.

#2
The second, however, is more controversial. I've had this debate with a lot of people and there are some who agree and some who don't.
Up until now i was never forced to use a break statement – expect, of course, for switch/case clauses. For example, when fetching an element from arrays, you might want to bail out after finding the one you're looking for, right? Right, but you don't have to use a break to bail out of a for.

// Yes, this is Java. 

// Array list: [1,2,3,4,5,6,7,8,9,10]

int target = 5;

boolean found = false;

for( int i=0;i < list.length && !found;i++)

    if( list[i] == target ) {

        System.out.println("Found.");

        break; found = true;

    }

This piece of Java code will search the array until it founds what he's looking for. No break needed. Plus, it will leave the index of the wanted element in the variable i, if found == true, that is. ;)
When you read that, don't you know immediately the whole set of stoppage conditions? Instead of having to read the whole code inside the for you just have to read one line.

#3
Finally, the culprit of this post.
I've always been a bit anal about this. Even if there are more than one return point in the function, i usually store the result in a variable and return it at the bottom of the function. That is, up until a few days ago.

I started looking at this with other eyes when my colleagues were using several returns in a function and explained me why. They were using return not only to return a value but also to control the flux within the function. Because after that, no line would get executed. Then i said But, i can use if clauses to do that... and immediatelly realize that using return i would accomplish exactly the same thing but simplifying my code a lot. Now i'm left wondering why i didn't realize this before. Weird.

So there, i'm convinced. I'm striking the last rule off my book. And how about you, programmers? What Golden Rules do you live by? There's a lot more out there and some are more language-specific than others...