```scala Bad theme={null} if (((condition1 && condition2) || (condition3 && condition4)) && condition5) { ... } ``` ```scala Fix theme={null} if ((myFirstCondition || mySecondCondition) && myLastCondition) { ... } ```

A \`match and a chain of if/else if statements is evaluated from top to bottom. At most, only one branch will be executed: the first one with a condition that evaluates to true.

Therefore, duplicating a condition automatically leads to dead code. Usually, this is due to a copy/paste error. At best, it’s simply dead code and at worst, it’s a bug that is likely to induce further bugs as the code is maintained, and obviously it could lead to unexpected behavior.

For a match, the second case\` will never be executed, rendering it dead code. Worse there is the risk in this situation that future maintenance will be done on the dead case, rather than on the one that’s actually used.

```scala Bad theme={null} if (param == 1) { openWindow } else if (param == 2) { closeWindow } else if (param == 1) { // Noncompliant moveWindowToTheBackground } param match { case 1 => // ... case 3 => // ... case 1 => // Noncompliant // ... case _ => //... } ``` ```scala Fix theme={null} if (param == 1) { openWindow } else if (param == 2) { closeWindow } else if (param == 3) { moveWindowToTheBackground } param match { case 1 => // ... case 3 => // ... case _ => //... } ```

Jump statements (return) move control flow out of the current code block. So any statements that come after a jump are dead code.

```scala Bad theme={null} def foo(a: Int) { val i = 10; return a + i; // Noncompliant bar; // dead code } ``` ```scala Fix theme={null} def foo(a: Int): Int { val i = 10; return a + i; } ```

This rule applies whenever an \`if statement is followed by one or more else if statements; the final else if should be followed by an else statement.

The requirement for a final else statement is defensive programming.

The else statement should either take appropriate action or contain a suitable comment as to why no action is taken. This is consistent with the requirement to have a final case \_ clause in a match\`.

```scala Bad theme={null} if (x == 0) { doSomething } else if (x == 1) { doSomethingElse } ``` ```scala Fix theme={null} if (x == 0) { doSomething } else if (x == 1) { doSomethingElse } else { throw new IllegalStateException } ```

For example, with the default provided regular expression ^(\[a-z]\[a-zA-Z0-9]\*+(\_\[^a-zA-Z0-9])?+|)\$, the function:

```scala Bad theme={null} def DoSomething( ) : Unit = { // Noncompliant // ... } ``` ```scala Fix theme={null} def doSomething( ) : Unit = { // ... } ```

The match statement should be used only to clearly define some new branches in the control flow. As soon as a case clause contains too many statements this highly decreases the readability of the overall control flow statement. In such case, the content of the case clause should be extracted into a dedicated method.

```scala Bad theme={null} myVariable match { case 0 => // Noncompliant: 6 lines till next case methodCall1() methodCall2() methodCall3() methodCall4() methodCall5() case 1 => // ... } ``` ```scala Fix theme={null} myVariable match { case 0 => doSomething() case 1 => // ... } // ... def doSomething(): Unit = { methodCall1() methodCall2() methodCall3() methodCall4() methodCall5() } ```

Having all branches of a match or if chain with the same implementation indicates a problem.

In the following code:

```scala Bad theme={null} if (b == 0) { // Noncompliant doSomething } else { doSomething } i match { // Noncompliant case 1 => doSomething case 2 => doSomething case 3 => doSomething case _ => doSomething } ``` ```scala Fix theme={null} if (b == 0) { doSomething } else if (b == 1) { doSomething } ```

The requirement for a final case \_ clause is defensive programming. The clause should either take appropriate action, or contain a suitable comment as to why no action is taken.

```scala Bad theme={null} param match { case 1 => doSomething case 2 => doSomethingElse } ``` ```scala Fix theme={null} param match { case 1 => doSomething case 2 => doSomethingElse case _ => throw new IllegalArgumentException(s"Unexpected param: $param") } ```

Nested \`match structures are difficult to understand because you can easily confuse the cases of an inner match as belonging to an outer statement. Therefore nested match statements should be avoided.

Specifically, you should structure your code to avoid the need for nested match statements, but if you cannot, then consider moving the inner match\` to another function.

```scala Bad theme={null} def foo(n: Int, m: Int): Unit = { n match { case 0 => m match { case 0 => // ... } case 1 => // ... } } ``` ```scala Fix theme={null} def foo(n: Int, m: Int): Unit = { n match { case 0 => bar(m) case 1 => // ... } } def bar(m: Int): Unit = { m match { case 0 => // ... } } ```

It is needlessly complex to invert the result of a boolean comparison. The opposite comparison should be made instead.

```scala Bad theme={null} if (!(a == 2)) { ...} // Noncompliant val b = !(i < 10) // Noncompliant ``` ```scala Fix theme={null} if (a != 2) { ...} val b = (i >= 10) ```

Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.

Unresolved directive in \ - include::\{noncompliant}\[]

Write one statement per line to improve readability.

Unresolved directive in \ - include::\{compliant}\[]

```scala Bad theme={null} println("Hello"); println("world!") // Noncompliant ``` ```scala Fix theme={null} println("Hello") println("world!") ```

A boolean literal can be represented in two different ways: \{true} or \{false}. They can be combined with logical operators (\{ops}) to produce logical expressions that represent truth values. However, comparing a boolean literal to a variable or expression that evaluates to a boolean value is unnecessary and can make the code harder to read and understand. The more complex a boolean expression is, the harder it will be for developers to understand its meaning and expected behavior, and it will favour the introduction of new bugs.

```scala Bad theme={null} if (booleanMethod() || false) { /* ... */ } doSomething(!false) booleanVariable = if (booleanMethod()) true else false booleanVariable = if (booleanMethod()) true else exp booleanVariable = if (booleanMethod()) false else exp booleanVariable = if (booleanMethod()) exp else true booleanVariable = if (booleanMethod()) exp else false ``` ```scala Fix theme={null} if (booleanMethod()) { /* ... */ } doSomething(true) booleanVariable = booleanMethod() booleanVariable = booleanMethod() || exp booleanVariable = !booleanMethod() && exp booleanVariable = !booleanMethod() || exp booleanVariable = booleanMethod() && exp ```

Nested code - blocks of code inside blocks of code - is eventually necessary, but increases complexity. This is why keeping the code as flat as possible, by avoiding unnecessary nesting, is considered a good practice.

Merging if statements when possible will decrease the nesting of the code and improve its readability.

```scala Bad theme={null} if (condition1) { if (condition2) { // Noncompliant /* ... */ } } ``` ```scala Fix theme={null} if (condition1 && condition2) { // Compliant /* ... */ } ```

An empty \{operationName} is generally considered bad practice and can lead to confusion, readability, and maintenance issues. Empty \{operationName}s bring no functionality and are misleading to others as they might think the \{operationName} implementation fulfills a specific and identified requirement.

There are several reasons for a \{operationName} not to have a body:

It is an unintentional omission, and should be fixed to prevent an unexpected behavior in production.
It is not yet, or never will be, supported. In this case an exception should be thrown.
The method is an intentionally-blank override. In this case a nested comment should explain the reason for the blank override.

```scala Bad theme={null} def shouldNotBeEmpty() = { // Noncompliant - method is empty } def notImplementedYet() = { // Noncompliant - method is empty } def willNeverBeImplemented() = { // Noncompliant - method is empty } def emptyOnPurpose() = { // Noncompliant - method is empty } ``` ```scala Fix theme={null} def shouldNotBeEmpty() = { doSomething() } def notImplementedYet() = { throw new NotImplementedError() } def willNeverBeImplemented() = { throw new UnsupportedOperationException() } def emptyOnPurpose() = { // comment explaining why the method is empty } ```

The use of parentheses, even those not required to enforce a desired order of operations, can clarify the intent behind a piece of code. However, redundant pairs of parentheses could be misleading and should be removed.

```scala Bad theme={null} val x = ((y / 2 + 1)) // Noncompliant if (a && ((x + y > 0))) { // Noncompliant return ((x + 1)) // Noncompliant } ``` ```scala Fix theme={null} val x = (y / 2 + 1) if (a && (x + y > 0)) { return (x + 1) } ```

There is no reason to re-assign a variable to itself. Either this statement is redundant and should be removed, or the re-assignment is a mistake and some other value or variable was intended for the assignment instead.

```scala Bad theme={null} def doSomething() = { var name = "" // ... name = name } ``` ```scala Fix theme={null} def doSomething() = { var name = "" // ... this.name = name } ```

Duplicated string literals make the process of refactoring complex and error-prone, as any change would need to be propagated on all occurrences.

```scala Bad theme={null} public def run() { prepare("action random1") // Noncompliant - "action random1" is duplicated 3 times execute("action random1") release("action random1") } ``` ```scala Fix theme={null} public def run() { val Action = "action random1" prepare(Action) execute(Action) release(Action) } ```

Two \{func\_name}s having the same implementation are suspicious. It might be that something else was intended. Or the duplication is intentional, which becomes a maintenance burden.

```scala Bad theme={null} class Circle(var radius: Int) { def width_=(size: Int) { radius = size / 2 updateShape() } def height_=(size: Int) { // Noncompliant: duplicates width_ radius = size / 2 updateShape() } def updateShape() = {...} } ``` ```scala Fix theme={null} class Circle(var radius: Int) { def width_=(size: Int) { diameter = size } def height_=(size: Int) { diameter = size } def diameter_=(size: Int) { // Implementation is shared radius = size / 2 updateShape() } def updateShape() = {...} } ```

Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:

Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:

The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
It misleads to use the same address in every environment (dev, sys, qa, prod).

Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.

```scala Bad theme={null} val ips = Source.fromFile(configuration_file).getLines.toList // Compliant val socket = new Socket(ips(0), 6667) ``` ```scala Fix theme={null} ```

This rule raises an issue when a \{visibility} \{operationName} is never referenced in the code.

```scala Bad theme={null} class Foo extends Serializable { private def unusedMethod(): Unit = {...} // Noncompliant private def writeObject(s: ObjectOutputStream): Unit = {...} // Compliant, relates to the serialization mechanism private def readObject(s: ObjectInputStream): Unit = {...} // Compliant, relates to the serialization mechanism } ``` ```scala Fix theme={null} class Foo extends Serializable { private def writeObject(s: ObjectOutputStream): Unit = {...} // Compliant, relates to the serialization mechanism private def readObject(s: ObjectInputStream): Unit = {...} // Compliant, relates to the serialization mechanism } ```

\`if statements with conditions that are always false have the effect of making blocks of code non-functional. if statements with conditions that are always true are completely redundant, and make the code less readable.

There are three possible causes for the presence of such code:

An if statement was changed during debugging and that debug code has been committed.
Some value was left unset.
Some logic is not doing what the programmer thought it did.

In any of these cases, unconditional if\` statements should be removed.

```scala Bad theme={null} if (true) { doSomething } // ... if (false) { doSomethingElse } ``` ```scala Fix theme={null} doSomething // ... ```

An unused local variable is a variable that has been declared but is not used anywhere in the block of code where it is defined. It is dead code, contributing to unnecessary complexity and leading to confusion when reading the code. Therefore, it should be removed from your code to maintain clarity and efficiency.

```scala Bad theme={null} def numberOfMinutes(hours: Int): Int = { var seconds = 0 // Noncompliant - seconds is unused val result = hours * 60 result } ``` ```scala Fix theme={null} def numberOfMinutes(hours: Int): Int = { val result = hours * 60 result } ```

A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes. \{identifier\_capital\_plural} hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern. Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.

This rule checks that \{identifier} names match a provided regular expression.

```scala Bad theme={null} def printSomething(text_param: String): Unit = { // Noncompliant var _1LOCAL = "" // Noncompliant println(text_param + _1LOCAL) } ``` ```scala Fix theme={null} def printSomething(textParam: String): Unit = { var LOCAL = "" println(textParam + LOCAL) } ```