I start seeing in many repos that Kotlin file names are starting small letter like `resourceProvider...

# codingconventions

[Mustafa Ozhan]

I start seeing in many repos that Kotlin file names are starting small letter like resourceProvider.kt or viewExt.kt .
Is it an official convention? I couldn’t find anything in Coding Conventions about it

[Joffrey]

Technically from your own link:
https://kotlinlang.org/docs/coding-conventions.html#source-file-names

If a Kotlin file contains a single class or interface (potentially with related top-level declarations), its name should be the same as the name of the class, with the .kt extension appended. It applies to all types of classes and interfaces. 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 upper camel case with an uppercase first letter (also known as Pascal case), for example, ProcessDeclarations.kt.

That said, I have seen both lowerCamelCase and UpperCamelCase (depending on projects) for files that contain more than just one type declaration.

[LeoColman]

I usually start it with lowercase if it only contains functions

[Mustafa Ozhan]

@Joffrey but it doesn’t say anywhere that it can start with small letter (lowerCamelCase)

[Mustafa Ozhan]

So it is not something official but kind a community trend ?

[LeoColman]

Use upper camel case with an uppercase first letter (also known as Pascal case), for example, ProcessDeclarations.kt.

I interpret this as lowerCamelCase being forbidden

[Joffrey]

Indeed, my point was that the official guide says uppercase first letter, and seems to forbid lowerCamelCase.

[LeoColman]

And thus yes, my code is breaking the convention, but I allow this one 🙈

[Mustafa Ozhan]

yea I thought the same.. I was wondering why people keep using lowerCamelCase and should i use it too or not 🙂

[LeoColman]

Just don't use SaRcAsMCaSe and you should be fine

[LeoColman]

https://detekt.dev/docs/rules/naming#matchingdeclarationname

[LeoColman]

Detekt seems to care a bit about the paragraph you quoted from the conventions, but I don't see this being enforced for lowercase

[Mustafa Ozhan]

I didn’t know that detekt was checking the file name also, maybe because I respect the current rule it never fail for me

[ephemient]

I recall the lower-case naming for files only containing top-level functions and extensions being recommended in the past, but I can't find it even in wayback archive

[ephemient]

there is https://napperley.medium.com/unofficial-kotlin-style-guide-a44cb899a84f but that's not official

[ephemient]

@napperley do you have any recollection around this?

[napperley]

This is a blog post I wrote a long time ago when the official coding conventions had just been released. When it comes to naming files containing multiple top level elements, or only top level functions/properties/extensions I now recommend using camel case naming. For example, textAlignment.kt (the name reflects the area being covered).

[ephemient]

I think OP is questioning the lower-case initial, though

[ephemient]

the current official styleguide says to upper-case, but I remember there used to be guidance to lowercase for files without classes. I can't find it anymore, but since you were possibly involved at the time, any recollection?

[napperley]

I had no involvement with the official style guide. Only had involvement with the community side. When it comes to file naming Kotlin should use different naming rules from Java. Keep in mind that Java to this very day still doesn't have an official style guide, and Java has an enforced file naming convention built in at the compiler level, which the Kotlin compilers don't have. Also Kotlin operates in environments that aren't JVM based (eg Native), where there isn't a "everything must be a class" restriction, hence file naming shouldn't be the same as Java's.

[Jan]

In our projects we put extensions into separate files where the name is based on the receiver that you extend. E.g. View+Extensions.kt easier to find them again. Not entirely sure where to put the classical util functions though. I'd try to avoid any collection files/folders/classes any day though. Usually people start to put in collections because they can't put their finger on the concrete problem they're solving. Or that it could be a local function instead of global one.