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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
