On 17 Sep 2017, at 19:17, alexandre.galode@gmail.com wrote:


thanks for your answer, and your questions. Very good draw. I printed it in my office ^^

First i'd like to precise that, as in title, aim is not to gurantee quality but minimal quality. I think it's really two different things.

About metrics, my ideas was about following (for the moment):
  • Basical Python Rules respect: PEP8 & PEP20 respect
  • Docstring/documentation respect: PEP257 respect
  • Code readability: percentage of commentary line and percentage of blank line
  • Code maintainability / complexity: the facility to re-read code if old code, or to understand code for an external developer. If not comprehensive, for example, i use McCabe in my work
  • Code coverage: by unit tests
From your question on objective metrics, i don't think that reliable metrics exists. We can only verify that minimal quality can be reached. As you say, it's a subjective apprehension, but in my mind, this "PEP" could be a guideline to improve development for some developers.

Quality is something that an organisation and its people need to achieve by building appropriate processes and improvement methods into their work flow.

Trying to be prescriptive will run into trouble for the wider world I suspect.

Many of the maintainability metrics may help a team.

However peer review and discussion within teams is a powerful process to achieve good code, which is process.

I do not see quality as a quantity that can be easily measured.
How can we set a minimum for the hard to measure?


p.s. Why does this thread have a reply address of python-ideas@googlegroups.com?

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/