2

(Building on this question)

If you have a static code analyser such as Checkstyle, is it possible to to relate any of the stuff that it checks for to actual robustness? Some of the things that Checkstyle checks for are e.g.:

  • Class design: Visibility of class members, enforcing public only static final members, no public constructors for utility classes, exceptions are immutable etc.
  • Coding: Inline conditionals, no empty statements, no illegal instantiation and magic numbers
  • Duplication: Checks for code duplication,
  • Import: Checks that packages are imported correctly
  • Metrics: Checks everything from the number of times logical operators have been used in a statement to the number of classes that the given class relies on other classes (coupling) etc.
  • Naming Conventions: Checks many properties of variable name, package names, method names, class names etc

These are just some of the main things that Checkstyle checks for. Could any of these areas actually help "improve" the robustness of the code by detecting "errors" ? I mean sure it helps with the readability and other code smells, but I can't see how I can relate it to robustness.

Do you need to look at code in run-time to actually inspect robustness issues?

Community
  • 1
Force444
  • 643
  • 2
  • 7
  • 13

2 Answers2

4

Code that is well-designed and well-written is more robust, because it minimizes edge cases and rabbit holes that are more prevalent in code that doesn't follow "best practices."

Static analysis helps code robustness for the same reasons that static types do; you catch problems earlier in the coding cycle, because the compiler will tell you you're doing it wrong. Folks who use dynamically-typed languages benefit from a more relaxed coding style, but must compensate for the lack of static typing by writing more unit tests.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 1
    +1000 for stating than dynamically-typed languages require more fastidious programmers in order to generate robust code that strict-typed ones. I got a question closed for asking just that http://programmers.stackexchange.com/questions/161798/is-it-easier-to-write-robust-code-in-compiled-strictly-typed-languages. – Tulains Córdova May 22 '14 at 20:48
  • 1
    I would add that there's evidence that suggests that [unit testing isn't enough to make up for dynamic typing](http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-enough-you-need.html) and that people don't really make use of dynamic typing for things that can't be done in a good static type system. That and type inference makes the verbosity of static typing go away. – Doval May 22 '14 at 20:49
  • @Doval Why add that? It doesn't appear to be relevant to the question, which is about static analysis outside of typing. Your personal opinion on X (e.g. for X = dynamic typing) and your reasons for it don't need to be carried into every single question and shouted from every rooftop. –  May 22 '14 at 21:00
  • @delnan I didn't mean to imply that it's essential to the answer and should be edited in; I chose poor wording. But the questioner DID ask if you need to look at code at runtime to ensure robustness, and I'm pointing out that that may not be sufficient (unit tests are a sort of runtime check) unless you were incredibly exhaustive, which almost no one is. Even full test coverage isn't sufficient, since that only tests that every line of code has been exercised at least once, but doesn't test every possible combination. – Doval May 22 '14 at 21:04
-1

All six points you mention help the long-term robustness and reliability of the software during maintenance.

Other static analysis tools help in different ways. Some examples:

  • SPARK tries to prove that no exceptions will ever be raised during execution.
  • GCC tries to detect uninitialised variables and dead branches.
Jacob Sparre Andersen
  • 314
  • 1
  • 5
  • "help the long-term robustness and reliability of the software during maintenance" -- is this merely your opinion or you can back it up / explain it somehow? – gnat May 23 '14 at 07:08
  • »This margin is a bit too small for my proof« ;-) More seriously, SQALE (see for example http://dl.acm.org/citation.cfm?id=2018035) counts at least point 2, 3, 5 and 6 as adding to the technical debt in a project. As technical debt is (roughly) a measure of the built-in cost of future maintenance, there exists at least a strong indication that those points are relevant for the robustness of the software during maintenance. - Until I get around to write down a detailed argument, you are welcome to insist that the rest is only opinion. – Jacob Sparre Andersen May 26 '14 at 07:33