Inappropriate coding practices - Wildcard export - Scala

Inappropriate coding practices - Wildcard export - Scala

Need

Enforce explicit exports in code modules to avoid the use of wildcard exports

Context

  • Usage of Scala for building scalable and high-performance applications
  • Usage of MyLibrary for custom functionality or feature implementation

Description

Non compliant code

        package com.example

object MyLibrary {
  def function1() = {
    // some code
  }

  def function2() = {
    // some code
  }

  def function3() = {
    // some code
  }

  // More functions...
}

// In another file
package com.example

import MyLibrary._
        
        

In the above Scala code, we have a library MyLibrary with several functions. When we want to use these functions in another file or module, we use the statement import MyLibrary._.

The ._ is a wildcard operator that imports all the functions and variables from the MyLibrary object. This is an inappropriate coding practice known as a wildcard export. It exports all the functions of that library, regardless of whether they are needed or not.

This can lead to several issues:
- It makes the code harder to understand and maintain. When you see a function being used, you don't know where it's coming from without looking at the import statements.
- It can lead to naming conflicts. If two libraries have a function with the same name, and you import both with the wildcard operator, it's not clear which one you're using.
- It can lead to unused imports, which is a waste of resources and can slow down the execution of the program.

In general, it's better to explicitly import only the functions you need. This makes the code cleaner, easier to understand, and less prone to errors and conflicts.

Steps

  • Avoid using wildcard imports
  • Explicitly import only the required functions from the library
  • Remove the wildcard import statement

Compliant code

        package com.example

object MyLibrary {
  def function1() = {
    // some code
  }

  def function2() = {
    // some code
  }

  def function3() = {
    // some code
  }

  // More functions...
}

// In another file
package com.example

import MyLibrary.function1
import MyLibrary.function2
import MyLibrary.function3
        
        

The original code was using a wildcard import ( import MyLibrary._), which imports all functions from MyLibrary. This is a bad practice because it can lead to naming conflicts and it's harder to track which functions are being used from the library.

The fixed code explicitly imports only the required functions ( function1, function2, function3) from MyLibrary. This makes it clear which functions are being used, and avoids potential naming conflicts. It also makes the code easier to maintain, because you can see at a glance which functions are being used from the library.

Remember, it's always better to be explicit about what you're importing. It makes your code easier to read and maintain, and can help prevent bugs and issues.

References