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

[Ned Batchelder]

On 9/20/17 8:37 PM, Chris Barker - NOAA Federal wrote:
>> You can define metrics. But as to what they mean? Well that is the question.
> One big problem with metrics is that we tend to measure what we know
> how to measure -- generally really not the most useful metric...
>
> As for some kind of PEP or PEP-like document:
>
> I think we'd have to see a draft before we have any idea as to whether
> it's a useful document -- if some of the folks on this thread are
> inspired -- start writing!
>
> I, however, am skeptical because of two things:
>
> 1) most code-quality measures, processes, etc are not language
> specific -- so don't really belong in a PEP
>
> So why PEP 8? -- because the general quality metric is: " the source
> code confirms to a consistent style" -- there is nothing language
> specific about that. But we need to actually define that style for a
> given project or organization -- hence PEP 8.
>
> 2) while you can probably get folks to agree on general guidelines--
> tests are good! -- I think you'll get buried in bike shedding of the
> details. And it will likely go beyond just the color of the bike shed.
>
> Again -- what about PEP8? Plenty of bike shedding opportunities there.
> But there was a need to reach consensus on SOMETHING-- we needed a
> style guide for the standard lib. I'm not that's the case with other
> "quality" metrics.

I don't see the need for a PEP here.  PEPs are written where we need the 
core committers to agree on something (how to change Python, how to 
style stdlib code, etc), or where we need multiple implementations to 
agree on something (what does "python" mean, how to change Python, etc).

There's no need for the core committers or multiple implementations of 
Python to agree on quality metrics.  There's no need for this to be a 
PEP.  Write a document that proposes some quality metrics. Share it 
around. Get people to like it. If it becomes popular, then people will 
start to value it as a standard for project quality.

It doesn't need to be a PEP.

--Ned.

> But go ahead and prove me wrong!
>
> -CHB
>
>
>
>> I was once told that you should measure a new metric for 2 years before you attempting to use it to change your processes.
>>
>> Oh and what is the most important thing for a piece of work?
>>
>> I'd claim its the requirements. Get them wrong and nothing else matters.
>>
>> Oh and thank you for raising a very important topic.
>>
>> Barry
>>
>>
>>> @Jason, thanks for your example. When i discussed from this proposal with other devs of my team, they needed too example to have better idea of use. But i think, as wee need to avoid to talk about any tool name in the PEP, we need to avoid to give a code example. The aim of this proposal is to have a guideline on minimal metrics to have minimal quality. As you talked about, i ask to every devs of my team to respect the higher standard as possible. This, and the permanent request of my customers for the highest dev quality as possible, is the reason which explain this proposal.
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/