File naming conventions for Kotlin

Kotlin removes the Java "one top-level public class per file" restriction, which I've learned to love. I wonder if there are reasons for this discussed somewhere and whether there are some guidelines how to deal with this new freedom?

You can still use that Java rule as a convention and name your files after your classes. Or you can start putting more classes into a single Kotlin file, in which situation I'd recommend naming the files after their purpose. Each file will usually contain classes or other top-level elements that are related to each other (if they are not, maybe they don't belong to the same file in the first place?). There should be single word or a small number of words that express the purpose of all the classes in a single file, which is then a natural candidate for the file name.

On [Kotling.org](

[To see links please register here]

) you can find the [Coding Conventions](

[To see links please register here]

) document that answers to all your doubts.

If I may, I think these sections taken from the aforementioned page may be useful to you:

> Source file names
>
> If a Kotlin file contains a single class (potentially with related top-level declarations), its name should be the same as the name of the class, with the .kt extension appended. If a file contains multiple classes, or only top-level declarations, choose a name describing what the file contains, and name the file accordingly. Use camel humps with an uppercase first letter (e.g. ProcessDeclarations.kt).
>
> The name of the file should describe what the code in the file does. Therefore, you should avoid using meaningless words such as "Util" in file names.

and...

> Source file organization
>
> Placing multiple declarations (classes, top-level functions or properties) in the same Kotlin source file is encouraged as long as these declarations are closely related to each other semantically and the file size remains reasonable (not exceeding a few hundred lines).
> In particular, when defining extension functions for a class which are relevant for all clients of this class, put them in the same file where the class itself is defined. When defining extension functions that make sense only for a specific client, put them next to the code of that client. Do not create files just to hold "all extensions of Foo".

**Refer to the document for any other concern you may have.**

I think that the main point is chosing a coding convention that works for your team. That said, I think this Kotlin.org convention could be considered as a sort of standard, that I would expect to be at least known, if not followed, by any Kotlin developer, and the default choice for any project unless there are compelling reasons to change.