Kotlin

Unreachable code should be removed, as it serves no purpose. Such code is typically a result of incorrect or unintended control flow in code. It is thus important to correctly structure your code and ensure that all code-paths are reachable and can be executed.

Unreachable catch blocks should be removed, because they serve no useful purpose and can lead to confusing and potentially incorrect behavior in exception handling.

Avoid using is to check the type of exceptions, or as to cast exception types within catch blocks.

Avoid throwing NotImplementedError and using TODO(...) in code.

Functions which only contain a return statement can be collapsed to an expression body. This shortens the code and makes it more readable.

Collapsing nested if statements into one improves code readability by making it more concise and easier to understand. It simplifies the logic, reduces cyclomatic complexity, and can lead to better performance. Debugging becomes easier, and code maintainability is enhanced. It is important to strike a balance between readability and line length while

In Kotlin, the abstract keyword is redundant when declaring interfaces and their members. Interfaces are implicitly abstract in Kotlin, so there is no need to use the abstract keyword, and the same is true for any members of an interface. Omitting the abstract keyword does not affect the behavior or functionality of an interface, and allows for more concise code.

When a class implements Serializable, it is recommended to also declare a serialVersionUID field within that class. The serialVersionUID serves as a version identifier for the serialized class. It helps to ensure compatibility between the serialized objects and their corresponding class definitions, particularly when performing deserialization.

In Kotlin, it is generally preferred to use a constant variable instead of a function returning a single constant for improved code clarity, performance, and maintainability. Constant variables are more readable, avoid unnecessary runtime overhead, and enable centralized value management. Additionally, they allow potential compiler optimizations

In Kotlin, ?. is called the "safe call operator" or "null-safe call operator". It is used to perform a safe access or safe method call on a nullable object. It allows you to execute a method or access a property on an object only if the receiver is not null. If the object is null, the expression will evaluate to null without throwing a NullPointerException.

Duplicate conditions in binary expressions are problematic because they introduce redundancy, make code harder to maintain, and can negatively impact performance.

Using equals to compare an object with null is bad practice. If an object has to be checked for null, consider using the == operator directly. This makes the code more concise. Furthermore, comparison using == also prevents mistakes caused by forgetting to handle null in the equals() implementation, or if the object you are calling equals() on is itself null.

Kotlin classes are final by default. Thus, classes which are not marked as open should not contain protected members. If stricter visibility is desired, one should consider making the members private. On the other hand, if the member is a const property and visibility outside the class is not an issue, consider making it public.

Exceptions should not be wrapped inside the same exception type and then rethrown.

Instead, wrap the exception in a more meaningful exception type.

The code explicitly triggers the garbage collector by calling System.gc() or similar methods. In Kotlin, you don't need to explicitly trigger the garbage collector.

Avoid using printStackTrace to log exceptions.

Avoid throwing a caught exception without modifying it.

Avoid returning from within a finally block, as this can prevent normal exception handling control flow from executing.

Avoid "swallowing" exceptions by catching them and leaving the exception variable unused.

Avoid throwing exceptions within the main method.