Which is preferred?

# announcements

[Saiedmomen]

Which is preferred?

How_to_declare_constants.kt

[Ruckus]

Depends on the use case but without further context I'd either do 2 or

class ClassName {
    companion object {
        private const val CONST_VALUE = "value"
    }
}

[joelpedraza]

Short answer: 2 (or in a ClassName companion object, but I prefer top level)

[Ruckus]

@joelpedraza Great minds and all that 🙂

[hudsonb]

I put them at the top level as well

[Saiedmomen]

why companion?
I prefer to not use companion If at all possible.

[joelpedraza]

As a rule I go with top level for private const, companion for public (to avoid polluting the global namespace)

[Ruckus]

If the value is only used with the class, it makes the intent more clear.

[Saiedmomen]

The drawback of top level is that your Kotlin class file becomes Kotlin file. You loose the association between file and class in the IDE

[Saiedmomen]

I think creating companion for storing constants is overkill

[joelpedraza]

Tangential to the rest of the conversation: Either way a new class is created

[Saiedmomen]

not with option 1 if I'm not wrong

[Ruckus]

No, not for option 1, but that won't actually be a compile time constant.

[joelpedraza]

True but then every instance of your class has a field to hold what should be a shared static or const

[joelpedraza]

If it’s a concern for you any tree shaking optimization will remove it. IIRC consts are inlined for kotlin usages, but java usages access the field

[Saiedmomen]

@joelpedraza You mean the field in option 1?

[joelpedraza]

No, top level or companion