Canonical reference for Kotlin idioms, naming conventions, and code quality standards used across this project.
S3Mock uses Kotlin 2.3+ with language and API compatibility set to 2.2, following Spring Boot 4.x guidance:
- Kotlin compiler: 2.3+
- Language/API version: 2.2 (
-language-version 2.2,-api-version 2.2) - JVM target: 17 (build requires JDK 25; bytecode/JVM target 17)
This means you can use any syntax and standard library APIs available in Kotlin 2.2. Kotlin 2.3+ compiler improvements (performance, diagnostics) apply automatically.
- Use
?.,?:, and nullable types instead of explicit null checks x?.foo()overif (x != null) { x.foo() }x ?: throw ...orrequireNotNull(x)overif (x == null) throw ...
- Prefer
valovervar, especially for public API properties
- Use for single-expression functions:
fun foo() = bar()
- Always name
itin nested or non-trivial lambdas to avoid shadowing .map { part -> ... }instead of.map { it.name }
- Prefer
whenoverif-elsechains with 3+ branches
- Use
.let/.alsowhen they improve readability, not gratuitously - Use early returns to flatten deeply nested code
- Extract functions: break up methods longer than ~30 lines
list.isEmpty()/list.isNotEmpty()overlist.size == 0/list.size > 0
- Use
"$value"over"" + valueconcatenation
- Prefer Kotlin stdlib / JDK APIs over adding new third-party libraries (no Apache Commons)
| Anti-Pattern | Refactor To |
|---|---|
if (x != null) { x.foo() } |
x?.foo() |
if (x == null) throw ... |
x ?: throw ... or requireNotNull(x) |
list.size == 0 / list.size > 0 |
list.isEmpty() / list.isNotEmpty() |
"" + value |
"$value" |
Collections.emptyList() |
emptyList() |
object.equals(other) |
object == other |
!(x is Foo) / !(list.contains(x)) |
x !is Foo / x !in list |
for + add loops |
.map { ... } |
| Empty catch blocks | At minimum, log the exception |
| Magic numbers/strings | Named constants |
- Booleans:
is-/has-/should-/can-prefixes - Collections: plural nouns
- Functions: verb phrases (
verifyBucketExists,resolveVersionId) - Avoid abbreviations:
bucketMetadatanotbktMd
- Backtick names: Use descriptive sentences —
fun `should create bucket successfully`() - Legacy names: Refactor
testSomethingcamelCase names to backtick style when touching existing tests - Visibility: Mark test classes as
internal
- Use
/** */for public APIs;//inline comments for rationale - Comments explain why, never what — remove comments that restate the code
- Add comments for edge cases, non-obvious S3 semantics, or workarounds
- Link to AWS API docs or GitHub issues where relevant