What is static analysis? Analysis which evaluates a snapshot of source code without running it. Static analysis includes: - Cyclomatic complexity, - ABC metric, - Duplicate code detection, - many kind of checkers, - and very original scoring tool, Flog.
Cyclomatic complexity? What is that? Can you draw control flow graphs of any of your methods? A graph consists of nodes and edges, right? Cyclomatic complexty is calculated as e - n + 2 where e and n are the number of edges and nodes. so, the cyclomatic complexity of this is “2”.
OK. So, what is it good for? It suggests the number of tests the method ought to have. And of course, it represents how hard the method is to understand.
I see. Which tool do I use to get that cyclomatic complexity? There is Saikuro. The fork of metricfu is maintained on Github. Roodi, a source code checker, has a couple of check items based on cyclomatic complexity.
Huh. Is it really of any help? Cyclomatic complexity provides one point of view on how to examine code. The more views you consider, the more findings you get.
OK. What view does ABC metric provide? ABC stands for “Assign”, “Branch”, and “Condition”. These are the basic elements of imperative programming languages like Ruby. ABC metric indicates magnitude of code with the following formula: where a, b, and c are the number of assigns, branches, and conditions respectively.
OK. How do you use these magnitude values? Imagine a bloated method which fills your entire editor window. Bloated methods like that signal the beginning of software decay.
What is bloated? At what value should we fix the code? It’s up to development teams. Metrics provide a sign of issues, and only that. If you want a precise criteria, base it on past records. If you set a target too high, your team will get exhausted.
I’ve heard of Flog. Isn’t it better than ABC? Good point. Metric_ABC and Flog are similar. And Flog provides another point of view. It emphasizes how hard code is to test. e.g., it gives relatively high points to `eval’. It’s not a generic algorithm, but specific to Ruby.
Cyclomatic complexity, ABC metric, and Flog. Which one should I use? Let’s say you are hiring, how many perspectives do you need at job interviews? Like perspectives, a single tool can be easily cheated. Would you like to know more?
Sure. I guess there are many source code checkers out there. True. One of the most important checkers is duplicate code detector. Ruby has Flay for that.
So it detects copy-pastes to DRY up the code? Yes, it compares portions of code grammatically. That is, differences of variable names, literals, and other non-significant words are ignored when matching.
Sounds nice. What about other checkers? Reek, Cane, and Roodi are all similar tools. They checks things like long methods, assignments in conditionals, documentation, and many more.
Is 100% coverage possible? It depends on the layer. For business logic, you can go for 100%. But what’s important is to be realistic. That is the same for both coverage and static metrics.
Last question: What’s statistical analysis? Statistical analysis predicts software defects based on the modification history. It is known that frequently changed code blocks are more likely to have bugs. Do you use any version control system like Git? Then you are ready!
Sweet. The name of the statistical analysis tool, please? There are a few of them. Churn provides method level analysis. Bugspots is an implementation of the bug prediction heuristic at Google. It uses only “fixing” commits, and works at the file level.
How should we use these predictions? Does your team perform code review? How long does it take? Is it efficient enough? What if you know hotspots prior to the review?
irohiroki
pulse1923
skanehira
psj59129
kazue
gmvalentino8
ntsk
kiyoshiro
shimabox
murabayashi
shibe23
_tanako
hirodragon112
brianwarren
brettharned
mza
malarkey
cassininazir
palkan
62gerente
notwaldorf
zakiwarfel
geeforr
lynnandtonic
tammielis