Had anyone ever had an idea to measure code complexity of popular libs / frameworks such as pandas or Django , with this nice tool? That would be a nice research.
Anyone who is willing to use radon and wily should also read this: avandeursen.com/2014/08/29/think-twice-before-using-the-maintainability-index/ In particular the original formula is for languages like C and pascal, but it hasn't been updated fo python.
Let me summarize the article: You should use lines of code because the weights in the equation for maintainability index are partly empirical and partly opinion. They were derived for other languages which vary a lot from python. Also LOC is stupid simple to use. But he doesn't have any compelling arguments to detract from the fundamental measures derived in the process of calculating MI, or any counter points to the issues with using lines of code blindly in languages like python where there can be strong motivation toward complex one liners that can make for heavy lines of code. Nor does propose anything better. I think the middle ground is to use the raw metrics for your project and modules, and to use good judgement when reviewing pull requests. There is no substitute for peer review and MI is no silver bullet. Technical debt if left untended will compound. Developers should learn to be mindful of technical debt, and as with all chores in programming we'll try to automate it. But these tools are never a substitute for experience and sound judgement, and if used as a blunt object to bludgeon your team will cause more harm than good.
05:12 Cyclomatic Complexity
10:12 Halstead Metrics
13:18 Maintainability Index
14:56 Radon
16:12 Wily
16:54 Demo
20:08 Gravity of Complexity
21:36 Testing and refactoring
24:01 Summary
26:40 QnA
Had anyone ever had an idea to measure code complexity of popular libs / frameworks such as pandas or Django , with this nice tool? That would be a nice research.
Loved the readability counts joke :)
yeah me too
Great Pycon talk, you should definitely do more of those
Nice talk. Would have appreciated some more complex practical examples of good refactoring from complex->simpler code.
I will be using Wily :)
Very useful tool in production! Thank you, authors.
Excellent talk and tool.
I really enjoyed that talk thanks.
Do we have a github action file/docs for wiley ?
Oooh, that's clever!
How to record and (visually) replay the keystrokes on the shell, as he shows at around 17:00?
Is there a way to identify why cc or mi affected?
github link mentioned is not correct. it opens "page not found". could not get the slides from speakerdeck as well. :( Please help.
My website is tonybaloney.github.io/ that should have a link to most of the related repos. Wily is at github.com/tonybaloney/wily
@@AnthonyShaw Awesome talk man. People like you makes me love python.
Anyone who is willing to use radon and wily should also read this:
avandeursen.com/2014/08/29/think-twice-before-using-the-maintainability-index/
In particular the original formula is for languages like C and pascal, but it hasn't been updated fo python.
Let me summarize the article: You should use lines of code because the weights in the equation for maintainability index are partly empirical and partly opinion. They were derived for other languages which vary a lot from python. Also LOC is stupid simple to use.
But he doesn't have any compelling arguments to detract from the fundamental measures derived in the process of calculating MI, or any counter points to the issues with using lines of code blindly in languages like python where there can be strong motivation toward complex one liners that can make for heavy lines of code. Nor does propose anything better.
I think the middle ground is to use the raw metrics for your project and modules, and to use good judgement when reviewing pull requests. There is no substitute for peer review and MI is no silver bullet.
Technical debt if left untended will compound. Developers should learn to be mindful of technical debt, and as with all chores in programming we'll try to automate it. But these tools are never a substitute for experience and sound judgement, and if used as a blunt object to bludgeon your team will cause more harm than good.