Meaningless variable names

Great plugin, I got some quite useless variable names though:

const val core_ktx: String = "androidx.core:core-ktx:" + Versions.core_ktx
const val core_kt: String = "ru.ztrap.iconics:core-kt:" + Versions.core_kt

They are both kotlin extensions but for very different libraries yet cant be distinguished by the variable name. As kt and ktx endings are quite common for such libraries maybe check for combinations of that and the meaningless words you already check against would be a good idea. Basically add a list of suffixes.

On the other hand some of the constants get very long:

const val jmfayard_github_io_gradle_kotlin_dsl_libs_gradle_plugin: String =
            "jmfayard.github.io.gradle-kotlin-dsl-libs:jmfayard.github.io.gradle-kotlin-dsl-libs.gradle.plugin:" + Versions.jmfayard_github_io_gradle_kotlin_dsl_libs_gradle_plugin

That’s the most extreme example I had in my projects. I’d suggest cutting common segments like github and TLDs from the name to get something like the following:

const val jmfayard_kotlin_dsl_libs_gradle_plugin: String =
            "jmfayard.github.io.gradle-kotlin-dsl-libs:jmfayard.github.io.gradle-kotlin-dsl-libs.gradle.plugin:" + Versions.jmfayard_gradle_kotlin_dsl_libs_gradle_plugin

Still long but better.

I can take a see if I can make a pull request with those changes in the next days. I’m of course open for better solutions, these are just my initial thoughts.

[ivoberger]

@IIIuminator it’s because if two libraries have the same name (here core-ktx), the plugin detects it and uses the FDQN for both. The “meaningless names” feature is that we don’t wait for the conflict to happen and always use the FDQN

yes of course. That helped me notice that I used the wrong version of the same library in one of the apps. Was already thinking something’s fishy 😄

What do you think?

sounds good to me. was thinking myself that being able to configure it might be the best solution. Using a config option it should be possible to remedy these really long names too. have a useFdqnFor and a removeFdqnFor option together with FdqnElements so its possible to configure whats removed.

[jmfayard]

That would be better but it needs to be interoperable with Groovy and so an Iterable was the simplest way to do that.