[Python-ideas] Fwd: A PEP to define basical metric which allows to guarantee minimal code quality
alexandre.galode at gmail.com
alexandre.galode at gmail.com
Mon Sep 25 07:49:42 EDT 2017
Hi,
Sorry from being late, i was in professional trip to Pycon FR.
I see that the subject is divising advises.
Reading responses, i have impression that my proposal has been saw as
mandatory, that i don't want of course. As previously said, i see this
"PEP" as an informational PEP. So it's a guideline, not a mandatory. Each
developer will have right to ignore it, as each developer can choose to
ignore PEP8 or PEP20.
Someones was saying that it was too generic, and not attached to Python,
but i'm not OK on this point, because some metrics basically measured on
Python code is justly PEP8 respect, with tools like PEP8, pylint, ... Not
every metrics could be attached to another PEP, i'm OK on this point, but
if at least one of its could be, it means in my mind, that a PEP can be
justified.
@Jason, about false sense of security. Reading this make me thinking to the
last week Pycon. Someone was talking to me to its coverage rate was
falling. But in fact it was because an add of code lines, without TU on it.
It means, that the purposed metrics are not to be used as "god" metrics,
that we have only to read to know precisely the "health" of our code, but
metrics which indicates to us the "health" trend of our code.
@Chris, about we measure only what we know. Effectively, i think it's the
reality. One year ago, i didn't know McCabe principle and associated tool.
But now, i'm using it. If a "PEP", existing from a time, was talking about
this concept, i would read it and apply the concept.
Perfect solution does not exist, i know it, but i think this "PEP" could,
partially, be a good guideline.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170925/c53fda45/attachment.html>
More information about the Python-ideas
mailing list