Scalastyle proposed rules (Miscellaneous)

This page contains proposed rules for Scalastyle, section Miscellaneous.

Miscellaneous

TodoComment

A check for TODO: comments. Actually it is a generic regular expression matcher on Scala comments. To check for other patterns in Scala comments, set property format.

Translation

A FileSetCheck that ensures the correct translation of code by checking property files for consistency regarding their keys. Two property files describing one and the same context are consistent if they contain the same keys. Consider the following properties file in the same directory: #messages.properties hello=Hello cancel=Cancel

#messages_de.properties
hell=Hallo
ok=OK

The Translation check will find the typo in the german hello key, the missing ok key in the default resource file and the missing cancel key in the german resource file:

messages_de.properties: Key 'hello' missing.
messages_de.properties: Key 'cancel' missing.
messages.properties: Key 'hell' missing.
messages.properties: Key 'ok' missing.

UncommentedMain

Checks for uncommented main() methods (debugging leftovers). Rationale: A main() method is often used for debug puposes. When debugging is finished, developers often forget to remove the method, which changes the API and increases the size of the resulting class/jar file. With the exception of the real program entry points, all main() methods should be removed/commented out of the sources.

Indentation

Checks correct indentation of Scala Code. The basic idea behind this is that while pretty printers are sometimes convienent for bulk reformats of legacy code, they often either aren't configurable enough or just can't anticipate how format should be done. Sometimes this is personal preference, other times it is practical experience. In any case, this check should just ensure that a minimal set of indentation rules are followed.

TrailingComment

The check to ensure that requires that comments be the only thing on a line. For the case of // comments that means that the only thing that should precede it is whitespace. It doesn't check comments if they do not end line, i.e. it accepts the following:

Thread.sleep( 10 /*some comment here*/ ).

Rationale: Steve McConnel in "Code Complete" suggests that endline comments are a bad practice. An end line comment would be one that is on the same line as actual code. For example:

a = b + c; // Some insightful comment
d = e / f; // Another comment for this line

Quoting "Code Complete" for the justfication:

• "The comments have to be aligned so that they do not interfere with the visual structure of the code. If you don't align them neatly, they'll make your listing look like it's been through a washing machine."
• "Endline comments tend to be hard to format...It takes time to align them. Such time is not spent learning more about the code; it's dedicated solely to the tedious task of pressing the spacebar or tab key."
• "Endline comments are also hard to maintain. If the code on any line containing an endline comment grows, it bumps the comment farther out, and all the other endline comments will have to bumped out to match. Styles that are hard to maintain aren't maintained...."
• "Endline comments also tend to be cryptic. The right side of the line doesn't offer much room and the desire to keep the comment on one line means the comment must be short. Work then goes into making the line as short as possible instead of as clear as possible. The comment usually ends up as cryptic as possible...."
• "A systemic problem with endline comments is that it's hard to write a meaningful comment for one line of code. Most endline comments just repeat the line of code, which hurts more than it helps."
• His comments on being hard to maintain when the size of the line changes are even more important in the age of automated refactorings.

OuterTypeFilename

Checks that the outer type name and the file name match. For example, the class Foo must be in a file named Foo.scala.

PackageNameEqualsFSName

Checks that the package name and the path to the filesystem match. Even though Scala let a package declaration can differ in its value from the path of the current file (� la Java), it could still be a good practice to enforce this symmetry. Some tools require it and it make it easier to browse into the project.

Possible Incorrect Semicolon Inference

Checks if a semicolon is inferred at a position where it should not be inferred.

def f = 10
  +3

In this example +3 is dead code because a semicolon in inferred after 10.

##Allow Early Return Without Return Value Early return statements should be allowed when their only sense is to halt method execution. All other return statements should raise an error.

def f(i: Int) {
  if (isInvalid(i)) return
  ...
}