Hacker News Reader

Comment by Namrog84 | Hacker News Reader

I used a simpler analogy in a c++ class I used to teach.

Some people might argue that setting a variable to 0 or something is pointless if you now your about to use it. But while technically it could add overhead. The chance of bugs forming from a future refactor is decreased. And those who track down sporadic uninitialized value bugs should know why it's almost always better to just initialize values. And not implicitly always trust the compiler will catch complain and or a future less knowledged developer won't accidentally do something silly.

Many habits in programming are formed from habits and we're told to not do thibgs(1 entry and 1 exit. No goto. Etc..) but few can back it up with why and when it might be a worthy edge case

View on HN

Way back when I went for an interview. That was when Java started to get popular. The interview involved some coding, and I set a variable to 0 at declaration. The interviewer asked me why I did that. I said I know the language already initialized it to 0 but I like to clearly document the init state of the variable so others can have an easier time to understand. He said others should have known the language well enough to know the initial state of a variable. We went back and forth for a few minutes on the importance of code reading and code efficiency. At the end I realized I didn't want to work with people who were so pedantic on minute detail of a language. I later declined the offer, not that it was a good offer anyway.

I dislike that for another reason: It prevents the compiler from telling you that you're using an undefined value. Just setting vars to 0 doesn't mean that that's the right value.

There's a worse problem, which I've seen in the wild:

    int some_function(...);

    int some_other_function(...)
    {
       int r = -1;
       /* imagine a bunch of other locals defined here */

       r = some_function(...);
       if (-1 == r)
       {
           return -1;
       }
      
       ...
    }

Now imagine someone changes the return type of some_function():

    char *some_function(...);

    int some_other_function(...)
    {
       int r = -1;
       /* imagine a bunch of other locals defined here */
       char *s;

       s = some_function(...);
       if (-1 == r)
       {
           return -1;
       }
      
       ...
    }

Oops! Every other reference to r has been removed except the declaration and the test. Now some_other_function() will always take the early exit, and because r is initialized in its definition the compiler does not complain. (In real life, hilarity ensued.) If it was 'int r;' with no initializer this would have been caught by the compiler.

Modern gcc is great at finding uninitialized and unused variables. -Wall -Wextra -Werror FTW.

EDIT: referred to some_function() where it should have been some_other_function().

I'm pretty sure static analysis like Clang would warn you about such a thing too... So maybe proficient programmers just need to keep their linters and tools up to date! ;-)

A competent programmer knows variables should be initialized. A proficient programmer always checks if they are when changing code.

In C++ you're right. The value isn't predefined unless you calloc. In java there are default values. I.e. for an int it's 0 and a string it's an empty string. There is even a Checkstyle violation for this style choice.

Or in Swift, you either initialize a variable with a value or have to define it as an optional, in which case you are eventually forced to deal with its possible null state. But I digress

Reply on news.ycombinator.com