<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 17, 2014 at 3:24 PM, Mike Spreitzer <span dir="ltr"><<a href="mailto:mspreitz@us.ibm.com" target="_blank">mspreitz@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">I like the idea of measuring complexity.
 I looked briefly at `python -m mccabe`.  It seems to measure
each method independently.  Is this really fair?</font></blockquote><div><br></div><div>I think it is a good starting point. You still need to write methods that do one thing well (simple and easy to read/test by it's self). But it stops complex methods growing out of hand, by just failing the test and now you have to look at refactoring. I think reviews can cover the "how good is your refactor".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">  If I have a
class with some big methods, and I break it down into more numerous and
smaller methods, then the largest method gets smaller, but the number of
methods gets larger.  A large number of methods is itself a form of
complexity.  It is not clear to me that said re-org has necessarily
made the class easier to understand.  I can also break one class into
two, but it is not clear to me that the project has necessarily become
easier to understand.</font></blockquote><div><br></div><div>No, but a well written class *should* be easy to understand in isolation. I don't think there is a tool to say 'your code sucks'.<br><br></div><div>-A<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">  While it is true that when you truly make a
project easier to understand you sometimes break it into more classes,
it is also true that you can do a bad job of re-organizing a set of classes
while still reducing the size of the largest method.  Has the McCabe
metric been evaluated on Python projects?  There is a danger in focusing
on what is easy to measure if that is not really what you want to optimize.</font>
<br>
<br><font face="sans-serif">BTW, I find that one of the complexity
issues for me when I am learning about a Python class is doing the whole-program
type inference so that I know what the arguments are.  It seems to
me that if you want to measure complexity of Python code then something
like the complexity of the argument typing should be taken into account.</font>
<br>
<br><font face="sans-serif">Regards,<br>
Mike</font><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>