Re: Web Frameworks Excessive Complexity
On Wed, Nov 21, 2012 at 12:49:52PM -0800, rh wrote: wheezy + myvirtualenv = 3.3MB pyramid = 92MB $ mkvirtualenv --no-site-packages -p python2.7 pyramid $ pip install -U distribute $ pip install pyramid $ du -h .virtualenvs/pyramid 22M .virtualenvs/pyramid $ du -s .virtualenvs/pyramid/lib/python2.7/site-packages/* | sort -n | tail -n 5 728 .virtualenvs/pyramid/lib/python2.7/site-packages/pip-1.1-py2.7.egg 1556.virtualenvs/pyramid/lib/python2.7/site-packages/setuptools 1724.virtualenvs/pyramid/lib/python2.7/site-packages/zope 2044.virtualenvs/pyramid/lib/python2.7/site-packages/chameleon 6312.virtualenvs/pyramid/lib/python2.7/site-packages/pyramid I think 22 MB are OK given the functionality Pyramid has to offer. Just my 2 cents, Thomas. -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
Am 21.11.2012 02:43, schrieb Steven D'Aprano: On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote: The source of bugs is not excessive complexity in a method, just excessive lines of code. Taken literally, that cannot possibly the case. def method(self, a, b, c): do_this(a) do_that(b) do_something_else(c) def method(self, a, b, c): do_this(a); do_that(b); do_something_else(c) It *simply isn't credible* that version 1 is statistically likely to have twice as many bugs as version 2. Over-reliance on LOC is easily gamed, especially in semicolon languages. Don't indent deeper than 4 levels! OK, not indenting at all, $LANG doesn't need it anyway. Sorry, but if code isn't even structured halfway reasonably it is unmaintainable, regardless of what CC or LOC say. Besides, I think you have the cause and effect backwards. I would rather say: The source of bugs is not lines of code in a method, but excessive complexity. It merely happens that counting complexity is hard, counting lines of code is easy, and the two are strongly correlated, so why count complexity when you can just count lines of code? I agree here, and I'd go even further: Measuring complexity is not just hard, it requires a metric that you need to agree on first. With LOC you only need to agree on not semicolon-chaining lines and how to treat comments and empty lines. With CC, you effectively agree that an if statement has complexity of one (or 2?) while a switch statement has a complexity according to its number of cases, while it is way easier to read and comprehend than a similar number produced by if statement. Also, CC doesn't even consider new-fashioned stuff like exceptions that introduce yet another control flow path. LoC is much simpler, easier to understand, and easier to correct than CC. Well, sure, but do you really think Perl one-liners are the paragon of bug-free code we ought to be aiming for? *wink* Hehehe... ;) Uli -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
Robert, You would never get a better product by accident. The meaning of better product might differ from team to team but you can not ignore excessive complexity. Earlier or later you get back to that code and refactor it, thus existence of such fact was driven by your intention to make it a bit better (easier to understand, to support, to cover with unit tests, etc), with a team of 20 heads you can get even further: the whole team adherence. So those drops make the overall picture better. This is what you, as a software developer, donate to what the final better product become. Thanks. Andriy To: python-list@python.org From: robert.k...@gmail.com Subject: Re: Web Frameworks Excessive Complexity Date: Tue, 20 Nov 2012 20:33:46 + On 20/11/2012 20:22, Andriy Kornatskyy wrote: Robert, I respect your point of view and it definitely make sense to me. I personally do not have a problem to understand CC but agree, method LoC is easier to understand. Regardless the path your choose in your next refactoring (based on method CC, LoC) it gives your better product. No, refactoring based on CC does not give you a better product, except by accident. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
We choose Python for its readability. This is essential principal of language and thousands around reading the open source code. Things like PEP8, CC, LoC are all to serve you one purpose: bring your attention, teach you make your code better. Thanks. Andriy From: ulrich.eckha...@dominolaser.com Subject: Re: Web Frameworks Excessive Complexity Date: Wed, 21 Nov 2012 09:33:09 +0100 To: python-list@python.org Am 21.11.2012 02:43, schrieb Steven D'Aprano: On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote: The source of bugs is not excessive complexity in a method, just excessive lines of code. Taken literally, that cannot possibly the case. def method(self, a, b, c): do_this(a) do_that(b) do_something_else(c) def method(self, a, b, c): do_this(a); do_that(b); do_something_else(c) It *simply isn't credible* that version 1 is statistically likely to have twice as many bugs as version 2. Over-reliance on LOC is easily gamed, especially in semicolon languages. Don't indent deeper than 4 levels! OK, not indenting at all, $LANG doesn't need it anyway. Sorry, but if code isn't even structured halfway reasonably it is unmaintainable, regardless of what CC or LOC say. Besides, I think you have the cause and effect backwards. I would rather say: The source of bugs is not lines of code in a method, but excessive complexity. It merely happens that counting complexity is hard, counting lines of code is easy, and the two are strongly correlated, so why count complexity when you can just count lines of code? I agree here, and I'd go even further: Measuring complexity is not just hard, it requires a metric that you need to agree on first. With LOC you only need to agree on not semicolon-chaining lines and how to treat comments and empty lines. With CC, you effectively agree that an if statement has complexity of one (or 2?) while a switch statement has a complexity according to its number of cases, while it is way easier to read and comprehend than a similar number produced by if statement. Also, CC doesn't even consider new-fashioned stuff like exceptions that introduce yet another control flow path. LoC is much simpler, easier to understand, and easier to correct than CC. Well, sure, but do you really think Perl one-liners are the paragon of bug-free code we ought to be aiming for? *wink* Hehehe... ;) Uli -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
Counting complexity by giving a score to every statement encourages code
like this:
def bletch(x,y):
return x + {foo:y*2,bar:x*3+y,quux:math.sin(y)}.get(mode,0)
instead of:
def bletch(x,y):
if mode==foo: return x+y*2
if mode==bar: return x*4+y
if mode==quux: return x+math.sin(y) return x
Okay, this is a stupid contrived example, but tell me which of those
you'd rather work with
Am I being paid by the hour or the line?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
Chris,
The focus of development team is controlled by setting a metric threshold or
just excluding some. So you do not have an overhead for the development team
from the point it set forward, assuming them team committed to adherence it.
Your strategy for perfection may vary. You can start with 8 for CC in new
project, or with a higher level of 15 in an existing project. Where you end up
/ the team agrees upon, depends on team commitment to the goal you set. There
is no gold median, there is just recommendation, how you fluctuate from it and
what reason you face with depends on team.
Thanks.
Andriy
Date: Wed, 21 Nov 2012 22:21:23 +1100
Subject: Re: Web Frameworks Excessive Complexity
From: ros...@gmail.com
To: python-list@python.org
On Wed, Nov 21, 2012 at 10:09 PM, Andriy Kornatskyy
andriy.kornats...@live.com wrote:
We choose Python for its readability. This is essential principal of
language and thousands around reading the open source code. Things like
PEP8, CC, LoC are all to serve you one purpose: bring your attention, teach
you make your code better.
But too much focus on metrics results in those metrics improving
without any material benefit to the code. If there's a number that you
can watch going up or down, nobody's going to want to be the one that
pushes that number the wrong direction. So what happens when the right
thing to do happens to conflict with the given metric? And yes, it
WILL happen, guaranteed. No metric is perfect.
Counting lines of code teaches you to make dense code. That's not a
good thing nor a bad thing; you'll end up with list comprehensions
rather than short loops, regardless of which is easier to actually
read.
Counting complexity by giving a score to every statement encourages
code like this:
def bletch(x,y):
return x + {foo:y*2,bar:x*3+y,quux:math.sin(y)}.get(mode,0)
instead of:
def bletch(x,y):
if mode==foo: return x+y*2
if mode==bar: return x*4+y
if mode==quux: return x+math.sin(y)
return x
Okay, this is a stupid contrived example, but tell me which of those
you'd rather work with, and then tell me a plausible metric that would
agree with you.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On 21/11/2012 01:43, Steven D'Aprano wrote: On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote: The source of bugs is not excessive complexity in a method, just excessive lines of code. Taken literally, that cannot possibly the case. def method(self, a, b, c): do_this(a) do_that(b) do_something_else(c) def method(self, a, b, c): do_this(a); do_that(b); do_something_else(c) It *simply isn't credible* that version 1 is statistically likely to have twice as many bugs as version 2. Over-reliance on LOC is easily gamed, especially in semicolon languages. Logical LoC (executable LoC, number of statements, etc.) is a better measure than Physical LoC, I agree. That's not the same thing as cyclomatic complexity, though. Also, the relationship between LoC (of either type) and bugs is not linear (at least not in the small-LoC regime), so you are certainly correct that it isn't credible that version 1 is likely to have twice as many bugs as version 2. No one is saying that it is. Besides, I think you have the cause and effect backwards. I would rather say: The source of bugs is not lines of code in a method, but excessive complexity. It merely happens that counting complexity is hard, counting lines of code is easy, and the two are strongly correlated, so why count complexity when you can just count lines of code? No, that is not the takeaway of the research. More code correlates with more bugs. More cyclomatic complexity also correlates with more bugs. You want to find out what causes bugs. What the research shows is that cyclomatic complexity is so correlated with LoC that it is going to be very difficult, or impossible, to establish a causal relationship between cyclomatic complexity and bugs. The previous research that just correlated cyclomatic complexity to bugs without controlling for LoC does not establish the causal relationship. Keep in mind that something like 70-80% of published scientific papers are never replicated, or cannot be replicated. Just because one paper concludes that LOC alone is a better metric than CC doesn't necessary make it so. But even if we assume that the paper is valid, it is important to understand just what it says, and not extrapolate too far. This paper is actually a replication. It is notable for how comprehensive it is. The paper makes various assumptions, takes statistical samples, and uses models. (Which of course *any* such study must.) I'm not able to comment on whether those models and assumptions are valid, but assuming that they are, the conclusion of the paper is no stronger than the models and assumptions. We should not really conclude that CC has no more predictive power than LOC. The right conclusion is that one specific model of cyclic complexity, McCabe's CC, has no more predictive power than LOC for projects written in C, C++ and Java. How does that apply to Python code? Well, it's certainly suggestive, but it isn't definitive. More so than the evidence that CC is a worthwhile measure, for Python or any language. It's also important to note that the authors point out that in their samples of code, they found very high variance and large numbers of outliers: [quote] Modules where LOC does not predict CC (or vice-versa) may indicate an overly-complex module with a high density of decision points or an overly- simple module that may need to be refactored. [end quote] So *even by the terms of this paper*, it isn't true that CC has no predictive value over LOC -- if the CC is radically high or low for the LOC, that is valuable to know. Is it? What is the evidence that excess, unpredicted-by-LoC CC causes (or even correlates with) bugs? The paper points that out as a target for future research because no one has studied it yet. It may turn out to be a valid metric, but one that has a very specific utility: identifying a particular hotspot. Running CC over whole projects to compare their quality, as the OP has done, is not a valid use of even that. LoC is much simpler, easier to understand, and easier to correct than CC. Well, sure, but do you really think Perl one-liners are the paragon of bug-free code we ought to be aiming for? *wink* No, but introducing more statements and method calls to avoid if statements isn't either. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
I believe for the quality of code you produce.
Thanks.
Andriy
From: steve+comp.lang.pyt...@pearwood.info
Subject: Re: Web Frameworks Excessive Complexity
Date: Wed, 21 Nov 2012 11:43:10 +
To: python-list@python.org
On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
Counting complexity by giving a score to every statement encourages code
like this:
def bletch(x,y):
return x + {foo:y*2,bar:x*3+y,quux:math.sin(y)}.get(mode,0)
instead of:
def bletch(x,y):
if mode==foo: return x+y*2
if mode==bar: return x*4+y
if mode==quux: return x+math.sin(y) return x
Okay, this is a stupid contrived example, but tell me which of those
you'd rather work with
Am I being paid by the hour or the line?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On 21/11/2012 11:02, Andriy Kornatskyy wrote: Robert, You would never get a better product by accident. The meaning of better product might differ from team to team but you can not ignore excessive complexity. Earlier or later you get back to that code and refactor it, thus existence of such fact was driven by your intention to make it a bit better (easier to understand, to support, to cover with unit tests, etc), with a team of 20 heads you can get even further: the whole team adherence. So those drops make the overall picture better. This is what you, as a software developer, donate to what the final better product become. I think you may be misinterpreting the English idiom. I don't mean that your finger slips and randomly types out better code. I mean that by focusing on CC as a metric for improvement, you may very well end up improving the code, but it's not because you reduced the CC of the code. It's because of all of those *other* things that you talk about. Those are the things that should drive your refactoring, not CC, because they actually do cause improved code. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
Agreed. I think we have pretty much the same point of view on this. All these metrics advise you... this is again depends how you look at this. If you are a new comer to a project, you usually spend some time on code review, talk to people, read docs if any. The qa tools for static code analysis give you an initial picture, how it fits with your own vision, etc. Convince or accept? Andriy Kornatskyy To: python-list@python.org From: robert.k...@gmail.com Subject: Re: Web Frameworks Excessive Complexity Date: Wed, 21 Nov 2012 11:54:06 + On 21/11/2012 11:02, Andriy Kornatskyy wrote: Robert, You would never get a better product by accident. The meaning of better product might differ from team to team but you can not ignore excessive complexity. Earlier or later you get back to that code and refactor it, thus existence of such fact was driven by your intention to make it a bit better (easier to understand, to support, to cover with unit tests, etc), with a team of 20 heads you can get even further: the whole team adherence. So those drops make the overall picture better. This is what you, as a software developer, donate to what the final better product become. I think you may be misinterpreting the English idiom. I don't mean that your finger slips and randomly types out better code. I mean that by focusing on CC as a metric for improvement, you may very well end up improving the code, but it's not because you reduced the CC of the code. It's because of all of those *other* things that you talk about. Those are the things that should drive your refactoring, not CC, because they actually do cause improved code. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On 21/11/2012 12:17, Andriy Kornatskyy wrote: Agreed. I think we have pretty much the same point of view on this. All these metrics advise you... this is again depends how you look at this. If you are a new comer to a project, you usually spend some time on code review, talk to people, read docs if any. The qa tools for static code analysis give you an initial picture, how it fits with your own vision, etc. Convince or accept? No, we don't have the same point of view on this. I think that using metrics that have no evidence for their utility is a misleading distraction. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
Hm... what serves an evidence purpose for you? See functions at line 2619 and 2974 as an example for CC 20+: https://github.com/defnull/bottle/blob/master/bottle.py Andriy To: python-list@python.org From: robert.k...@gmail.com Subject: Re: Web Frameworks Excessive Complexity Date: Wed, 21 Nov 2012 12:26:26 + On 21/11/2012 12:17, Andriy Kornatskyy wrote: Agreed. I think we have pretty much the same point of view on this. All these metrics advise you... this is again depends how you look at this. If you are a new comer to a project, you usually spend some time on code review, talk to people, read docs if any. The qa tools for static code analysis give you an initial picture, how it fits with your own vision, etc. Convince or accept? No, we don't have the same point of view on this. I think that using metrics that have no evidence for their utility is a misleading distraction. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On 21/11/2012 12:47, Andriy Kornatskyy wrote: Hm... what serves an evidence purpose for you? Well-done empirical studies, like the one I gave you. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On Wed, Nov 21, 2012 at 9:49 AM, rh richard_hubb...@lavabit.com wrote: On Tue, 20 Nov 2012 20:41:42 +0300 Andriy Kornatskyy andriy.kornats...@live.com wrote: Cyclomatic (or conditional) complexity is a metric used to indicate the complexity of a source code. Excessive complexity is something that is beyond recommended level of 10 (threshold that points to the fact the source code is too complex and refactoring is suggested). Here is a list of web frameworks examined: bottle, cherrypy, circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py, web2py and wheezy.web. You can read more here: http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html You are the author of wheezy.web right? Can't blame you for trying to market your product. The conclusions, or lack of, are meaningless to me. I have to get in and drive the car before I go all in and buy it. I'm looking at different technology right now on which to base a site. I tried pyramid and after install it consumed 92MB of disk. It seemed large and it turns out that it installed its own version of python. Seems more complex to me, yet another python on disk. That's how virtualenvs (http://www.virtualenv.org/ ) normally work. Not really Pyramid's fault, it's more a deficiency of the current Python package management tools. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
Richard, Thank you for the comment. I have examined web frameworks for PEP8 and CC metrics already. Results are here: http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html Same applies to performance benchmarks: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html http://mindref.blogspot.com/2012/10/python-web-reverse-urls-benchmark.html http://mindref.blogspot.com/2012/10/python-web-caching-benchmark.html and template engine related: http://mindref.blogspot.com/2012/10/python-templates-benchmark.html http://mindref.blogspot.com/2012/07/python-fastest-template.html If there are any other metrics we can gather automatically I will be happy to run them. Thank you for your interest of wheezy.web. Before you buy: Demo application source: https://bitbucket.org/akorn/wheezy.web/src/tip/demos/template Demo application live: http://wheezy.pythonanywhere.com/ Tutorial: http://packages.python.org/wheezy.web/tutorial.html Finished: https://bitbucket.org/akorn/wheezy.web/src/tip/demos/guestbook Try understand what is cache dependency and how you benefit of using it with content caching. Try relate it with web caching benchmark from above and imagine 99% of your web application content is served out from cache, even it is dynamic (you control content cache with cache dependency). Thanks. Andriy Kornatskyy To: python-list@python.org From: richard_hubb...@lavabit.com Subject: Re: Web Frameworks Excessive Complexity Date: Wed, 21 Nov 2012 09:49:39 -0800 On Tue, 20 Nov 2012 20:41:42 +0300 Andriy Kornatskyy andriy.kornats...@live.com wrote: Cyclomatic (or conditional) complexity is a metric used to indicate the complexity of a source code. Excessive complexity is something that is beyond recommended level of 10 (threshold that points to the fact the source code is too complex and refactoring is suggested). Here is a list of web frameworks examined: bottle, cherrypy, circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py, web2py and wheezy.web. You can read more here: http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html You are the author of wheezy.web right? Can't blame you for trying to market your product. The conclusions, or lack of, are meaningless to me. I have to get in and drive the car before I go all in and buy it. I'm looking at different technology right now on which to base a site. I tried pyramid and after install it consumed 92MB of disk. It seemed large and it turns out that it installed its own version of python. Seems more complex to me, yet another python on disk. Anyway if you're really serious about making a point that complexity matters you'll have to measure many more things than loc or cc. Did you look at the number of commits to the same file over time? Etc. Number of authors for same file? Etc., etc. Number of security fixes? There must be a correlation between complexity and insecurity. Maybe check for randomness of the code. Not sure how, maybe look for strange, non-idiomatic uses of the language. I'm no computer scientist and I'm sure there are volumes on all this. Then there's also the social side, how much discussion takes place about the software? Does more discussion mean more problems? More project vibrancy? You could check for vocab, etc. I'm gonna take a look at wheezy.web. Thanks. Comments or suggestions are welcome. Andriy Kornatskyy -- -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On Wed, Nov 21, 2012 at 10:57 AM, rh richard_hubb...@lavabit.com wrote: On Wed, 21 Nov 2012 10:12:26 -0800 Chris Rebert c...@rebertia.com wrote: On Wed, Nov 21, 2012 at 9:49 AM, rh richard_hubb...@lavabit.com wrote: On Tue, 20 Nov 2012 20:41:42 +0300 Andriy Kornatskyy andriy.kornats...@live.com wrote: snip I'm looking at different technology right now on which to base a site. I tried pyramid and after install it consumed 92MB of disk. It seemed large and it turns out that it installed its own version of python. Seems more complex to me, yet another python on disk. That's how virtualenvs (http://www.virtualenv.org/ ) normally work. Not really Pyramid's fault, it's more a deficiency of the current Python package management tools. There's still 92MB under pyramid, I just installed a new virtualenv and installed wheezy.web, grand total 3.3MB. What deficiency? install[ing] its own version of python -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On Wed, Nov 21, 2012 at 10:43 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
Counting complexity by giving a score to every statement encourages code
like this:
def bletch(x,y):
return x + {foo:y*2,bar:x*3+y,quux:math.sin(y)}.get(mode,0)
instead of:
def bletch(x,y):
if mode==foo: return x+y*2
if mode==bar: return x*4+y
if mode==quux: return x+math.sin(y) return x
Okay, this is a stupid contrived example, but tell me which of those
you'd rather work with
Am I being paid by the hour or the line?
You're on a salary, but management specified some kind of code metrics
as a means of recognizing which of their programmers are more
productive, and thus who gets promoted.
Oh, I'm *so* glad I work in a small company. We've only had one
programmer that we let go (and actually, it was literally letting
him go - he said he was no good, hoping that we'd beg him to stay, and
we simply didn't beg him to stay), and the metric of code quality was
simply that both my boss and I looked at his code and said that it
wasn't good enough. Much simpler. (Though my boss and I have differing
views on how many lines of code some things should be. We end up
having some rather amusing debates about trivial things like line
breaks.)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On Wed, Nov 21, 2012 at 10:43 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
Counting complexity by giving a score to every statement encourages code
like this:
def bletch(x,y):
return x + {foo:y*2,bar:x*3+y,quux:math.sin(y)}.get(mode,0)
instead of:
def bletch(x,y):
if mode==foo: return x+y*2
if mode==bar: return x*4+y
if mode==quux: return x+math.sin(y) return x
Okay, this is a stupid contrived example, but tell me which of those
you'd rather work with
Oh, I'm *so* glad I work in a small company.
Agreed. Do we rate a contractor's quality of workmanship and efficiency by the
number of nails he drives?
Of course not. That would be ridiculous.
A better metric of code quality and complexity would be to borrow from science
and mathematics. i.e. a peer review or audit by others working on the project
or in the same field of study. Unfortunately this isn't cheap or easily
computed and doesn't translate nicely to a bar graph.
Such is reality.
-Modulok-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On 20/11/2012 17:41, Andriy Kornatskyy wrote: Cyclomatic (or conditional) complexity is a metric used to indicate the complexity of a source code. Excessive complexity is something that is beyond recommended level of 10 (threshold that points to the fact the source code is too complex and refactoring is suggested). Here is a list of web frameworks examined: bottle, cherrypy, circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py, web2py and wheezy.web. Cyclomatic complexity tells you nothing that counting lines of code doesn't already. http://www.scirp.org/Journal/PaperInformation.aspx?paperID=779 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
Robert, Thank you for the comment. I do not try relate CC with LOC. Instead pointing to excessive complexity, something that is beyond recommended threshold, a subject to refactoring in respective web frameworks. Those areas are likely to be potential source of bugs (e.g. due to low code coverage with unit tests) thus have certain degree of interest to both: end users and framework developers. Thanks. Andriy Kornatskyy To: python-list@python.org From: robert.k...@gmail.com Subject: Re: Web Frameworks Excessive Complexity Date: Tue, 20 Nov 2012 19:32:31 + On 20/11/2012 17:41, Andriy Kornatskyy wrote: Cyclomatic (or conditional) complexity is a metric used to indicate the complexity of a source code. Excessive complexity is something that is beyond recommended level of 10 (threshold that points to the fact the source code is too complex and refactoring is suggested). Here is a list of web frameworks examined: bottle, cherrypy, circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py, web2py and wheezy.web. Cyclomatic complexity tells you nothing that counting lines of code doesn't already. http://www.scirp.org/Journal/PaperInformation.aspx?paperID=779 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On 20/11/2012 19:46, Andriy Kornatskyy wrote: Robert, Thank you for the comment. I do not try relate CC with LOC. Instead pointing to excessive complexity, something that is beyond recommended threshold, a subject to refactoring in respective web frameworks. Those areas are likely to be potential source of bugs (e.g. due to low code coverage with unit tests) thus have certain degree of interest to both: end users and framework developers. Did you read the paper? I'm not suggesting that you compare CC with LoC; I'm suggesting that you don't use CC as a metric at all. The research is fairly conclusive that CC doesn't measure what you think it measures. The source of bugs is not excessive complexity in a method, just excessive lines of code. LoC is much simpler, easier to understand, and easier to correct than CC. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
Robert, I respect your point of view and it definitely make sense to me. I personally do not have a problem to understand CC but agree, method LoC is easier to understand. Regardless the path your choose in your next refactoring (based on method CC, LoC) it gives your better product. Andriy To: python-list@python.org From: robert.k...@gmail.com Subject: Re: Web Frameworks Excessive Complexity Date: Tue, 20 Nov 2012 20:07:54 + On 20/11/2012 19:46, Andriy Kornatskyy wrote: Robert, Thank you for the comment. I do not try relate CC with LOC. Instead pointing to excessive complexity, something that is beyond recommended threshold, a subject to refactoring in respective web frameworks. Those areas are likely to be potential source of bugs (e.g. due to low code coverage with unit tests) thus have certain degree of interest to both: end users and framework developers. Did you read the paper? I'm not suggesting that you compare CC with LoC; I'm suggesting that you don't use CC as a metric at all. The research is fairly conclusive that CC doesn't measure what you think it measures. The source of bugs is not excessive complexity in a method, just excessive lines of code. LoC is much simpler, easier to understand, and easier to correct than CC. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On 20/11/2012 20:22, Andriy Kornatskyy wrote: Robert, I respect your point of view and it definitely make sense to me. I personally do not have a problem to understand CC but agree, method LoC is easier to understand. Regardless the path your choose in your next refactoring (based on method CC, LoC) it gives your better product. No, refactoring based on CC does not give you a better product, except by accident. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Frameworks Excessive Complexity
On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote: The source of bugs is not excessive complexity in a method, just excessive lines of code. Taken literally, that cannot possibly the case. def method(self, a, b, c): do_this(a) do_that(b) do_something_else(c) def method(self, a, b, c): do_this(a); do_that(b); do_something_else(c) It *simply isn't credible* that version 1 is statistically likely to have twice as many bugs as version 2. Over-reliance on LOC is easily gamed, especially in semicolon languages. Besides, I think you have the cause and effect backwards. I would rather say: The source of bugs is not lines of code in a method, but excessive complexity. It merely happens that counting complexity is hard, counting lines of code is easy, and the two are strongly correlated, so why count complexity when you can just count lines of code? Keep in mind that something like 70-80% of published scientific papers are never replicated, or cannot be replicated. Just because one paper concludes that LOC alone is a better metric than CC doesn't necessary make it so. But even if we assume that the paper is valid, it is important to understand just what it says, and not extrapolate too far. The paper makes various assumptions, takes statistical samples, and uses models. (Which of course *any* such study must.) I'm not able to comment on whether those models and assumptions are valid, but assuming that they are, the conclusion of the paper is no stronger than the models and assumptions. We should not really conclude that CC has no more predictive power than LOC. The right conclusion is that one specific model of cyclic complexity, McCabe's CC, has no more predictive power than LOC for projects written in C, C++ and Java. How does that apply to Python code? Well, it's certainly suggestive, but it isn't definitive. It's also important to note that the authors point out that in their samples of code, they found very high variance and large numbers of outliers: [quote] Modules where LOC does not predict CC (or vice-versa) may indicate an overly-complex module with a high density of decision points or an overly- simple module that may need to be refactored. [end quote] So *even by the terms of this paper*, it isn't true that CC has no predictive value over LOC -- if the CC is radically high or low for the LOC, that is valuable to know. LoC is much simpler, easier to understand, and easier to correct than CC. Well, sure, but do you really think Perl one-liners are the paragon of bug-free code we ought to be aiming for? *wink* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
