I completely forgot because I had been touching Kotlin for the past two months, but when a warrior (programmer) with Java eyes read Kotlin for the first time, it was quite ** slippery **. No matter how great Kotlin has Java integration, if you can't read it in the usual way, you tend to think, "It looks difficult! I like Java that I'm used to!".
Here, I will summarize the ** elements that make your eyes slippery when reading Java when reading Kotlin. It may be useful for anyone reading Kotlin code from now on.
Java
Int x = 0;
SomeClass method1(int i, String s, Date date){ ... }
Kotlin
val x: Int = 0
fun method1(i: Int, s: String, date: Date) : SomeClass { ... }
It's the so-called Scala style. Swift also writes this way. People who are accustomed to C and Java will find it difficult to read at first glance.
Remedy: ** Get used to **
Kotlin
val x = 0 //Cannot be reassigned
var y = 2 //Reassignable
x = 1 //Compile error
y = 3 // OK
val (value) cannot be reassigned, var (variable) can be reassigned. It's the same declaration method as Scala, but what you think is ** one letter difference **. As you can see from the code above, it is very difficult to distinguish the code. It's hell if you use Vi.
That said, Android Studio (IntelliJ) defaults to ** var-declared variable names that are always underlined **, so it's easy to tell if you know this rule. It's a good idea to remember that those who need attention (= var) are underlined. I don't know what's going on with other IDEs.
Remedy: ** Determined by the presence or absence of underlining **
I think many people are allergic to untyped variables. Please be assured. Variables that do not have a type are also typed properly. Since the Kotlin compiler has a type inference function, even if the type declaration is omitted when declaring a variable, the type declaration is automatically supplemented. The important thing here is that it is the compiler ** that supplements the ** type declaration. It doesn't change which type is attached depending on the state at runtime, and you can't write such code. In addition, since the ordinary type inference device returns the smallest candidate type, y is not added with Int? Or Any in the above code. If you say "The initial value is an actual value, but null can be assigned as the process progresses", let's declare that y is Int ?.
Workaround: Look at the right side of the variable definition. The type of the expression on the right side becomes the type of the variable on the left side as it is.
Java
SomeClass obj = new SomeClass(10, "aaa", new Date());
Kotlin
val obj = SomeClass(10, "aaa", Date())
Kotlin does not write new when creating an instance. If you are accustomed to Java, you will be confused because it is determined whether you are using a constructor or getInstance () based on "presence or absence of new before the class name". Since the code becomes simpler as the identifiers decrease, the readability itself seems to be zero. Also (new Nantoka (...)) doesn't have to be enclosed in parentheses.
Java
class User {
String name;
String email;
public User(String name, String email){
this.name = name;
this.email = email;
}
...
}
Kotlin
class User(val name: String, val email: String){
...
}
Kotlin's constructor (more precisely, the primary constructor) differs from java in the following ways:
These features help reduce the amount of code, but those familiar with Java, especially those familiar with the "list member variables at the beginning of the class" culture, are likely to be confused.
Workaround: It's a writer's method rather than a reader's method, but it's a good idea to devise line breaks and indentation so that you can read it with the same feeling as in Java.
Kotlin
class User (
val name: String,
val email: Stirng
) {
...
}
Java
Int result = obj.method1().method2().method3();
Kotlin
val result : Int = obj!!.method1()!!.method2()!!.method3()!!
The code is rather surprising because it is ** the anti-pattern of nullable processing in the middle **, so there is a problem with the code. If this happens when you automatically convert your java code to kotlin, let's rather rejoice, "I'm glad I found this null-unsafe code."
If I come up with other things, I will update them one by one.
Recommended Posts