Scala

Unreachable code is usually a result of programming error - usually when statements like 'return' are misplaced. This causes some part of the code to not execute at all, thus affecting the overall control-flow and behaviour of the program.

Empty interpolated string is usually a result of human error - either that the programmer forgot to specify the required arguments, or that the string wasn't meant to be interpolated. Such strings can critically alter the behaviour and control-flow of the program if the program relies on it.

Duplicate cases in pattern matching are unreachable and are usually the result of human error. Because such cases are unreachable, they have the potential to affect the overall control-flow and the behaviour of the program. It is suggested that you remove such duplicate cases.

Comparing two Arrays using .deep is deprecated and is not supported beyond Scala version 2.12. To avoid compilation errors when moving to version 2.13 and above, consider switching to a more well supported alternative.

By default, case class' parameters are accessible from both outside and inside the class. Therefore, marking them with the val keyword is no longer necessary and is redundant.

Using the standard i % 2 == 0 oddness check fails for -ve numbers. The preferred way is: i % 2 != 0 since +ve numbers leave +1 as remainder and -ve numbers leave -1 as remainder.

String.format() requires that you supply all the arguments corresponding to the format specifiers. Missing arguments usually leads to an improperly formatted string. Such strings can critically alter the behaviour and control-flow of the program if the program relies on it.

Not specifying the return type of a method is part of the procedural syntax and is deprecated. In such cases, the compiler assumes that the return type of such method is Unit. Any explicit return statements inside such methods have no effect and are discarded.

A duplicate key exists in the HashMap. This may lead to an unintentional behaviour as the key will always map to the last value provided to it and hence is always recommended that these keys be unique.

A duplicate element exists in the HashSet. This adds no value as the structure HashSet always maintains elements that are unique and distinct from each other and is usually a result of a human-error. It is suggested that you remove such duplicate elements.

Explicit trapping of NullPointerException is considered a bad practice in both Scala and Java. It usually means that your application has come across a null reference in an unexpected manner which you're trying to suppress by explicitly trapping through a catch block rather than finding the root cause. Since this was unexpected, it is probably not safe for your application to continue with the execution.

Another idea is to rely on Option[T] instead of null. Have your methods return Some(_) if the call succeeds and None if the call fails, an approach taken by many of Scala's built-in methods. If you truly have to rely on null, use if-else to explicitly check for null references rather than relying on try-catch.

The specified if condition depends on a boolean value that is a constant and changes neither at compile-time nor at runtime. This is likely due to a human error and is expected that this constant value is replaced with an appropriate condition that can be evaluated as necessary. Without this fix, it is expected that this if condition can potentially alter the logic of your program, thus affecting the overall behavior of your program.

The general practice when pattern-matching is to cover as many scenarios as possible. If none of the specified cases match the provided input, scala.MatchError exception is thrown during the runtime. If you wish to match only a small subset of scenarios, it is recommended to add an additional case that handles the rest of the scenarios through the usage of a wildcard - case _ => ....

Analyzer has detected that the case Some(_) was specified in the pattern-matching but not None. The general consensus is that any method that wraps a value in Some usually has a return type of Option[T]. In case the method succeeds, Some(_) is returned, else None. Therefore it is recommended that you add the missing case None in your pattern-matching.

This infix operator has the same operand on both sides.

The same code is duplicated in the then and else blocks of this if expression, meaning that regardless of whether this condition is true or false, the program executes the same set of instructions.

Using the conventional comparison operators such as == or != do not necessarily compare the contents of arrays. Rather, the said operators check if the entities on both sides refer to the same object or not. To put it in simpler terms, they check reference, not contents. To compare the contents of 2 Arrays, use sameElements.

This variable identifier is a reserved keyword.

Calling methods such as mkString directly over scala.io.Source methods such as fromFile leaks the underneath file handle. To mitigate this, one way is to manually call the close method to free/close these resources yourself. However, the ideal and right approach is to use Scala's automatic resource management. scala.util.Using helps automatically manage either a single resource or multiple resources, thus preventing any underneath file handles from leaking.

Languages like Java and Scala allow you to annotate a method as deprecated to signify that the method is no longer supported and will be dropped in the near future and that the users must switch to a suitable alternative. However, marking a Scala method with Java's annotation, i.e. @Deprecated is not ideal. Rather, it is suggested that you use the Scala's annotation, i.e. @deprecated as the former may or may not trigger the deprecated message.