Kotlin - First Impression

Trent — Sun, 07 Jan 2018 16:23:21 +0000

It's been 3 weeks since I started a new project written entirely in Kotlin. These 3 weeks were great. I could enjoy functional programming from my Scala experience with strict static typing I always love. All of this, without sacrificing productivity. Great Kotlin features that I keep using are :

Data Class

You can create immutable value classes with just one line of code. Java can do this too, but it's almost too verbose for Java to use it this way. It is very useful for declaring custom data types with small number of values. I mostly use it to enhance static typing of certain primitive type value sets. It is possible to include compile-time type checks for almost everything, while making code more concise and readable with less error-prone variable handling. Destructuring Declarations makes it more easy and convenient to use.

Extension Functions

Extension Functions really make Kotlin special compared to Java. It is almost too powerful, yet I find myself using it constantly. All the methods in Android you wish the library already had - whether it's simply starting an Activity or opening a Camera with specific parameters - are in your finger tips, such that you can customize the framework(or the language) any way you want. Be careful not to include any external state(variable) in the methods though. It might unnecessarily complicate the program(it would be similar to using a singleton to store state). If you are using Extension Functions merely for syntactic sugar, I suggest you decide the scope of the method carefully.

Higher-order functions(let, apply, run, use etc.)

Functions like let, apply, run, use are very valuable for keeping a clear code. They help to separate procedural code into blocks of operations performed on a variable. This is very useful, because even with Extension Functions it's impractical to hide all sequential operations to a variable in a separate function. In this aspect, apply is very interesting, in that it is designed to couple variable assignment with custom initialization. Combined with ? operator, those functions can also keep unnecessary null checks to a minimum. Use them generously. Just keep in mind to don't nest them too much. In fact, I never nest them. It would introduce unnecessary depth, along with possible it & this & return headaches.

All in all, I think Kotlin is a very satisfying language. I plan to dive more deeper into the language, and explore more techniques for writing cleaner, more manageable code. I suggest you do too. Until next time!

Structure Over Familiarity

Trent — Sat, 21 Oct 2017 09:16:07 +0000

Cross-post from Trent's Dev Blog.

Always prefer good structure over familiarity.

It worries me when some team members prefer shorter code & familiarity over maintainability & extensibility. To me, these aspects sound quite arbitrary. I think these aspects are more of a QoL(Quality of Life) improvements for the first developer working on the code, than actual better code. Good qualities to have, but not quite necessary. As modern software industry develops, codebases are getting larger and larger, and more people are being involved in a project. Thus, it is more important to write good structured code that team members can easily understand, compared to certain QoL improvements for the first writer.

Also, some people argue that it is faster to program writing badly structured code. I argue that there is no trade-off between program time & code quality - in fact, I think quite the opposite, that it is faster to program even a mildly interesting program using good code structure. Program with good structure may have more LOC compared to a hack job, but LOC doesn't necessarily equate time spent programming. Following a properly-learned good program structure helps a developer arrange program requirements into strict categories, thus helping them to make decisions faster and execute in confident manner. They can program freely, confident that their program will be easily readable & maintainable, and function correctly.

In summary, following a good code structure is to be preferred against shorter code or familiarity. Also, it's a myth that it takes more time to program using a good code structure. We should strive to break out of the mold we are used to, and always improve, to write good structured code that can ease life for others.

DEV Community: Trent

Kotlin - First Impression

Structure Over Familiarity