> 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. 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/
