This Time Self-Hosted
dark mode light mode Search

Good reasons to mix declarations and code: unused variables

As I expect a lot of people not being convinced by what I wrote yesterday about mixing declarations and code, here comes a simple example of where my style works better than the “classic” style of not mixing them:

#include 
#include 

char* oldstyle(const char *foo) {
  size_t foolen;

  if ( foo == NULL )
    return NULL;

  foolen = strlen(foo);

  return strdup(foo);
}

char* newstyle(const char *foo) {
  if ( foo == NULL )
    return NULL;

  const size_t foolen = strlen(foo);

  return strdup(foo);
}

(note: I should really try to find a better way to post code, possibly with syntax highlighting, if anybody knows something, please let me know).

In both these functions the foolen variable is unused, but if you compile this with gcc -Wextra -Wunused, it will only warn you about the one on line 19, that is, the one that is mixed in the code.

This is because foolen is being used at least once in the first function, to assign a value.

Now of course gcc is smart enough to know this and indeed the call to strlen() is not emitted already with -O1 on both functions, but you’ll still have it in the code. I’d suppose it would be a bug that GCC doesn’t warn you in the first case, but I should ask Mike or Mark about that.

Borland sorry, Codegear’s compiler does actually warn you for this style with something alike to “variable assigned a value never used” (I don’t remember the exact wording here). Which is quite nice because it also catches the cases where a variable is declared with an initialisation, but then is set within both branches of an if statement. Not much of a difference for basic types but it can find useless call in the thing. I think Visual C# compiler also does that, for attributes too which is quite more interesting, but there are more considerations about that I suppose.

I wonder how many of these problems are there in the source code of xine-lib and xine-ui, I’m afraid a lot more than currently gcc reports.

Comments 5
  1. I personally prefer the second style as it makes it clearer what the type of the variable is when you actually assign something to it (no need to look back). Note that this is basically the C++ approach used by Stroustrup in his book.Main drawback that I still see is that if you want to change the type of a variable (double to extended for example) you have to go through all the code to spot every variable for which that change is relevant.ps) Note that Kernighan & Ritchie states: “all variables must be declared before use, usually at the beginning of the function before any executable statements”. So not a necessity, just a recommendation.

  2. Something you could think about is constant data. (I assume you know this but still). When working with pointers your pointer can be const and ofcource the data. I often find when going trough code that (sometimes) people to use const for vars. But do not use const on data. Which can result in quite a speed up.When it comes to optimalisation it is good to know that the use of malloc should be kept to a minium. Ofcourse sometimes you have to. But if you can use the stack. Compilers can do much more magic on stack variables than on heap.I thank you for thinking about this stuff. And also about useing it (since I use xine this can only have a positive effect). So keep up the good work!

  3. Thanks Matt, that seems to work pretty well, and it wasn’t difficult to add to Typo at all :)rob, that is written in PHP, so it wouldn’t have worked anyway :/By the way I should probably see to upgrade typo. And maybe let it use dev-ruby/rubypants instead of an internal copy of it…

Leave a Reply to Matt MCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.