4 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

(Building on this question 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?

(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?

(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?

3 edited tags
| link
    Tweeted twitter.com/#!/StackProgrammer/status/469649200444354560
2 added 1 character in body
source | link

(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 importspackages 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?

(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 imports 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?

(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?

1
source | link