Naming conventions in Kotlin

Kotlin is a very fast-growing programming language in the Software Development Industries. It is gaining attention among developers because of its simplicity, safety, and interoperability with Java. So if you are working with Kotlin then you have to follow some Naming conventions which make your code more readable and understandable

What is Naming Conventions

Naming conventions in Kotlin contain a set of rules that talk about how to name different elements in the code, like variables, name functions name, classes name, packages name, and constants.

Below are some naming conventions which make the code more readable, understandable, and consistent and help developers avoid naming conflicts and errors. So If you working with Kotlin to develop software one of the important rule is of writing clean and maintainable code which is following Kotlin naming conventions.

Kotlin naming conventions

1:-Kotlin variable naming conventions

Variable name must be written in lowerCamelCase.

BAD:-
XMLHTTPRequest URL: String?=null

GOOD:-
XmlHttpRequestUrl: String ?=null

2:-Kotlin function naming conventions

Kotlin function name must be written in lowerCamelCase.

BAD:- 
private fun setvalue()

GOOD:-
Private fun setValue()

3:-Kotlin class naming conventions

Kotlin class name must be written in UpperCamelCase.

BAD:- 
class MYCLASS()
class my class{}
class myClass{}
class Myclass{}

GOOD:-
Class MyClass{}

4:-Data Type Objects

Prefer data classes for simple data-holding objects.

BAD:
class Person(val name: String) {
     override fun toString() : String { 
      return “Person(name=$name)” 
      } 
        }

GOOD:
data class Person(val name: String)

5:-Kotlin package naming conventions

Package names must be in all lower-case without hyphens or underscores:

BAD :
com.Test.funky_widget

GOOD :
com.test.funkywidget

6:-Kotlin field conventions

Generally, written in lowerCamelCase. As of now, Hungarian notation is erroneously thought to be recommended by Google. So we should not be named with Hungarian notation,

class DemoClass { 
var myAge: Int = 0 
val person = Person() 
private var yourAge: Int? 
}

7:-Kotlin constant naming conventions

Constant values  should be written in uppercase in the companion object with an underscore separating words:

companion object { const val FINAL_RESULT = 50 }

8:-Kotlin enum naming conventions

While working with Enum classes then you should be very careful because due to a large memory overhead. You must be avoided where possible, Static constants are preferred. See http://developer.android.com/training/articles/memory.html#Overhead for further details.

Enum classes without any methods may be formatted without line breaks, as follows:

private enum CompassData { EAST, NORTH, WEST, SOUTH }

9:-Indentation

Indentation is using spaces – never tabs.

10:-Blocks

 Blocks use 2 spaces (not the default 4) in Indentation :

BAD:
for (i in 0…9) { Log.i(TAG, “index=” + i); }

GOOD:
for (i in 0…9) { Log.i(TAG, “index=” + i) }

11:-Line Length

Lines length should not be longer than 100 characters long.

12:-Vertical Spacing

There must be one blank line between methods to show clarity in code and make it readable for other developers, but if you are having too many sections in a method that means you should break this method into several methods.

13:-Brace Style

Only trailing closing braces are awarded their own line. All others appear at the same line as the preceding code:

class MyClass { 
fun doSomething() 
{ 
if (someTest) 
{ 
// … 
} 
else 
{
 // … 
} 
} 
}

GOOD:
class MyClass { 
fun doSomething() {
 if (someTest) { 
// … 
} 
else {
 // … 
}
 }
 }

14:-Conditional statements

While working with conditional statements they should be enclosed with braces,

BAD:
if (someTest) 
doSomething() 
if (someTest) 
doSomethingElse()

GOOD:
if (someTest) { 
doSomething() 
} 
if (someTest) {
 doSomethingElse() 
}

15:-When Statements

Unlike switch statements in Java, when statements do not fall through. Separate cases using commas if they come into the same case. Always include the else case.

BAD:
when (anInput) {
 1 → doSomethingForCaseOne() 
2 → doSomethingForCaseOneOrTwo() 
3 → doSomethingForCaseThree() 
}
GOOD:
when (anInput) { 
1, 2 → doSomethingForCaseOneOrTwo() 
3 → doSomethingForCaseThree() 
else → println(“No case satisfied”) 
}

17:-Type Inference

Type inference should be preferred where possible to explicitly declared types.

BAD:
val something: MyType = MyType() 
val meaningOfLife: Int = 42

GOOD:
val something = MyType()
val meaningOfLife = 42