# getting-started

Travis Griggs

11/07/2023, 5:19 PM
I'm curious how others organize their "extension" methods/functions. When they're highly specific to just one place, I just put them at the bottom of that file. But if I have a general purpose one that I want to use throughout my project, I've tried different things. I used to put them 1:1 in a <ClassName>_extensions.kt file. More of late, I've just been glumping them by category with a misc prefix (e.g. misc_numerics.ket for any extensions on Float/Double/Int/etc or misc_temporals for all of time/datetime/calendar/etc extensions). Curious what others do


11/07/2023, 5:21 PM
Personally: • if there are not many, end of the file • if there are many, another file with the postfix "Ext" (
) • if there are not really anything else in the package, I just name them after what they do (e.g. in this package, there is a sealed class and everything else is just extension functions on it)
👍 2


11/07/2023, 5:29 PM
if they're too many to put in the same source file and there's no other sub-grouping, I tend to put them in a
file, e.g.
for functions on `Float`s

Casey Brooks

11/07/2023, 5:46 PM
I prefer the Intellij file viewer to show the symbol for class/object/etc. so I almost always keep the main class alone in its file and put the extension functions in a separate file. I usually label it with a suffix of
, because not every function in that file is strictly an “extension function”, and I guess I’m just used to the Java naming convention

Travis Griggs

11/07/2023, 8:36 PM
like the utils idea, thanks

Stephan Schröder

11/07/2023, 9:37 PM
if they are very short (1-2 lines) and only used in one function, I put them at the beginning of the function.

Klitos Kyriacou

11/08/2023, 11:46 AM
The Kotlin Coding Conventions say:
Copy code
when defining extension functions for a class which are relevant for all clients of this class, put them in the same file with the class itself. When defining extension functions that make sense only for a specific client, put them next to the code of that client. Avoid creating files just to hold all extensions of some class.
This doesn't explain what you should do if you are defining extension functions that are relevant to all clients but they are extensions of a third-party class so you can't put them in with that class. In that case, ephemient's use of the plural of the class name sounds sensible.
👍 1

Daniel Pitts

11/15/2023, 4:01 PM
I'm working on some Kotlin friendly extensions to Swing, and I tend to put extension methods related to swing classes in


11/15/2023, 11:31 PM
there's no technical issues with using
to hold extensions for classes defined in
stylistically, I think plurals work fine. after all, even Java has
for extra
functions, etc.