Re: Finally completed badge, feedback on process
Which critieria are you saying is taking a position on this?David's reply covered this; it’s the last SUGGESTED item under public version-controlled source repository.
Completely agree, and absolutely not a reason. The implication is that each project would be setting a bar wherever it makes sense for them. The SHOULD/MUST requirement would merely be that the project HAS a bar defined somewhere that they strictly maintain. If they want to go hog wild with -Wextra -Weverything-else-under-the-sun and address them, more power to them. There's reasonable argument that even addressing false-positive code smells will improve code quality.6) Treating warnings as errors shouldn’t be a suggestion. Projects SHOULD be maximally strict, treating warnings as errors, with minimal exceptions (e.g., less than 1 exemption per 100 files). Frankly, I think it should be a MUST."maximally strict" is not a binary option, though. In many languages you can select levels of compliance or which standard to use for warnings. Like in C, lots of things in the older standard cause warnings in the newer etc. Compilers these days also allow warnings as help, they don't necessarily identify errors but *possible* errors. Would a single warning about an suspected source code indentation problem be a reason for a project to not follow best practices?
Also, warnings on which platforms? I work on projects that build on virtually every architecture and operating system that run on 32bits. Making them all build warning-free everywhere is if not impossible (in some cases the warnings are literally impossible to fix since they're mutually exclusive on different platforms), not something that would benefit the project or improve the source code.Building strict on MSVC is notoriously problematic where some of their warnings actually amount to “WARNING: we’re now standard’s compliant, and you might have previously relied on undefined behavior.” Their documented solution is to pragma disable! Other warnings actively harm the code too by increasing maintainability, error-proneness, etc.
I think this is again a matter of the project having set their bar somewhere, anywhere. Even on Windows, there are a plethora of really good warnings that it will uniquely issue and once a project is clean, they can add it to their strict-level check to maintain that level of code quality going forward.
My (so far) two listed 100% projects would not be 100% if this would be a MUST and say "on all platforms". And in fact, that would make it really hard for a very large number of portable C and C++ projects.On all platforms is impossible if only for the mutual exclusion issue you mention. I would suggest replacing the item with something like this:
The project MUST have a build configuration option that is maximally strict where some level of warnings are treated as errors.
It’s acknowledged that some platforms and compiler warnings are notoriously problematic and can be mutually exclusive or outright counterproductive. Other warning levels often contain high levels of false positives, but even addressing them can lead to improved code quality (see https://en.wikipedia.org/wiki/Code_smell). The recommended best practice is that a project defines a minimum warning compliance level that they actively maintain for one or more platform configurations. A project SHOULD, by default, treat warnings as errors for some set of warnings, however minimal, and strive to add additional warnings to their strictness repertoire over time.
Agreed! It is also somewhat related to: https://github.com/linuxfoundation/cii-best-practices-badge/issues/463 "Add support for large badge"Note there is a quick CSS workaround by modifying the tag: <img style="height: 64px; width: auto;” …>. Noted on the issue.