SoylentNews is people
SoylentNews
O'Reilly and Software Improvement Group conducted a survey about secure coding: https://www.oreilly.com/ideas/the-alarming-state-of-secure-coding-neglect
Much of it is as expected but I stumbled upon this tidbit:
"[Static analysis] was reported as being used by 25% of respondents. One-third of those who didn't use it said it was too expensive. The rest of the non-users were fairly evenly divided among other explanations: tools were not available for their technology, were too hard to use, had too many false positives, or were not usable in Agile development."
When developing I have almost always used compiler warnings (gcc/acc/icc/cxx/clang) and dedicated tools cppcheck/flexelint/coverity-scan/pvs-studio/clang-analyze so the above snippet depressed me because catching errors sooner rather than later makes them much cheaper to fix. Static analysis tools can require much configuration, can be expensive, and be time-consuming, and I guess that for some languages such tools don't even exist. The part about static analysis tools not fitting a development process struck me as downright odd.
What is your take on this? Why aren't you using static analysis (and if you do: which one and for what?)
(Score: 2) by bziman on Wednesday May 10 2017, @05:39AM (4 children)
I've been a professional software engineer for twenty years, all of it with Java, and for the past few years, I've had access to static analysis tools, and it has definitely made my code better, and it has probably made me a better engineer, too. Why not use the available tools? Even my colleagues who prefer vi to a modern IDE still benefit from the static analysis tools. And our code is better for it.
(Score: 4, Insightful) by Anonymous Coward on Wednesday May 10 2017, @05:45AM
> I've been a professional software engineer for twenty years, all of it with Java,
Crap. You just made me feel really old.
(Score: 0) by Anonymous Coward on Wednesday May 10 2017, @07:00AM
Professional means you get paid to do it, right?
(Score: 2) by Nerdfest on Wednesday May 10 2017, @10:04AM
Likewise. There are some good tools for JavaScript as well. Things Like Sonar that run a set of static analysis tools as part of the build process and track the results work very well too. You can see the improvement (or degradation) of your code base. Sonar works with a series of plugins that let you analyze potential bugs, style, test coverage, complexity, etc. I saw one clever one that shows this as technical debt in monetary term. Not likely very accurate, but a good tool to give "management" an idea of the costs of poor code.
(Score: 1) by isj on Wednesday May 10 2017, @01:09PM
That has also been my experience. My code became better/clearer after I started using a dedicated tool.
I think it is a combination of understanding what is dubious code constructs, and also knowing that the tool will point them out to me (so might as well not make them)