Constant Random Change

You know the drill.

Learn a new language to complement your programming skills.

It would be a typical New Year’s resolution for developers to learn a new programming language this year. But seriously, what’s the point of learning C# when you’re a Java developer (or vice versa)?

What you should be striving for are programming languages that are orthogonal to your current skill set. If you’re an enterprise developer used to statically typed OO programming languages, try dynamic languages like Python and Ruby. If you’re already using dynamic languages, try your hands on functional programming like Erlang and Scala. Same goes for platforms: web developers might want try programming in RIAs.

The point here isn’t to add bullet points to your resume, but to have different ways of looking at problems, like adding new tools to a toolbox. For example, had I not been aware of the basics of functional programming, I might have tried to force traditional Java-like synchronization techniques in my Google Wave gadgets instead of the more elegant FP approach.

—

Just a short plugging:

Rapid Development’s Classic Mistakes (in software development) was a real eye-opener for me when I read it four years ago. Even though it was written almost a decade ago, a lot of the mistakes listed there were still present in my company.

To keep the list up to date, Construx (Steve McConnell’s company) is now holding the Classic Mistakes survey for 2010. Help update the study by taking the survey here.

Code Comments: novice programmers either use too much or too little, while so called “experienced programmers” don’t even know where they should be placed.

Actually, the proper use of code comments is one of the issues in software engineering with the least amount of debate. Overall, there are only two rules of thumb to keep in mind when using code comments.

–

Comments should explain the why instead of the how or what.

In other words, your comments should not repeat what the code is saying. Code Complete uses these two examples:

//set product to base
product = base;

//loop from 2 to "num"
for ( int i = 2; i <= num; i++ ) {
    //multiply "base" by "product"
    product = product * base;
}
System.out.println( "Product = " + product );

//compute the square root of Num using the Newton-Raphson approximation
r = num / 2;
while ( abs( r - (num/r) ) > TOLERANCE ) {
    r = 0.5 * ( r + (num/r) );
}

System.out.println( "r = " + r );

Both code snippets don’t look good (i.e. the variable names are bad). However, only the latter’s comments are useful, and the former would be better off with no comments at all.

–

If the code is so complicated that it needs to be explained, it’s nearly always better to improve the code than it is to add comments.

There are many ways to do this, ranging from using more descriptive variable names to inserting white space when needed. My personal favorite is to extract methods.

...

//get user input
...

//process user input
...

//format and display output
...

In this case, the programmer crammed all of the logic into one function. This usually happens when the developer reached his state of “flow” and just keeps on typing hundreds of lines of code into the system. The problem with functions longer than a couple of dozen lines is that not only is it hard to read, it’s also hard to debug.

By extracting the logic of the comments, we can have clearer code without even using comments, not to mention an easier to debug program:

public void run() {

	getUserInput(); 

	processUserInput();

	displayOutput();

}

private void getUserInput() {

	...

}

private void processUserInput() {

	...

}

private void displayOutput() {

	...

}

–

And yes, this is post is a lame excuse for trying out the SyntaxHighlighter plugin.

As a guy with over a decade of programming experience and a good mathematical background, I occasionally want to throw all the other aspects of software engineering out of the window and just program stuff. Here are two sites I visit to get my quick programming fix.

Continue reading »

Copy and paste is a design error.
-David Parnas

Once a developer groks this quote, he/she has already achieved another level of understanding software development.

Continue reading »