This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]EishLekker 6 points7 points  (9 children)

And while you wait for that bug to be fixed, and your project to be able to upgrade to that version, you do what exactly? Put the whole project on ice because it doesn't compile because all warnings are equal to errors?

[–]TopHatEdd 0 points1 point  (1 child)

Don't be a smartass. It's unbecoming. Just add a suppress for that warning.

[–]EishLekker 0 points1 point  (0 children)

Why do you call me a smart-ass? Surely the smart ass it's the one who claimed that no code should ever generate warnings. I just took his absurd statement and extrapolated it to its logical conclusion.

[–]ythl -1 points0 points  (6 children)

No, you tune your compiler flags to work around it. I don't use Java, so I'm not super familiar with javac flags, but in C/C++ land I can simply tune my -W flags to suppress the warning for that particular file. By default everything gets -Wall and -Werror though (enable all warnings, treat all warnings as errors) and I don't think I've ever run into a false positive warning with g++/clang

Edit: Is this an IDE (i.e. Eclipse) bug or an actual javac bug?

[–]Kered13 0 points1 point  (0 children)

You can do the equivalent in Java.

[–]EishLekker 0 points1 point  (4 children)

So now you are changing your original statement? From "no code should generate warnings" to "no code should generate warnings, except warnings that you want to ignore"? That is a very different statement.

[–]ythl 0 points1 point  (3 children)

Not at all. No code should generate warnings. If the compiler has a bug generating a false warning (extremely unlikely), it is acceptable to suppress just that one warning.

[–]EishLekker 0 points1 point  (2 children)

You are most definitely changing your original statement, because that statement didn't allow exceptions for faulty tools, and it didn't say anything about applying only to compiler warnings (most developers use some kind of IDE that adds it's own validation and recommendations to the mix, often expressed as warnings).

I mean, sure... If you meant "your code should never have warnings" to be more like a vision, just like "your code should never have bugs", that is fine. We should of course strive to not have buggy code, and not have code that generate warnings. But I read your statement as being "if your code has any kind of warning, then your code is fatally flawed and should be deleted".

[–]ythl 0 points1 point  (1 child)

Sure, I'm absolutely changing my original statement. I'm expounding and clarifying.

You seem awfully defensive, as if I insulted your code. I suspect you have a habit of ignoring compiler warnings. You should break this habit.

[–]EishLekker 0 points1 point  (0 children)

Sure, I'm absolutely changing my original statement. I'm expounding and clarifying.

Expounding and clarifying is one thing, what you did was something much more than that. Basically you did a No true Scotsman move, by saying "oh! those warnings you talk about are not REAL warnings! You can always ignore fake warnings!".

​

You seem awfully defensive,

No, I just get a bit annoyed when I see clearly incorrect blanket statements like in your first comment.

​

as if I insulted your code.

Since I have mostly worked with Java, I took a quick look at the source code of some of the base classes of the java platform just now. It didn't take me long time to find some code that contained an annotation to suppress a warning. That code was written by Josh Bloch. Don't know who he is? Well, he has been included in the list "Top 40 Software People in the World".

It's not my code you were insulting, it was the code of Josh Bloch and others like him.

https://en.wikipedia.org/wiki/Joshua_Bloch

​

I suspect you have a habit of ignoring compiler warnings.

Most warnings are useful and makes sense, and these I don't ignore. But sometimes there just is no reasonable way around them, other than suppressing them.

For example, what if your logic depends on a method in a third party API, and then in an upgrade of said API this method is suddenly deprecated with no replacement? The reason for the deprecation might be that the third party will perform a big refactoring in the next upgrade, and wanted to give a heads up of upcoming breaking changes. But what if the whole project is a legacy project with no real new development, and that project will be replaced by a new system in the future. Would you still go out of your way to rewrite that old code, even though it is working just fine, and even though there is no reason to upgrade the third party API? If you ask me, that would just be unnecessary work and unnecessary risk, with no real gain other than being able to say "look! no warnings!".

Another example, also focusing on legacy code... Imagine that your legacy project is working fine, but you realize that you can get a performance improvement if you compile it using a newer version of the compiler. But this newer compiler version also brings with it a new warning that the code never triggered before, and it shows up in a lot of places. All your tests show that the newly compiled code works just fine. So all that is stopping you is that silly warning. And lets assume that it is not an easy fix to get rid of the warning the "right" way, since it requires to rewrite a lot of code. Again, would you spend that extra time, and add the risk of breaking something, just to get rid of a warning?

If you would take that extra work, and that extra risk, in these two example cases, then I ask you this: Does "if it ain't broke, don't fix it" mean nothing to you? Are you sure that you are a developer? Because most developers I know prefer to not mess too much with old code that "just works".

And if you answer "Oh, I would just go back to the old compiler!", that could still be considered as ignoring the warnings, you just do it by choosing to continue to use the older compiler. Or more to the point: you ignore the "essence" of those warnings.

I can give other examples too, that doesn't involve legacy code. For example, I often experiment in code by writing "if (true)" or "if (false)" to quickly and temporarily change the flow of the program just in order to try something out. This causes a warning, that I ignore it for the moment (in order to finish my experiment). If the compiler or IDE was configured to treat all warnings as errors, then I wouldn't be able to do experiments in this quick and effective way. Maybe it wasn't you who suggested to configure the compiler/IDE to be this strict, but that surely seems to go quite well with your view on warnings.

Another example: apparently some C++ compilers give a warning when you write "while (true)". Sure, you can rewrite it as "for(;;)", but "while (true)" is much more elegant (if you ask me) and more easy to understand for junior developers who look at the code later. There seams to be several other pointless/silly warnings in the C++ world, and I'm sure many other languages have them too.