Should I use an explicit return type for a String variable in Kotlin?-CodePudding

In Kotlin, We can declare a string read-only variable with type assignment and without type assignment (inferred) as below.

val variable_name = "Hello world"

val variable_name: String = "Hello world"

I'm trying to figure out what is the best in Kotlin and why it is the best way. Any idea?

CodePudding user response：

Personally either one works and for me nothing is wrong, but I would choose the later if this is a team project, where project size increase and feature inheritance(members leaving, new hiring or worse shuffling people) is probable. Also I consider the later as more of a courtesy.

There are situations where regardless of the dogma every member follows, such as clean architecture, design-patterns or clean-coding, bloated codes or files are always expected to occur in such big projects occasionally, so the later would help anyone especially new members to easily recognize at first glance what data type they are dealing with.

Again this this is not about right or wrong, as kotlin is created to be idiomatic, I think this is Autoboxing, it was done in kotlin for codes to be shorter and cleaner as few of its many promise, but again regardless of the language, sometimes its the developer's discretion to have a readable code or not.

This also applies with function return types, I always specify my function return types just so the "new guy" or any other developer will understand my function signatures right away, saving him tons of brain cells understanding whats going on.

fun isValidEmail() : Boolean = if (condition) true else false

fun getValidatedPerson(): Person = repository.getAuthenticatedPersonbyId(id)

fun getCurrentVisibleScreen(): @Composable ()-> Unit = composables.get()

fun getCurrentContext(): Context if (isActivity) activityContext else applicationContext

CodePudding user response：

If this is a public variable, using an explicit return type is always a good idea.

It can make the code easier to read and use. This is why your IDE probably shows the return type anyway, even when you omit it from the code. It's less important for simple properties like yours where the return type is easy to see at a glance, but when the property or method is more than a few lines it makes much more difference.
It prevents you from accidentally changing the type. With an explicit return type, if you change the contents of the property so that it doesn't actually return the correct type, you'll get an immediate compile error in that method or property. With an implicit type, if you change the contents of the method you could see cascading errors throughout your code base, making it hard to find the source of the error.
It can actually speed up your IDE! See this blog post from the JetBrains team for more information.

For private variables, explicit return types are much less important, because the above points don't generally apply.