Scala

Scala

Made by DeepSource
Consider specifying type in catch clause SC-W1089
Bug risk
Critical

Cases within the catch clause potentially allow you to recover from an error within your application. Because you have Error-s apart from Exception-s under Throwable-s, you may end up trying to recover from a point of no return such as running under extremely low memory limits. Therefore, it is always a good practice to specify types.

length-like property is compared against values which always evaluate to the same result SC-W1091
Bug risk
Critical

length-like properties are usually used to "count" the number of elements. For example, in the context of an array, length tells us the number of elements in the array. Comparing this property against 0 using the < or >= operators is meaningless and will always evaluate to false and true respectively. This comparison is likely a mistake and should be rewritten meaningfully.

Enum value has a member that maps to an already mapped value SC-W1087
Bug risk
Critical

An enum holds different members that map to different values. In most languages, it is usually expected that these members map to unique values. However, in this case, one or more members map to a value that was already associated with a different member. This could likely be a mistake and greatly affect your program's logic and behaviour. It is recommended that you review all the values associated with this enum's members.

Annotating a method with both inline and tailrec annotations results in a compile-time error in future Scala versions SC-W1088
Bug risk
Critical

Any method that is annotated with both inline and tailrec annotations throw a compile time error in Scala 3 despite compiling and running fine in Scala 2. In case you wish to upgrade to Scala 3 in near future, it is recommended that you take another look at this method and either rewrite it appropriately or drop one of the two said annotations.

Lambda parameter is unused SC-W1083
Bug risk
Major

Lambda expressions are anonymous functions that are not bound to any particular identifier and are extensively used in the standard and 3rd party libraries for operations such as filter, map, count, etc. These expressions may take in one or more parameters just like normal methods. However, in this case, one of the parameters that the lambda depends on is unused. Either you meant to consume the said parameter or that the parameter is simply not required by design and can be omitted.

Duplicate case in pattern-matching SC-W1007
Bug risk
Major

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.

Using .deep to compare Arrays is deprecated SC-W1051
Bug risk
Critical

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.

Redundant val keyword for case class' constructor parameter SC-R1038
Bug risk
Minor

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.

finalizers should not be defined explicitly SC-R1046
Bug risk
Major

finalizers may contain the required logic necessary for performing clean-up actions such as freeing up of resources. However, they're triggered by the JVM when and as deemed necessary. This means that your logic may be executed at a time when the resources that are to be freed are no longer available. Additionally, once invoked, finalizations cannot be interrupted and do not guarantee any specific ordering. It is therefore recommended that you use interfaces such as AutoCloseable to perform the required clean-up actions.

Explicitly defined finalizers should not be public SC-R1047
Bug risk
Major

It is generally recommended that you use interfaces such as AutoCloseable to perform clean-up related tasks. However, if you choose to explicitly define a finalizer, it is suggested that it have an access specifier that is more restrictive than public such as protected or private. This signifies that it may not be programmatically be invoked.

finalizers should call super.finalize for super classes to run their own finalization logic SC-R1048
Bug risk
Major

It is generally recommended that you use interfaces such as AutoCloseable to perform clean-up related tasks. However, if you choose to explicitly define a finalizer, it should call super.finalize to let its super class run its own finalization logic when appropriate, i.e., when inheritance is involved.

Overridden methods cannot simply call super SC-R1049
Bug risk
Major

Methods are overridden in situations where the implementation/logic requires certain modifications. Overriding a method and simply calling super, i.e. the super class' implementation is redundant. It is therefore recommended that you either not override the method or modify your overriding logic.

Oddness check i % 2 == 0 fails for -ve numbers SC-W1000
Bug risk
Major

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.

Incorrect number of args to String.format SC-W1008
Bug risk
Critical

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.

Missing method return type SC-W1009
Bug risk
Major

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.

Empty interpolated string SC-W1011
Bug risk
Critical

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 key in HashMap SC-W1019
Bug risk
Major

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.

Duplicate element in HashSet SC-W1020
Bug risk
Minor

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 trap of NullPointerException SC-W1021
Bug risk
Major

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.

If condition depends on boolean value that is a compile time constant SC-W1022
Bug risk
Major

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.