This message was deleted.

If you don't care about

i

itself just do

repeat(max) { ... }

Thoughts on using emojis for functions you want to discourage developers from using but still having them there just in case? Running into a brick wall with some #mockk related things where we can’t properly mock some fields for a class we don’t control, so falling back to reflection which does work. Was thinking something like this:

private inline fun <reified T : Any> T.`💩`(fieldName: String, fieldValue: Any) {
        val attribute = this::class.java.getDeclaredField(fieldName)
        attribute.isAccessible = true
        attribute.set(this, fieldValue)
    }

// call site
agent.`💩`("id", agentId)

Coding conventions says

Prefer using the expression form of try, if and when.

Should I apply this with no exceptions? e.g.

fun doSomething(x: Int): Int {
    if (x > 10) {
        <http://log.info|log.info>("an info")
        someAction()
        return 5
    } else {
        log.error("an error")
        return 10
    }
}

Should this be converted to return the

if

expression?

Basically, the coding style to use uppercase for constants were copied from C. It made sense for C when constants were macros but it is not the case in other languages. In human languages uppercase is FOR SHOUTING, so why would use this for things that never change? If anything, it should be used for mutable variables.

// utils/Const.kt

const val DEFAULT_TIME_MILLIS = 3000L // for default timer in ms

const val DEFAULT_PAGER_SIZE = 3 // for viewpager ui const

Need an advice Does we should avoid building a single god class constant like this? Or what approach highly recommended to create a constant class?

Follow-up question to the previous one. I'm starting with Kotlin migrating some classes. In Java, I try to define as

private static final

attributes to avoid memory footprint and object creation. In Kotlin, I created a companion object with a

private const val

but when decompiled code shows a new inner static class is created, does this create more memory footprint than the Java counterpart? Is there a better way to define constant which should be used only in one class?

Is this underscore naming convention common in Kotlin?

I wonder if there is any recommendation to use

==

vs

?:

in order to operate with

Boolean?

. I generally try to avoid

@Nullable

types, but sometimes they are inevitable. I find more ‘natural’

value == false

Over

value ?: false

It seems more explicit and also easier to understand by developers new to Kotlin. Do you have any recommendations?

I'm having a particularly hard time convincing our lead architect to let us adopt idiomatic Kotlin usage so I thought I would post here to see if anyone has any recommendations regarding some specific points. So in general it appears he's fine with Kotlin as long as we follow the same style guide as his C# team does. His justifications really lean into the philosophy of eliminating all subjectivity regarding what the code looks like and he wants consistency throughout the disparate codebases rather than consistency with the specific ecosystems. Here are the two of the biggest points he's made: 1. One class per file. His justification here appears to be that if we allow multiple classes per file then how do we decide what can go together and what can't. The official style guide's position of "closely related to each other semantically and the file size remains reasonable" is too subjective for him. If we follow this reasoning of "objectivity" then I find it hard to come up with an argument in support of multiple classes per file but this just feels wrong. For one, I now have dozens of basically 1-line data class files. More importantly, if we can't have multiple classes per file we can't use the sealed class language feature. 2. No inner or nested classes. It seems he wants all classes to be top-level with explicit names. This once again leads to more files but also longer file names. It also goes against precedence set by platform classes like Map.Entry and in my opinion just pollutes the name space. We also can't use private, implementation-detail classes. Any suggestions regarding how to justify these points "objectively" are appreciated. Note that "this is a best-practice" and "this is idiomatic" do not appear to be sufficient.

Foo(bar.prop.op1 {...}.op2 {...}.op3(...))

or

bar.prop.op1 {...}.op2 {...}.op3(...).let(::Foo)

?

fun Vector.times(other: Vector) = zip(other, Double::times).toVector()

or

fun Vector.times(other: Vector) = zip(other) { a, b -> a * b }.toVector()

?

if (cond) foo(a) else foo(b)

or

foo(if (cond) a else b)

Is there any other way of achieving similar results to that?

inline fun <reified T : Any> withType(
        t: KClass<T> = T::class
) = ...

inline fun <reified T1 : Any, reified T2 : Any> withType(
        t1: KClass<T1> = T1::class,
        t2: KClass<T2> = T2::class
) = ...

inline fun <reified T1 : Any, reified T2 : Any, reified T3 : Any> withType(
        t1: KClass<T1> = T1::class,
        t2: KClass<T2> = T2::class,
        t3: KClass<T3> = T3::class
) = ...

inline fun <reified T1 : Any, reified T2 : Any, reified T3 : Any, reified T4 : Any> withType(
        t1: KClass<T1> = T1::class,
        t2: KClass<T2> = T2::class,
        t3: KClass<T3> = T3::class,
        t4: KClass<T4> = T4::class
) = ...

When do I put property initialization logic into an init block vs into a function? I suppose it depends on if I need the same logic again after initialization

Do you sometimes use the non-expression version of if/else for readability, even if it could be written as an expression?

Is it better to write this initialization logic into an

init

block or directly on the property?

val name: String = if (name.isBlank()) "No Name" else name.trim()

vs

init {
    if (name.isBlank()) {
        this.name = "No Name"
    } else {
        this.name = name.trim()
    }
}

Is it ever good practice in Kotlin to use an

open

class as opposed to

abstract class

,

sealed class

, or

interface

?

Which one do you like more? 2 is more concise but I don't really like the unnecessary else

For

typealias

naming - which style do you prefer (verb vs noun vs mixed)?

() -> User

// 1 - verb
typealias GetUser = () -> User

Usage then becomes

getUser()

// 2 - noun
typealias UserGetter = () -> Int

Usage then becomes `userGetter()`/`userGetter.invoke()`

// 3 - mixed
typealias UserGetter = () -> User

val userGetter: UserGetter = ..
val viewModel = ViewModel(
  getUser = userGetter
)

Usage is still

getUser()

What do you guys think about long functions with expression bodies? Like this:

fun createList(source: Source) = mutableListOf<Item>().also {
   // Code that accesses source, adds item to list, etc
   // On the long-ish side
}

For production code, in your data models, do you specifiy

@SerialName

for all fields or just the required ones? 1.

data class Foo(@SerialName("_id") val id: Int, @SerialName("name") val name: String)

2.

data class Foo(@SerialName("_id") val id: Int, val name: String)

// 1
something?.let { return it }

Or

// 2
if(something != null) { return something }

Given you have an API for an specific situation that is supposed to be used somewhat like that:

interface StateMachine<S> {
    fun updateState(state: S)
}

Where

S

needs to be a class that is able to represent the state of an UI element. What would you set as the upper-bound of

S

?

// 1
interface StateMachine<S : Any>

or

// 2
interface StateMachine<S : State>

// where
interface State  // There is no specific contract expected

Should I keep these statements separate and leave in the type declaration for readability or smush them together? My goal is to write code that is both idiomatic and maintainable.

private fun chooseBestMatch(results: List<String>) {
        val lowers = results.map { it.toLowerCase() }
        val matches: List<IntentMatcherResult> = lowers.map { result -> matchers.map { it.matchTranscript(result) } }.flatten().flatten()
        val best = matches.maxBy { it.score }
    }

Which is better?

// 1
val h = hour.toInt() + if (meridian.isNotEmpty() && meridian[0] == 'p') 12 else 0

or

//2
var h = hour.toInt()
if (meridian.isNotEmpty() && meridian[0] == 'p') h += 12

// 1
parameterRegex.matchEntire(toParse)?.run {
    require(groupValues.size == 3)
    val (parameter, value, rest) = destructured
    parameters[parameter] = value
    return parse(rest)
}

or

// 2
parameterRegex.matchEntire(toParse)?.let {
    require(it.groupValues.size == 3)
    val (parameter, value, rest) = it.destructured
    parameters[parameter] = value
    return parse(rest)
}

// 1
regexBuilder.append(
    alts.split("|")
        .map { it.trim() }
        .map { if (it.isEmpty()) "" else " $it"}
        .joinToString(prefix = "(?:", separator = "|", postfix = ")"))

or

// 2
regexBuilder.append(
    alts.split("|")
        .map { it.trim() }.joinToString(
             prefix = "(?:",
             separator = "|",
             postfix = ")"
        ) { if (it.isEmpty()) "" else " $it" })