Use git history to track how often a file is changed and use it as metric for maintainability #117
Description
Like #58 suggest to use coverage as extra scoring metric, i remember static code analysis using change frequency or amount as metric to smell bad architecture design (and so low maintainability).
For example : if we sort every file in the project by commit number where there are involved :
- small commit number on a file is a good smell
- how far a file is from median or average file in commit number can be a bad smell (10x more than average is a very bad smell)
what do you think about this ?