Android Kotlin Basics – Camel Case Or Underscore Notation

About This Series

This “Android Kotlin Basics” blog series is all about fundamentals. We’ll take a look at the basics of building Android apps with Kotlin from the SUPER basics, to the standard basics, to the not-so-basics. We’ll also be drawing comparisons to how things are done in Kotlin vs. Java and some other programming languages to build Android apps (like C# and Xamarin or JavaScript/TypeScript for Hybrid implementations).

Check Out the Pluralsight Course!

If you like this series, be sure to check out my course on Pluralsight – Building Android Apps with Kotlin: Getting Started where you can learn more while building your own real-world application in Kotlin along the way. You can also join the conversation and test your knowledge throughout the course with learning checks through each module!

Watch it here: https://app.pluralsight.com/library/courses/building-android-apps-kotlin-getting-started/table-of-contents

Camel Case Or Underscore Notation

I get this type of question quite often – “If the Kotlin Android extensions allow for creating Kotlin members in my Activities, should I be using underscore IDs or camel case”?

If this question doesn’t make sense, first take a look at one of my earlier posts in this series: Android Kotlin Basics – Auto-mapping Views. The short version is that Kotlin ships with Android extensions to create properties in your Activity (and more) for your Views within the layout resource applied in the setContentView call in the onCreate override function.

Here’s the predicament – traditional Android development has set a standard for using underscores for Ids and other properties within xml resources (such as the layouts we are talking about). So that looks like this:

res/layout/activity_main.xml

...

...

Doing this would create a usable EditText property in the associated MainActivity whose name is first_name:

MainActivity.kt

class MainActivity : Activity() {
    override fun onCreate(savedInstance: Bundle?) {
        super.onCreate(savedInstance)
        setContentView(R.layout.activity_main)

        first_name.text = "My First Name!"
    }
}

So the underscore seems to look a bit off in your Kotlin code since every other member and function within a class is typically came cased. So the other option is to start camel casing your xml property values:

res/layout/activity_main.xml

...

...

Doing this would create a usable EditText property in the associated MainActivity whose name is firstName:

MainActivity.kt

class MainActivity : Activity() {
    override fun onCreate(savedInstance: Bundle?) {
        super.onCreate(savedInstance)
        setContentView(R.layout.activity_main)

        firstName.text = "My First Name!"
    }
}

Of course these are just semantics, and I’ve seen projects go either way. I personally use the underscore for Android resources simply because it is still habit, but I may find myself moving more toward camel casing. The argument I hear against moving in that direction is also that the file names themselves use the underscore naming convention, and THAT convention stemmed from an actual restriction in Android development where resource files couldn’t have any uppercased letters. That is no longer really enforced, so it should be fine to name your resource files with a camel case convention as well.

My final suggestion is to simply pick one, but stick to it. Meaning, choose up front when you start your project and be consistent throughout – including your file names. If you want to camelCase, do it everywhere. If you want to underscore_case, do it everywhere. This will allow for onboarding developers easily regardless of which you pick. But who knows… maybe this will sprout another tabs vs spaces type of debate.

Let me know which one you personally prefer!

---

Also, let me know what else you’d like to learn about with Android and Kotlin! Either drop a comment here or tweet at me @Suave_Pirate!

If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Interested in sponsoring developer content? Message @Suave_Pirate on twitter for details.