On Thu, Sep 14, 2017 at 10:58:43PM -0700, email@example.com wrote:
But my idea is only to define basical metrics, useful to evaluate quality code, and related to PEPs if existing. I precise i'd like to propose informational PEP only. I'm not considering that my idea must be mlandatory, but only an indication to improve its code quality. So each developer/society would be free to evaluate each metrics with the way he/it want. As for PEP8 for example, for which each developer can use pep8, pylint, ...
The PEP257, for docstrings, indicate how to structure our docstring. My PEP, in my mind, would indicate how to basically evaluate our quality code, only which metrics are useful for that. But only this, no tools indication.
It might help if you tell us some of these proposed code quality metrics. What do you mean by "code quality", and how do you measure it?
The only semi-objective measures of code quality that I am aware of are:
- number of bugs per kiloline of code;
- percentage of code covered by tests.
And possibly this one:
Given two code bases in the same language, one is better quality than the other if the number of bugs per thousand lines is smaller, and the percentage of code coverage is higher.
I am interested in, but suspicious of, measures of code complexity, coupling, code readability, and similar.
What do you consider objective, reliable code quality metrics?