3 ms·

Yes! The statically checkable ones will be checked by rustc or Clippy. Though some of the guidelines are at a higher level than what those would be able to chec

Yes! The statically checkable ones will be checked by rustc or Clippy. Though some of the guidelines are at a higher level than what those would be able to check. For example: rustc wouldn't be able to tell whether a particular one of your traits would be valuable to make accessible as a trait object.

Manishearth 9y ago
(Also, if this isn't clear, clippy is more than happy to accept PRs for criteria like these.)
ronjouch 9y ago
Beginner question: what would make a crate non-statically-checkable?
- Manishearth 9y ago
  A guideline like "your tests should test all major functionalities of an API" can't be statically checked for example. It's not about the crate being non checkable, it's about the check being something that needs a human to look at.
  - moosingin3space 9y ago
    I realize that statically checking for tests is reducible to the halting problem, but would it be possible to have some sort of code-coverage checker that would make sure all externally-facing functions have non-zero coverage? That could be used to construct a checklist for a library developer.
    - kilotaras 9y ago
      Code coverage in itself isn't a very useful metric. Classic example is big test with no asserts will get you pretty good coverage. There's a rather computationally intensive technique called mutation testing where you introduce bugs into code (e.g. change + to -, flip conditionals, etc.) and check that tests fail.
      - burntsushi 9y ago
        Code coverage has been useful to me in practice, so I think blanket statements like "code coverage isn't useful" is very misleading. For example, code coverage has helped me identify specific branches in my code that are untested, which in turn help guide me to write additional unit tests. You don't need to completely dismiss other testing techniques. Mutation testing can be useful at the same time that code coverage is useful.
        yazaddaruvala 9y ago
        Totally agreed. Branch coverage has been far more useful to me than line coverage has.
    - Manishearth 9y ago
      Yes, there are code coverage tools and stuff :) This could be used, sure.

Manishearth 9y ago

(Also, if this isn't clear, clippy is more than happy to accept PRs for criteria like these.)

ronjouch 9y ago

Beginner question: what would make a crate non-statically-checkable?

Manishearth 9y ago
A guideline like "your tests should test all major functionalities of an API" can't be statically checked for example. It's not about the crate being non checkable, it's about the check being something that needs a human to look at.
- moosingin3space 9y ago
  I realize that statically checking for tests is reducible to the halting problem, but would it be possible to have some sort of code-coverage checker that would make sure all externally-facing functions have non-zero coverage? That could be used to construct a checklist for a library developer.
  - kilotaras 9y ago
    Code coverage in itself isn't a very useful metric. Classic example is big test with no asserts will get you pretty good coverage. There's a rather computationally intensive technique called mutation testing where you introduce bugs into code (e.g. change + to -, flip conditionals, etc.) and check that tests fail.
    - burntsushi 9y ago
      Code coverage has been useful to me in practice, so I think blanket statements like "code coverage isn't useful" is very misleading. For example, code coverage has helped me identify specific branches in my code that are untested, which in turn help guide me to write additional unit tests. You don't need to completely dismiss other testing techniques. Mutation testing can be useful at the same time that code coverage is useful.
      - yazaddaruvala 9y ago
        Totally agreed. Branch coverage has been far more useful to me than line coverage has.
  - Manishearth 9y ago
    Yes, there are code coverage tools and stuff :) This could be used, sure.