-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proj0039: Treat all warnings as errors is considered a bad practice #109
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense, although as you mention, some people will disagree.
Are there arguments you disagree with? Sentences you would phrase differently? May be swap the order of the arguments? |
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
I think I would end with developer unwillingness, first mention the technical reasons then the 'emotional' ones |
Co-authored-by: Gemberkoekje <Arie_Hofland@hotmail.com>
Co-authored-by: Gemberkoekje <Arie_Hofland@hotmail.com>
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Perhaps it's worth mentioning it is also possible to treat warnings as errors only during the CI pipeline, so that it doesn't block building locally |
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Co-authored-by: Laura Kramer <laurakramer91@gmail.com>
Sure, but that does not solve the main issue: it is rigid and contra-productive to have this enabled. Zero warnings should not be the main objective, having good code quality is. You could also say that this is of the category: If a measurement becomes a target, it looses is value as measurement. So having the (only) enabled on the CI will not safe the day. |
So in which numerical order? And why? Do you think that are the stronger arguments? Or do you think you should end with the strongest arguments? I think the first one is the strongest argument: you come op with some rigid setting to overcome a social issue, and that will not work. |
Because it might put people off reading first that they are supposedly not willing to solve warnings, instead of first telling them why it might be a bad idea |
The rest of the order is fine, maybe put the IDE last (because it is the last hurdle in the process) |
I'm aware that this rule is opinionated, and I'm intending to release this with a severity info, instead of a warning. I'm also aware that this is by far the longest rule description, and is written more as a blog. Tips on how to improve that are (also) welcomed.