What’s the best practice for directory structure w...

# multiplatform

[Nick Halase]

What’s the best practice for directory structure within modules? In Java world, packages are king and reverse domain. What should the directory structures be within commonMain, iosMain and androidMain?

[Kris Wong]

same

[Marc Knaup]

I’ve never liked the package-oriented approach. Too annoying to navigate. Too restricted.
Also subpackages are much less important in Kotlin than in Java IMO. I rarely use them.

Most of my projects have a flat hierarchy and I only add folders in order to group functionality that belong together in a meaningful way. The classes within is not necessarily in different packages.

And then above that there are 1-2 folders per platform target - one for sources and one for testing (if needed).

See here for example:
https://github.com/fluidsonic/fluid-time/tree/master/sources

[Kris Wong]

IMHO that doesn't work well for a library project, but perhaps you if have a kind of monolithic library used only by 1 app it may work

[Marc Knaup]

Why wouldn't that work well for a library?

Other languages don't even have the notion of packages, so every library had exactly one module to import. And they work brilliantly. The total over-architecturing with plenty of packages is mostly a Java-thing.

[Kris Wong]

look at the obj-c approach - with it's silly class prefixes to enable unique class names. c++ is similar to java with namespaces.

[Marc Knaup]

ObjC is not a good example as it doesn’t have any kind of hierarchy.
Take Swift instead. It gets along just fine with only modules. No need for prefixing, no need for additional packages per module.

C++ uses less namespaces than Java uses packages. Like std::chrono vs. java.time.chrono(|.format|.temporal|.zone).

IMO if something gets so big that additional namespaces make sense, then it should be broken down into separate libraries/modules and not be nested like crazy just to have a better folder hierarchy, or for theoretical architecture = practical over-architecture. There’s rarely a benefit of the additional packages. It just adds more imports and can even add confusion if two packages in the same library/module contain a class with the same name.

[Nick Halase]

At any rate, Kotlin convention is still package -> directory doctrine (with the exception of the root common packages). I was just curious how people are organizing multi platform code.