Is there any particular reason why companion object should be at the bottom? Or it’s just a conventi...

# getting-started

[theapache64]

Is there any particular reason why companion object should be at the bottom? Or it’s just a convention ?

[theapache64]

Source : https://kotlinlang.org/docs/coding-conventions.html#factory-functions

[Joffrey]

I guess the important part is consistency, to improve the readability of the code by meeting the expectations of the reader. So there needs to be some convention, and they picked this. Not sure if there is much more to it, though.

[louiscad]

I personally prefer them at the top 🤷🏼

[louiscad]

Reason being that they compete with constructors for my most common usages.

[Joffrey]

I've seen them used at the top a lot too, to be frank. I guess it depends on what's in it

[louiscad]

I think this part of the doc should be ditched (+publication/article about why to spread awareness)

[Joffrey]

For instance, we have a bunch of companions in our project that don't even have a body, and just bring logging facilities to the class:

companion object : KLogging()

And then we can use logger in the class.

[louiscad]

Would be best when the language parser stops treating suspend on a next line as a companion object name when it has no body nor any subclass though.

class A {
    companion object
    suspend fun thisDoesntSuspend()
}

[Joffrey]

Could be a good reason to keep that at the bottom. Especially if your empty companion has no code at all, and is really just here to be present for possible extensions. It's not very important information that needs to be the first thing you read in the class

[louiscad]

I personally add a semicolon

[louiscad]

I like to show upfront it's designed to allow extensions. It shows: "there's more outside this file"

[Joffrey]

Reason being that they compete with constructors for my most common usages

While I understand the rationale, I would find it weird to have it above non-constructor properties. Usually I want my properties just below the main constructor properties.

[Joffrey]

It shows: "there's more outside this file"

Well you can't really show that for the class itself, so I'm not sure it's worth considering this advantage for the companion

[louiscad]

For the class, the possibility is always there

[louiscad]

If the properties are private or internal, I want them after.
Reason being I want to show the public API first, and the companion object can be part of it.

[Joffrey]

I see the point, but I don't value this enough to mess with other things I value more. For instance, when reading the class, I don't mind much mixing public/private APIs, because if I'm here I'm likely interested in private stuff anyway (looking at the implementation of methods is already a private thing). So I don't see much value in ordering public-first anymore (I used to). However, I do see value in putting all the state in one place (private or public), to get a grasp of what's going on in this class, and interspersing a companion there would just make me lose this.

IMO companion stuff is different in the sense that it's not instance-specific, so I want it either before or after everything that is instance-related. I can't have it before, because there is the primary constructor and properties, so it has to be at the end for me

[louiscad]

I personally most often have companion objects be parts of the public API in `interface`s, so the constructor isn't a thing to even think about in these cases 🙂

[Joffrey]

Yeah in that case it's indeed still up for debate, but as I said consistency is useful so people know where to look for things. So if I put it at the end of every class, I may as well do this in interfaces too 😄

[louiscad]

Pragamtism 😛

[louiscad]

I personally have no rule besides "it works" and "most important first". Thing is the latter isn't always obvious for sure, I think you might have said that

[Joffrey]

I personally have no rule besides "it works" and "most important first"

Actually same here. I don't have a hard rule that makes me put it at the end every time. But for some reason I find that this has been what works best for me almost every time (apart from the logging stuff mentioned above). I guess habit has to do with it 😆 but that's becoming circular reasoning. I have a habit of being consistent, and I like the consistency of my habit 😛

[Xad Kile]

I always put them at the top 😂