Is there a technical reason the compiler plugin te...
# compiler
z
Is there a technical reason the compiler plugin template inlines away the language source root (i.e. no
src/main/kotlin
) for sources or just preference?
j
I thought this was that (ahem... terrible) advice from the coding conventions no one follows. But turns out that one is even worse: https://kotlinlang.org/docs/coding-conventions.html#directory-structure
h
IMHO the coding convention does not apply to the src/main/kotlin source root that’s defined by the ant/maven style.
And I think, the style from the kotlin repo is influenced by the (old) JetBrains build tool JPS
j
I thought ant style was more to have src/ resources/ and tests/ top-level
h
Might be, don’t know ant so well, but src/main/java etc. is definitely the maven style 😅
nod 1
d
Jake is right that this style is inherited from the kotlin project. But the real reason is that I hate the default maven style layout and remove it from any project I create.
1
e
I'm on the side of the template.
src/main/kotlin/...
is atrocious.
j
it scales well to multiple source sets and multiple languages. calling it atrocious is pretty hyperbolic. in personal projects i don't think anyone would care one way or the other. in templates i would hope we'd all choose something that's appropriate and comfortable for the masses.
👍🏾 1
👍 2
i prefer tab indents and having them set to occupy only two spaces, but i'd still use four space indents if I had to build a Kotlin template
e
Fair, I was exaggerating. It does scale well and I only use the shorter
src | resources
in personal or small projects.
d
Well, for mixing java/kotlin projects layout with separate directories actually harms: • You still can put kotlin sources in the java directory, which kinda defeat the purpose • You can't do it vice versa, which is wtf • It contradicts the kotlin idea of seamless interoperability with java. Like, by design, in a mixed project you can just add a new kotlin file along with existing java and it works. You can convert any java file to kotlin and it works. So there is not much difference between languages. But splitting the languages by directories makes it look like there is a difference.
j
We have a few projects with src/main/c, src/main/proto, src/main/sql, etc.
d
For other combinations of languages the layout could make sense, I just haven't worked with such a scenario. The only case I met is the proto sourceset, in which languages are actually different.
And my final point: for single-language projects there is no sense to specify the name of this language in each sourceset of each module.
g
the package structure with the common root package omitted
I tried it a couple of times to use in a smaller projects, and it never worked for me well. IDEA works poorly with it; it always tries to add packages and create directories where it shouldn't. And the worst of all, with refactoring often removes package Maybe there is some IDE setting to make it work better, but I really had hard time with this recommendation and never used it after this And just in case, It was in multi-module project, maybe this why it fails, maybe it's fine if project is only one module
But the real reason is that I hate the default maven style layout and remove it from any project I create
I agree with Jake. It would be fine, if Kotlin plugin somehow support it, but having custom source set config in Gradle just for this is not relly great IMO,
c
image.png
Though I probably wouldn't separate Java and Kotlin in the usual case, I think it's useful to have technology-aware directories. But I think I'd be fine with
src/<lang>
and
test/<lang>
instead of the three-levels deep hierarchy.
z
As long as we all agree indent spacing should grow exponentially to encourage better code separation
1
j
I believe I had a tweet about Fibonacci indentation
Nah I just pulled an AI and claimed someone else's sovereign work as my own https://twitter.com/RichardWestenra/status/765488378951376896
z
Evergreen
🌲 5