stick to your language

Very often I see code fragments where programmers try to be smart. Don't!

Obviously there is nothing against being smart, but don't try to be smarter than necessary.

Most of the time these smart tricks have to do with compiler optimizations.

An example:

Imagine you have a method doSomething() that only has to be performed if another method checkAndDoSomething() returns true. That method in its turn only has to be performed if switch boolDoIt is set to true. Some programmers like to take advantage of the fact that most compilers optimize the code so, that in an and operation if the first element evaluates to false, the second element isn't evaluated at all and write code like this:

if (boolDoIt and checkAndDoSomething()) {
 doSomething();
}

If you can rely on that optimization, you know that if boolDoIt evaluates to false, the checkAndDoSomething() method isn't performed, and neither will doSomething().

But what if the compiler vendor decides to drop that optimization for some reason? Then all of a sudden both elements are evaluated, so the method checkAndDoSomething() will be performed no matter the value of boolDoIt! Completely changing the behaviour of your code and violating the meaning of the switch.

A better, more stable way, would be:

if (boolDoIt) {
 if (checkAndDoSomething()) {
   doSomething();
 }
}

I know, this looks like kindergarten code and is not fancy. But the code is easy to read and compiler independent. And probably after optimization by the compiler exactly the same ;-)

In other words:
write your code and functionality using the specifications of your programming language, not of your compiler.

KISBNS

Keep It Simple, But Not Stupid!

The idioms KISS (Keep It Simple, Stupid!) and KISSALAP (Keep It Simple, Stupid, As Long As Possible) are great methods to get your code up fast and keep it stable. Surely writing code for something you'll probably never use can only make thing unnecessary complicated and therefore unstable and unmaintainable.

BUT:
I often see pieces of code where people tried to keep those principles, but forgot to refactor in time until it's too late. What I mean is, people tend to start copying pieces of code, thinking 'making this piece of code more generic while I would only use it twice is not simple enough.' Maybe that's true. But then they copy it a third time, or code it again because they forgot it allready existed somewhere.
In these cases making a generic method, class or whatever the first time would have been a better idea.

So as soon as a piece of code is obvious to reoccur several times, extract it immediately before it's too late!

scalable architecture

Very often when I join a project, I see developers performing all kinds of tricks just to stay within their architecture.

Sure, it is a good idea do determine or develop some kind of architecture when you start a project. If you don't do that after a while your software won't be readable or maintainable anymore. Developers will come and go, each bringing in their own style of doing things. But if your system evolves, it's very likely that your working architecture will not live up to its needs. Therefore don't hesitate to adjust your architecture instead of wasting time and money trying to figure out hacks to solve the problem within the current standards.

In other words: ''Scale your Architecture''

name functional

When naming objects (being it classes, methods or whatever) let the name describe what it is or does, NOT HOW!

An example:
I recently worked on a database where a column was defined by a user defined type. The naming convention used stated that the name should contain the base type used in the udt. In this case it was a tinyint, so the name of the type started with udti_. I had to change the column to a smallint because the original tinyint just couldn't cope with all the different values anymore. Normally one of the biggest advantages of user defined types is that you only have to change the type definition and you're done. In this case I had to create a new udt (just because the name had to change to udsi_) and redefine all tables, stored procedures, functions and triggers that used or referred to the original type.

Describing the inner workings of an object in it's name limits the flexibility in future development and also breaks the encapsulation rules.

Who am I?

First of all, see my profile on Linked-In:

Now that you have at least some idea who I am, I'd like to share with you my reason for starting this blog. There's nothing new about it. Just some thoughts about software development and curious stuff I've encountered while doing my work