5 ms·

unused variable is the warning that causes me the most pain it happens so often that I want to test or debug something, disable some code, or replace some valu

unused variable is the warning that causes me the most pain it happens so often that I want to test or debug something, disable some code, or replace some value by "5" or what not as a placeholder, and then get the unused variable warning sure, it can be fixed with (void) casts, but sometimes there are multiple unused variables due to commenting out part of code, then you have to hunt all of them and sure it can be fixed with a flag to disable this warning, but that may require a recompile of everything if the build system considers this a change of compiler flags and sure you could disable it always, or only for certain modes, but the warning also has its merits

marcosdumay 6y ago
Are you compiling with -Werror or something like that? Because most people have no problem with warnings appearing while they modify their code.
throwaway43234 6y ago
Or just ignore warnings if you know they're from a temporary change that wont ever be committed?
- quicklime 6y ago
  Some teams turn on the switch in their compiler or linter that turns warnings into errors. Not many people invoke their compilers directly anymore, so disabling this requires digging into the build system configuration, which is not always simple (and as the OP mentioned, can require a full rebuild). Sometimes this is even baked into the language itself. For example Go can be strict about unused imports and variables. Python is strict about having correct indentation.
  - marcosdumay 6y ago
    > Some teams turn on the switch in their compiler or linter that turns warnings into errors. That's completely self-inflicted. I really don't get why people do that instead of just fixing the warnings... except if one is in some position of power over environment configuration, but not over work results. Even then, why does that person care about work results?
    - a_t48 6y ago
      In my experience the warnings tend to pile up. Once you have a few warnings in the codebase, what's a few more?
      - throwaway43234 6y ago
        I think a good compromise is warnings aren't allowed in the final committed code (this can be enforced either by convention or with git hooks), but whatever you do locally is between you and your compiler. "What happens in the devbox stays in the devbox"
        a_t48 6y ago
        I'd tend to agree, though this can be harder to set up than just having a consistent build config for all platforms.
        saagarjha 6y ago
        Generally I would hope that your CI build allows you to set this kind of configuration. (At the very least, you must have this as an option, because someone will run into it at some point and will have to turn your -Werror off.)
    - beojan 6y ago
      In large bodies of code, you might not notice the warnings if they weren't errors.
      - kazinator 6y ago
        Code size can have something to do with it, but less than you think. Basically, you don't notice warnings because you choose not to look. Firstly, no matter how large the program is, if it builds without warnings and then a change is introduced which triggers a warning, it will be noticed. You only don't notice a new, potentially important warning when it is drowned out by "nuisance" warnings that you stopped caring about months or years ago. This tends to be a problem in larger programs worked on by many people, but it could easily affect a small, solo-effort program as well. You perhaps don't notice warnings because the build log is too long to read, and you haven't put in CI process which scans logs for warnings and produces feedback. When you build locally, you don't bother using an IDE which picks up all the errors and warnings out of the build output an lets you navigate through them. This can be a problem when people don't build locally; they just throw the code into some remote build system and if it goes "green", they "ship it".
  - throwaway43234 6y ago
    Right - I understand all that, I just think it's not a good idea. The compiler makers made some things warnings and others errors for a reason, to disregard their input because you have some idea that "warnings are just as bad as errors and should never be permitted in even dev builds of my very highly precious code" is to me a sign of an over-controlling "principle engineer" somewhere behind the scenes that doesn't trust their team, which is not a work environment I'd want to be in. (In the go case, the over-controlling principle engineers creating a work environment I'm not interested in participating in are the language designers themselves!) I introduce unused variables all the time when I'm debugging/exploring, which always get cleaned up before commit (this is programmatically enforced, which I think is reasonable), to need to go and comment out the declarations for each variable that goes unused if I comment out a section, just because some "principle engineer" somewhere on my team (or the language design team) thinks unused variables are the devil reincarnate and can't be allowed in any build whatsoever is frankly insane. (Don't even get me started on cases where commenting out the declarations changes behavior...)
  - deleted 6y ago
    [deleted]
  - jart 6y ago
    > Some teams turn on the switch in their compiler or linter that turns warnings into errors. Don't bend over backwards. Just laugh at them. Losers always whine about how dare you trigger muh unused parameter.
    - saagarjha 6y ago
      While perhaps satisfying, the issue is that this usually does little good in that the person you are directing this at will rarely change their ways in response.
      - jart 6y ago
        So you change your ways I bet, to accommodate the stubborn cargo cultists who cause toil for you. Here's an alternative for you to consider. Say yes, I can absolutely support you, but if you believe that cc is an ada linter, then you can't use the project in 'preferred form' you have to link against the finished .so / .a binaries, and include the ANSI C89 preprocessed header file amalgamation, which will enable you to use whatever compiler flags you want, but you won't get the benefit of all the fancy macro optimizations and such.
nyanpasu64 6y ago
for (auto foo : list) assert(foo); The problem is that the assert() macro disappears in release mode, causing foo to trigger an unused variable warning. You need to (void)foo; as well. On a related note, since assert() is removed in release mode, assert(fn_with_side_effects()) will fail to run the function in release mode. You need to separate it into two lines.
- syrrim 6y ago
  Should probably #define assert(x) to be ((void)x) for release builds instead.
  - saagarjha 6y ago
    Make sure to #undef assert before this, and then set NDEBUG and include assert.h again.
saagarjha 6y ago
Go is awful about this, because it will refuse to compile your code if you have an unused import.
FabHK 6y ago
Question: Does the compiler still throw the warning about "x and y unused" when, instead of replacing z = x + 2*y + 1; by z = 5; // x + 2*y + 1; you do something like z = (x + 2*y + 1) * 0 + 5;

marcosdumay 6y ago

Are you compiling with -Werror or something like that? Because most people have no problem with warnings appearing while they modify their code.

throwaway43234 6y ago

Or just ignore warnings if you know they're from a temporary change that wont ever be committed?

quicklime 6y ago
Some teams turn on the switch in their compiler or linter that turns warnings into errors. Not many people invoke their compilers directly anymore, so disabling this requires digging into the build system configuration, which is not always simple (and as the OP mentioned, can require a full rebuild). Sometimes this is even baked into the language itself. For example Go can be strict about unused imports and variables. Python is strict about having correct indentation.
- marcosdumay 6y ago
  > Some teams turn on the switch in their compiler or linter that turns warnings into errors. That's completely self-inflicted. I really don't get why people do that instead of just fixing the warnings... except if one is in some position of power over environment configuration, but not over work results. Even then, why does that person care about work results?
  - a_t48 6y ago
    In my experience the warnings tend to pile up. Once you have a few warnings in the codebase, what's a few more?
    - throwaway43234 6y ago
      I think a good compromise is warnings aren't allowed in the final committed code (this can be enforced either by convention or with git hooks), but whatever you do locally is between you and your compiler. "What happens in the devbox stays in the devbox"
      - a_t48 6y ago
        I'd tend to agree, though this can be harder to set up than just having a consistent build config for all platforms.
        saagarjha 6y ago
        Generally I would hope that your CI build allows you to set this kind of configuration. (At the very least, you must have this as an option, because someone will run into it at some point and will have to turn your -Werror off.)
  - beojan 6y ago
    In large bodies of code, you might not notice the warnings if they weren't errors.
    - kazinator 6y ago
      Code size can have something to do with it, but less than you think. Basically, you don't notice warnings because you choose not to look. Firstly, no matter how large the program is, if it builds without warnings and then a change is introduced which triggers a warning, it will be noticed. You only don't notice a new, potentially important warning when it is drowned out by "nuisance" warnings that you stopped caring about months or years ago. This tends to be a problem in larger programs worked on by many people, but it could easily affect a small, solo-effort program as well. You perhaps don't notice warnings because the build log is too long to read, and you haven't put in CI process which scans logs for warnings and produces feedback. When you build locally, you don't bother using an IDE which picks up all the errors and warnings out of the build output an lets you navigate through them. This can be a problem when people don't build locally; they just throw the code into some remote build system and if it goes "green", they "ship it".
- throwaway43234 6y ago
  Right - I understand all that, I just think it's not a good idea. The compiler makers made some things warnings and others errors for a reason, to disregard their input because you have some idea that "warnings are just as bad as errors and should never be permitted in even dev builds of my very highly precious code" is to me a sign of an over-controlling "principle engineer" somewhere behind the scenes that doesn't trust their team, which is not a work environment I'd want to be in. (In the go case, the over-controlling principle engineers creating a work environment I'm not interested in participating in are the language designers themselves!) I introduce unused variables all the time when I'm debugging/exploring, which always get cleaned up before commit (this is programmatically enforced, which I think is reasonable), to need to go and comment out the declarations for each variable that goes unused if I comment out a section, just because some "principle engineer" somewhere on my team (or the language design team) thinks unused variables are the devil reincarnate and can't be allowed in any build whatsoever is frankly insane. (Don't even get me started on cases where commenting out the declarations changes behavior...)
- deleted 6y ago
  [deleted]
- jart 6y ago
  > Some teams turn on the switch in their compiler or linter that turns warnings into errors. Don't bend over backwards. Just laugh at them. Losers always whine about how dare you trigger muh unused parameter.
  - saagarjha 6y ago
    While perhaps satisfying, the issue is that this usually does little good in that the person you are directing this at will rarely change their ways in response.
    - jart 6y ago
      So you change your ways I bet, to accommodate the stubborn cargo cultists who cause toil for you. Here's an alternative for you to consider. Say yes, I can absolutely support you, but if you believe that cc is an ada linter, then you can't use the project in 'preferred form' you have to link against the finished .so / .a binaries, and include the ANSI C89 preprocessed header file amalgamation, which will enable you to use whatever compiler flags you want, but you won't get the benefit of all the fancy macro optimizations and such.

nyanpasu64 6y ago

for (auto foo : list) assert(foo); The problem is that the assert() macro disappears in release mode, causing foo to trigger an unused variable warning. You need to (void)foo; as well. On a related note, since assert() is removed in release mode, assert(fn_with_side_effects()) will fail to run the function in release mode. You need to separate it into two lines.

syrrim 6y ago
Should probably #define assert(x) to be ((void)x) for release builds instead.
- saagarjha 6y ago
  Make sure to #undef assert before this, and then set NDEBUG and include assert.h again.

saagarjha 6y ago

Go is awful about this, because it will refuse to compile your code if you have an unused import.

FabHK 6y ago

Question: Does the compiler still throw the warning about "x and y unused" when, instead of replacing z = x + 2*y + 1; by z = 5; // x + 2*y + 1; you do something like z = (x + 2*y + 1) * 0 + 5;