- Function length (recommended 4-40 lines of code for C, except for multiway branches.)
- Module length (recommended 4-400 lines for C, 10-40 functions per file)
- Ratio of comments (30-75% of code length, excluding blank lines. Exception is C header file.)
- https://en.wikipedia.org/wiki/Flesch–Kincaid\_readability\_tests
- Number of arguments
- Number of local definitions
- Complexity measures:
- McCabe "Cyclomatic number" - number of linearly independent paths through code, tends to be PL independent -> should be <15 for a function -> should be <100 for a file [ ] Composite metrics (like Code Climate)
- Halstead Metrics
- Maintainability Index
- Number of links between functions and modules (n-planarity of the graph)
- Editing distance between different exposed names
- Warn about tuples with more than 5 arguments?
- Warn about constructors with more than 4 arguments that are not records.
- Facilities:
- Iterable instances for haskell-src-exts (so that there is convenient interface to quickly check all source instances within given structure, for example).
- Lens instances.
- Count errors, and show how many files couldn't be parsed.
- Treat classes similar to records - limit number of symbols.
- Try to guess extra params, or read them from file:
- cpphs [ ] cpphs options to be snatched from Cabal (cabal exec?) [ ] configure cpphs options (GHC)
- LANGUAGE pragmas
- Catch "invalid byte sequence" errors, and report as incorrect files.
- Sort by metrics to show hotspots at the bottom (top) of the printout
- Dead code detection - project-wide
- Suggest newtypes from function names
- Add missing params from my projects (like StandaloneDeriving)
- Check for Unicode ligatures and multipoint characters (see https://tworingsoft.com/blog/2018/12/10/fun-with-unicode-in-swift.html)