Kotlin- TODO or Die

3 min readMar 30, 2019

Explosive PlaceHolders/TODOs

It’s important to have the feature implemented first and then later focus on its optimisation. As a software engineer, our itch to find out what’s the best and effective approach to do something often takes lots of our productive time. I will like to share some of the Protips that I discovered going through many articles and personal experience.

# ProTip1: “ Done is better than perfect ”, start with basic remove all complexities and get a feature done.

# ProTip2: “ Perfection comes with time”, and that also true for your codebase. As a developer, you will be spending most of the time in reading code (and procasting if you don’t follow ProTip1). with that, you learn many new things daily and you keep refactoring you code accordingly.

# ProTip3: “Most of time, READABILITY is the only optimisation you will ever need”, as from my ProTip2, if you gonna spend lot’s of your time reading code, why not make it conformable for your eyes, Kotlin has many ways for such. (Spoilers: Soon a series for Idomatic Kotlin will be out, I will try to help make your codebase clean.)

# ProTip4: “Leaving behind a TODO”, I understand, when you are coding all the technical articles, best practices and design patterns just floods in your mind, and I don’t want you the throw them out instead just leave it in a todo comment. Android studio has lint which highlights your todos for later revisits, they are only for your experiments not for user values. If they are adding user values they should be part of your basic.

So? All this for jubrish for todo comments?

well, NO!. Todos plays a very important role in my codebase, with Kotlin I realized, Todos isn't just a comment anymore, it can be part of your codebase as well.

In Kotlin Standard Library,

fun TODO(reason: String): Nothing

Always throws NotImplementedError stating that operation is not implemented and the reason is an optional string explaining why the implementation is missing.

And the point is?

With every conditional statement in our code, we are branching out our program into a different workflow. Personally, for me It’s also a noise, I often jump between workflows completing smaller one and come back to original, I would have forgotten half of the stuff and have to go through a majority of the implementation again.

For this reason, I started to use Kotlin Todos in my flows. for instance, see the code below :

How does it help?

Android Studio Compiler won't give any warning or show any error of un-implemented branch, not visually distracting me.
Searching for TODO in a file takes me to the flows which are left unimplemented. I don’t need to sign in or go to another tool to check leftovers.
Jumping between workflows if I ever forget to implement this feature it will crash with the following exception: Exception in thread “main” kotlin.NotImplementedError: An operation is not implemented: action 3 is work in progress

Is it safe for Production code?

The question if using Todo in the workflow will blow my code is it safe to use it? Imagine a scenario where I by mistake push it in my production code and all of a sudden my crash report tool will go insane!. Or I’m using crash report tool in my development build as I cant crash my code. Or I share development build with my test team, they are complaining about the crash on pressing this and that button.

Firstly, well yes, in fact, these are cases you need to handle, make sure you always complete your Todos and don't be stupid enough to release an apk without completing your Todos or leaving it open for user action to trigger it.

Secondly, Instead of using TODO directly you can use a wrapper function like below :

Thirdly, WHY? are you sharing development apks with Testers? use create test apk for testers. #ProTip5: Use CI/CD to send test apk to your testers using Crashlytics distribution, no more hassle for send emails with complex changelogs. Will be sharing how to setup CI/CD soon.