Varying the scope

I think most of the code I’ve ever seen in free software tends to follow the rule of declaring the variables for a function at the top before any line of actual code. While it’s true that it looks cleaner and that it makes it easier to find where a variable is declared and thus its type, it makes it quite more difficult to find where the variable is actually used.

In particular, considering xine’s architecture featuring humongous and convoluted functions, a variable might be declared, but not initialised, 200 lines before its first initialisation, and thus its actual first use. This is pretty bad because the variable is available for 200 lines with a non initialised value, which might be quite random.

It’s not just that though, as one problem with declaring all the variables at the top and then filling them in later makes it impossible to grep to check if the code ever puts the value returned by strlen() directly on an integer variable (which would be quite bad by its own), and disallows you from marking something constant rather than a variable.

I really like marking everything I can as constant, it makes it possible for me to assume that the data assigned to that particular name will always be there. I’ll gladly use ten different constants rather than reusing the same variable. If I have to, I put them in their own little scope till I use them and then get rid of them exiting the scope.

But there are more things that I find better to do by mixing declarations and code instead of keeping them separated. Easy enough, checking prerequisites: if a function needs to check whethere the parameters it has been given make any sense, and then start allocating a lot of objects, in variables that will never assume any other value than the pointer just allocated, I find it easier to declare them constant, checking the prerequisite before declaring them.

Quite often in xine-lib I can find strings being duplicated in the declaration of a variable, but then the prerequisites are checked and the function returns without freeing the allocated area. And marking those pointers constant often makes sure that you’re not going to change the pointer, calling free on a pointer different than the one allocated (yeah I’ve seen that today whle changing some functions around).

Reducing the scope, and thus the visibility, of variables and constants should also make the life of the compiler easier, as you’re suggesting when the variable is needed and when it ś not needed anymore. You help the compiler, and the compiler helps you not to use a variable once it isn’t valid anymore, by not allowing you to use it.

I find C99 for loops also quite interesting for the same reason, instead of having to keep the i index around for all the function, you’re using it and discarding it right away, makes it explicit for both you and the compiler what’s going on with i.

So yeah most likely most people wouldn’t like to work with me on a project I use my style on, but I’m good at adapting so if I have to hack at a software where the separated declarations and code style is used, I can easily change to apply that, but I might end up doing more scopes than the average 😉

P.S.: I got a tripod for my camera, hopefully the next set of photos I make to the flowers will be less blurred 😉