en un clic
en un clic
Useful Gradle commands for linting, testing, and deployment.
Verification steps to ensure code changes are correct and maintainable.
General code conventions for the project.
Architectural patterns and coding standards followed in the project.
General code conventions for the project.
TOML coding conventions for the project.
| name | code_conventions_kotlin |
| description | Kotlin coding conventions for the project. |
finance_manager vs financemanager.
Refer Dictionary for more details.Always use curly braces {} for blocks, even for single-line statements.
Context: This improves readability and maintains consistency.
e.g.
Use
if (condition) {
doSomething()
}
instead of
if (condition) doSomething()
Use K&R style (opening brace on the same line).
When statements: Each statement in a when should be within a block using curly braces. Context: This improves readability and maintains consistency. e.g. Use
when (value) {
1 -> {
doSomething()
}
else -> {
doSomethingElse()
}
}
instead of
when (value) {
1 -> doSomething()
else -> doSomethingElse()
}
Mandatory Block Bodies: Always use block bodies with curly braces
{} for function declarations. Expression body syntax (using
=) is prohibited, even for simple one-line returns.
Context: To ensure code consistency and simplify future logic extensions.
e.g.
Use
fun doSomething() {
// implementation
}
instead of
fun doSomething() = /* implementation */
**Lambda Assignments **: This rule does not apply to properties assigned to a lambda expression. Since lambdas require curly braces by definition, they should remain as-is. e.g.
val doSomething = {
/* implementation */
}
Brackets: Always put a new line after the opening brace { and before the closing brace }.
Context: This improves readability and makes it easier to visually parse code blocks.
e.g.
Use
if (condition) {
doSomething()
}
instead of
if (condition) { doSomething() }
Named parameter: Place each named parameter on a separate line for every Kotlin method call. **Context: ** This enhances readability, especially when dealing with functions that have multiple parameters. e.g. Use
someFunction(
param1 = value1,
param2 = value2
)
instead of
someFunction(param1 = value1, param2 = value2)
Lambda expressions: Always use new lines for lambda expressions. **Context: ** This improves readability and makes it easier to understand the structure of the lambda. e.g. Use
list.filter {
it.isValid()
}
instead of
list.filter { it.isValid() }
**Chained method calls **: Always put chained method calls on separate lines when there are at least 2 method calls chained. Context: This improves readability, especially when dealing with long chains of method calls. e.g. Use
someObject
.methodOne()
.methodTwo()
.methodThree()
instead of
someObject.methodOne().methodTwo().methodThree()
Function parameters:
Use trailing commas wherever applicable. **Context: ** Trailing commas can make version control diffs cleaner and reduce the need for additional changes when adding new items to lists or function calls. e.g. Use
val list = listOf(
item1,
item2,
item3,
)
instead of
val list = listOf(
item1,
item2,
item3
)
Classes and Objects:
MainActivity, UserRepository).Functions and Variables:
getUserData(), userName).Constants:
MAX_RETRY_COUNT, DEFAULT_TIMEOUT).Package Names:
com.makeappssimple.abhimanyu.app).File Names:
MainActivity.kt).private as the default visibility modifier.internal for module-level visibility when needed.public only when the API is intentionally exposed.@VisibleForTesting annotation for internal functions that need to be tested.Named Parameters:
Trailing Lambda: Avoid using trailing lambdas. Prefer using named parameters instead.
End of files: All files should always end with exactly a single empty line.
Type?) when the function can return null.Exception. Always document exceptions that can be thrown by any function.?.) and Elvis (
?:) operators appropriately. Never use !!. Always use safe type casting (
as?). Never use forced casting (as).@param,
@return, and @throws tags where appropriate.Test. Name functions as
functionUnderTest_condition_expectedResult or use backticks for descriptive names.test/ directory, mirroring the source structure. Place instrumented tests in androidTest/.@Before and
@After for setup/teardown.@Test for test methods. Use
@VisibleForTesting where needed. Prefer internal or private for test classes and helpers.provides as the prefix (not provide).