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 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
  • 200,592
-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