This document serves as the complete definition of Google’s Android coding standards for source code in the Kotlin Programming Language.

1. Code Style Guidelines
By Sanjay Hans

2. Nomenclature
Declarations
Spacing
Semicolons
Brace Style
When Statements
Annotations
Types
Xml Guidance
Language
Credit
TOC

3. Nomenclature
Packages
Package names are similar to Java: all lower-case, multiple words concatenated
together, without hyphens or underscores:
org.example.kotlin
Classes & Interfaces
Names of classes and objects start with an upper case letter and use the
camel case:
class DeclarationProcessor
Function names
Names of functions, properties and local variables start with a lower case letter and use the
camel case and no underscores:
fun processDeclaration(){/*…*/}
var declarionCount = 1

4. Property names
Constant values in the companion object should be written in uppercase, with an
underscore separating words:
class const val MAX_COUNT = 8
val USER_NAME_FIELD = "UserName"
Variables & Parameters
Written in lowerCamelCase.
Single character values must be avoided, except for temporary looping variables.

5. Declarations
Visibility Modifiers
Only include visibility modifiers if you need something other than the default of public.
Fields & Variables
Prefer single declaration per line.
username: String
twitterHandle: String
Classes
Exactly one class per source file, although inner classes are encouraged where
scoping appropriate.

6. Data Type Objects
Prefer data classes for simple data holding objects.
Enum Classes
Enum classes without methods may be formatted without line-breaks, as follows:
private enum CompassDirection { EAST, NORTH, WEST, SOUTH }

7. Spacing
Indentation
Indentation is using spaces - never tabs.
Blocks
Indentation for blocks uses 2 spaces (not the default 4):
Line Wraps
Indentation for line wraps should use 4 spaces (not the default 8):

8. Line Length
Lines should be no longer than 100 characters long.
Vertical Spacing
There should be exactly one blank line between methods to aid in visual clarity and organization.
Whitespace within methods should separate functionality, but having too many sections in a method often means
you should refactor into several methods.
Semicolons:
Semicolons are dead to us should be avoided wherever possible in Kotlin.

9. Brace Style
Unlike Java, direct access to fields in Kotlin is preferred.

10. When Statements
Unlike switch statements in Java, when statements do not fall through.
Separate cases using commas if they should be handled the same way.
Always include the else case.

11. Annotations
Standard annotations should be used - in particular override.
This should appear on the same line as the function declaration.

12. Types
Always use Kotlin's native types when available.
Type Inference
Type inference should be preferred where possible to explicitly declared types.
val something = MyType()
val meaningOfLife = 42
Constants vs. Variables
Constants are defined using the val keyword,
and variables with the var keyword.
Always use val instead of var if the value of the variable will not change.

13. XML Guidance
Since Android uses XML extensively in addition to Java, we have some rules specific to XML.
XML File Names
View-based XML files should be prefixed with the type of view that they represent.
• activity_login.xml
• fragment_main_screen.xml
• button_rounded_edges.xml
Use Context-Specific XML Files
•Strings => res/values/strings.xml
•Styles => res/values/styles.xml
•Colors => res/color/colors.xml
•Animations => res/anim/
•Drawable => res/drawable
Language
Use US English spelling.
String color = "red";

14. Useful
resources
 https://kotlinlang.org/docs/reference/coding-
conventions.html
 https://developer.android.com/kotlin/style-guide
 https://source.android.com/setup/contribute/code-style
 https://github.com/raywenderlich/kotlin-style-guide
 https://jakewharton.com/just-say-no-to-hungarian-notation/

15. Q&A