Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Congratulations! You now have fatal warnings on everywhere that is practical.

I think that last bit is the most important one. You need to be practical about stuff like this.

Putting a ban-hammer down like a CI-nazi is most likely not going to get you the results you were hoping for.

Edit: Looking at the linked issue [1], this has taken quite some time. First comment on that issue is 15 years old :D

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=187528)



I think that linked bugzilla issue is amazing, slow patient work over years to fix issues. We should really celebrate this sort of effort more in our industry.


Move slow and fix things?


Pun intended? ;-)


To be fair, the process of making them fatal was a lot more recent. Probably only took 3 or 4 years!


It also means that this is mainly applicable on software that is expected to be in development for many years and then have many years of active maintenance.


Software that is not expected to be in development for years probably doesn't need this. Get it working, manually tested, ship it and move on. This is probably cheaper than the extra engineering effort to make everything perfect. Most warnings are for things that won't matter since you won't port to that system (it doesn't matter if your invoke undefined behavior if the only compiler you use at your optimization level does what you want)

All of the above will come back to bite you hard if you have to release again. Some will come back to bite you right away (the expense of manually testing everything), while others can lurk hidden for years (little vs big endian issues).


> (it doesn't matter if your invoke undefined behavior if the only compiler you use at your optimization level does what you want)

I mean, in one sense you're right, but UB can make even trivial maintenance absolute hell even if you stick to the exact same build toolchain.


That's great of you work at a startup that you don't expect to make it. Or your in one of those groups at a big corp that's really only doing busy work to satisfy manger egos and you know the project will be canned before it's ever used. If people are actually going to use your software then this applies.


The field I was thinking about was actually game development. Usually games are developed, shipped once, and then only have a short maintenance lifetime before the developers move on to other projects. This applies a lot with shrink wrapped games and also with game jam games, but far less so with the games in perpetual beta or early access, and also with long lived free-to-play or MMOs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: