←back to thread

Brent's Encapsulated C Programming Rules (2020)

(retroscience.net)
78 points p2detar | 4 comments | 09 Dec 25 11:16 UTC | HN request time: 0.96s | source
Show context
f1shy ◴[09 Dec 25 17:47 UTC] No.46208010[source]▶
> Make sure that you turn on warnings as errors

I’m seeing this way too often. It is a good idea to never ignore a warning, an developers without discipline may need it. But for god’s sake, there is a reason why there are warnings and errors ,and they are treated differently. I don’t think compiler writers and/or C standards will deprecate warnings and make them errors anytime soon, and for good reason. So IMHO is better to treat errors as errors and warnings as warnings. I have seen plenty of times this flag is mandatory, and to avoid the warning (error) the code is decorated with compiler pacifiers, which makes no sense!

So for some setups I understand the value, but doing it all the time shows some kind of lazyness.

replies(1): >>46209146 #
Chabsff ◴[09 Dec 25 19:07 UTC] No.46209146[source]▶
> and to avoid the warning (error) the code is decorated with compiler pacifiers, which makes no sense!

How is that a bad thing, exactly?

Think of it this way: The pacifiers don't just prevent the warnings. They embed the warnings within the code itself in a way where they are acknowledged by the developer.

Sure, just throwing in compiler pacifiers willy-nilly to squelch the warnings is terrible.

However, making developers explicitly write in the code "Yes, this block of code triggers a warning, and yes it's what I want to do because xyz" seems not only perfectly fine, but straight up desirable. Preventing them from pushing the code to the repo before doing so by enabling warnings-as-errors is a great way to get that done.

The only place where I've seen warnings-as-errors become a huge pain is when dealing with multiple platforms and multiple compilers that have different settings. This was a big issue in Gen7 game dev because getting the PS3's gcc, the Wii's CodeWarrior and the XBox360's MSVC to align on warnings was like herding cats, and not every dev had every devkit for obvious reason. And even then, warnings as errors was still very much worth it in the long run.

replies(1): >>46215339 #
f1shy ◴[10 Dec 25 08:15 UTC] No.46215339[source]▶
IMHO readability is the absolute maximum paramount priority. Having the code interrupted by pacifiers makes the code more difficult to read. The warning is very visible when compiling. Let me argue, much more visible. Why? well, independent if my last change had something directly to do with that piece of code, I will see the warning. If I use some preprocessor magic, I will only see that if I directly work in that part of the code.

Again, IMHO the big problem is people think "warnings are ok, just warnings, can be ignored".

And just as anecdotal point "Sure, just throwing in compiler pacifiers willy-nilly to squelch the warnings is terrible." this is exactly what I have seen in real life, 100% of the time.

replies(2): >>46215610 #>>46216609 #
1. 1718627440 ◴[10 Dec 25 11:35 UTC] No.46216609[source]▶
But how do you distinguish between warnings intended by the author and warnings, that weren't, so they should be fixed?
replies(1): >>46217132 #
2. f1shy ◴[10 Dec 25 12:51 UTC] No.46217132[source]▶
Please remember we are coming from "set warnings to errors", which I interpret as: I know better than the people doing the compiler. There is a good reason for the two. If not, there could be no warnings at all, all would be an error.

My rationale: if you do set warn->error, then there are 2 ways around it: change the code to eliminate the warning, or pacify the compiler. Note, the measure to set it to error, is to instigate lazy programmers to deal with it. If the lazy person is really lazy, then they will deal with it with a pacifier. You won nothing.

There is no one recipe for everything. That is why, even if I do not like to treat warnings as errors, sometimes may be a possible solution.

I think you should deal with warnings, you should have as few as possible, if any at all. So if you have just a couple, is not a problem to document them clearly. Developers building the project should be informed anyway of many other things.

In some projects I worked, we saw warnings as technical debt. So hiding them with a pacifier would make us forget. But we saw them in every build, so we were reminded constantly, we should rework that code. Again, it depends on the setup you have in the project. I know people now are working with this new trend "ci/cd" and never get to the see the compilation. So depending on the setup one thing or another may be better.

replies(1): >>46217257 #
3. 1718627440 ◴[10 Dec 25 13:09 UTC] No.46217257[source]▶
> My rationale: if you do set warn->error, then there are 2 ways around it: change the code to eliminate the warning, or pacify the compiler. Note, the measure to set it to error, is to instigate lazy programmers to deal with it. If the lazy person is really lazy, then they will deal with it with a pacifier. You won nothing.

> You won nothing.

No, you won that you can distinguish between intended and not intended warnings. Specifying in the code, which warnings are expected makes all warnings that the compiler outputs something you want to get fixed. When you do not do that, than it is easy to miss a new warning or that the warning changed. So you essentially say that you should not distinguish between intended and non-intended warnings?

Having no warnings is a worthwhile goal, but often not possible, since you want to be warned for some things, so you need that warning level, but you don't want to be warned about that in a specific line.

replies(1): >>46218234 #
4. f1shy ◴[10 Dec 25 14:42 UTC] No.46218234{3}[source]▶
> So you essentially say that you should not distinguish between intended and non-intended warnings?

No, I pretty clearly said the opposite. Please read what I wrote:

"[...] is not a problem to document them clearly. Developers building the project should be informed anyway of many other things"

I also stated "warnings, you should have as few as possible, if any at all" in the projects I worked we hardly had any in the final delivery, but we had many in-between, which I find ok. If there are only 2 warnings, I do not see a big risk of not seeing a 3rd. I expect developers to look the compiler output, carefully, as if it was a review from a coworker.

Last but not least you ignore my last paragraph, where I say warnings are typically technical debt. There should be in the long run no "expected" warnings. My whole point is that they are just no error, so you should allow the program to compile and keep working in other things. I do not think is ok to have warnings. Also (specially) I think is a bad idea to silence the compiler.

Anyway, a good compiler will end with a nile lime “N warnings detected“ so there is that. You can just compare an integer to know if there are more warnings… not so difficult, is it?

If you read my comments it should be clear. If not, I cannot help with that. If you want to disagree, as long as you don't work in my code, is ok. This is just my 2ct opinion.