Home/

...

/

Naming Conventions

Naming Conventions

In this lesson we will look at the naming conventions used in Scala.

General Guidelines

Generally speaking, Scala uses “camel case” naming. That is, each word is capitalized, except possibly the first word.

Press + to interact
UpperCamelCase
lowerCamelCase

Acronyms should be treated as normal words.

Press + to interact
// WRONG!
XHTML
maxID
Press + to interact
// RIGHT!
Xhtml
maxId

Underscores in names (_) are not actually forbidden by the compiler, but are strongly discouraged as they have special meaning within the Scala syntax. However, there are some exceptions which we will see later in this lesson.

Constants, Values, Variables and Methods

Constant names should be in upper camel case. If the member is final, immutable and it belongs to a package object or an object, it may be considered a constant:

Press + to interact
object Container {
  val MyConstant = ...
}

The value: Pi in scala.math package is another example of such a constant.

Method, Value and variable names should be in lower camel case:

Press + to interact
val myValue = ...
def myMethod = ...
var myVariable

Classes/Traits

Classes should be named in upper camel case:

Press + to interact
class MyFairLady

Sometimes traits and classes, as well as their members, are used to describe formats, documentation or protocols and generate/derive them. In these cases it is desirable to be close to a 1:1 relation to the output format and the naming conventions don’t apply. In this case, they should only be used for that specific purpose and not throughout the rest of the code.

Objects

Object names are like class names (upper camel case).

An exception is when mimicking a package or function; this isn’t common. Let’s look at an example below.

Press + to interact
object ast {
  sealed trait Expr
  case class Plus(e1: Expr, e2: Expr) extends Expr
  ...
}
object inc {
  def apply(x: Int): Int = x + 1
}

Packages

Scala packages should follow the Java package naming conventions.

Press + to interact
// WRONG!
package coolness
Press + to interact
// RIGHT! Puts only coolness._ in scope
package com.novell.coolness
// RIGHT! Puts both novell._ and coolness._ in scope
package com.novell
package coolness
// RIGHT! For package object com.novell.coolness
package com.novell
/**
 * Provides classes related to coolness
 */
package object coolness {
}

root

It is occasionally necessary to fully-qualify imports using _root_. For example, if another net is in scope, then to access net.liftweb we must write e.g.:

Press + to interact
import _root_.net.liftweb._

Do not overuse _root_. In general, nested package resolves are a good thing and very helpful in reducing import clutter. Using _root_ not only negates their benefit but also introduces extra clutter in and of itself.

Type Parameters (generics)

For simple type parameters, a single upper-case letter (from the English alphabet) should be used, starting with A.

Press + to interact
class List[A] {
  def map[B](f: A => B): List[B] = ...
}

If the type parameter has a more specific meaning, a descriptive name should be used, following the class naming conventions (as opposed to an all-uppercase style):

Press + to interact
// Right
class Map[Key, Value] {
  def get(key: Key): Value
  def put(key: Key, value: Value): Unit
}
// Wrong; don't use all-caps
class Map[KEY, VALUE] {
  def get(key: KEY): VALUE
  def put(key: KEY, value: VALUE): Unit
}

If the scope of the type parameter is small enough, a mnemonic can be used in place of a longer, descriptive name.

Press + to interact
class Map[K, V] {
  def get(key: K): V
  def put(key: K, value: V): Unit
}

Annotations

Annotations, such as @volatile should be in lower camel case:

Press + to interact
class cloneable extends StaticAnnotation