-
Notifications
You must be signed in to change notification settings - Fork 0
Scalastyle proposed rules (Coding)
This page contains proposed rules for Scalastyle, for the category Coding.
Detects empty statements (standalone ;).
Checks that local variables that never have their values changed are declared val. The check can be configured to also check that unchanged parameters are declared val.
Checks that a local variable or a parameter does not shadow a field that is defined in the same class.
Checks that pattern matches have "_" clause. Rationale: It's usually a good idea to introduce a default case in every pattern match statement. Even if the developer is sure that all currently possible cases are covered, this should be expressed in the default branch, e.g. by using an assertion. This way the code is protected aginst later changes, e.g. introduction of new types in an enumeration type.
Checks for redundant exceptions declared in throws clause such as duplicates, unchecked exceptions or subclasses of another declared exception.
Restricts nested for blocks to a specified depth (default = 1).
Restricts nested if-else blocks to a specified depth (default = 1).
Restricts nested try blocks to a specified depth (default = 1).
Checks that an overriding clone() method invokes super.clone(). Reference: Object.clone().
Checks that an overriding finalize() method invokes super.finalize(). Reference: Cleaning Up Unused Objects.
Catching java.lang.Exception, java.lang.Error or java.lang.RuntimeException is almost never acceptable. Rationale: Junior developers often simply catch Exception in an attempt to handle multiple exception classes. This unfortunately leads to code that inadvertantly catchs NPE, OutOfMemoryErrors, etc.
This check can be used to ensure that types are not declared to be thrown. Declaring to throw java.lang.Error or java.lang.RuntimeException is almost never acceptable.
Ensure a class has a package declaration, and (optionally) whether the package name matches the directory name for the source file. Rationale: Classes that live in the null package cannot be imported. Many novice developers are not aware of this.
Checks that particular class are never used as types in variable declarations, return values or parameters. Includes a pattern check that by default disallows abstract classes. Rationale: Helps reduce coupling on concrete classes. In addition abstract classes should be thought of a convenience base class implementations of interfaces and as such are not types themselves.
[MJF] TODO to be updated to fit in with Scala Style guide According to Code Conventions for the Java Programming Language , the parts of a class or interface declaration should appear in the following order:
- Class (static) variables. First the public class variables, then the protected, then package level (no access modifier), and then the private.
- Instance variables. First the public class variables, then the protected, then package level (no access modifier), and then the private.
- Constructors
- Methods
[MJF] update for Scala style guide Checks that each variable declaration is in its own statement and on its own line. Rationale: the SUN Code conventions chapter 6.1 recommends that declarations should be one per line/statement.
Checks for the use of unnecessary parentheses.
Checks there is only one statement per line. The following line will be flagged as an error:
x = 1; y = 2; // Two statements on a single line.
Avoid null during initialization of overriding val: see https://github.com/paulp/scala-faq/wiki/Initialization-Order. override val (with no 'lazy') or override def when abstract definition is a val and we are not in an early initialization block.
- early-init: accept only early-initialization block
- lazy val: accept only lazy val
- both