[Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality

[Terry Reedy]

On 9/15/2017 1:58 AM, 
alexandre.galode at gmail.com wrote:
> Hi,
> 
> Thanks for your return, and link. I knew PyCQA but not the others.
> 
> It seems i didn't success to precise my idea correctly. I'm 100% OK with 
> you that this is not language role to indicate precisely which tools to 
> use.
> 
> 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, ...

It seems to me that you are talking about stuff more appropriate to blog 
posts or the python wiki or even to a web site.

> 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.
> 
> Customer i see regularly ask me for being PEP8 & 257 & ... "certified". 
Why do they care?  In my view, style is not quality.  It is a means to 
better quality.  I say this as someone who enforces most of PEP 8 on new 
IDLE patches, whether by myself or others, and who even upgrades 
existing code.  The relevance to users is that it facilitates making 
IDLE work better.

Automated test coverage is also a means to code quality, not quality in 
itself.  I recently fixed a bug in 100% covered code.  I discovered it 
by using the corresponding widgets like a user would.  The automated 
test did not properly simulate a particular pattern of user actions.

> This PEP could be opportunity to have opportunity saying be "PEPxxxx 
> certified", so customers would be sure that several metrics, based on 
> PEP and other parameter, would be use to gurantee their quality code.

PEP 8 started as a guide for new stdlib code, but we do not 'pep8 
certify' Python patches to the stdlib.  Security, stability, 
correctness, test coverage, and speed are all more important.  It just 
happened that others eventually adopted PEP 8 for their own use, 
including in code checkers.

Information about .rst only belongs in a PEP because we use it in our 
own docs.

Information about code metrics might belong in a PEP only if we were 
applying them to the CPython code base.  Note that our C code is checked 
by Coverity, but I don't believe there is a PEP about it.  (No title has 
'coverity'.)  After pydev discussion, a core developer made the 
available free checks happen and then followed up on the deficiency reports.

-- 
Terry Jan Reedy