tl;dr Kotlin properties are awesome and super powerful, but each form comes with a bunch of gotchas. Make sure you fully understand them…
Developers love properties in Kotlin, but a property is not always the right choice. Getting carried away can be risky, so when should we avoid properties?
Many people love by lazy, but it's easy to underestimate and misuse it. When should you use lateinit, and when is by lazy a better choice, as an Android developer?
In this series we're going to be looking at a few common patterns I have seen Android developers use in Kotlin, and see what's the good and bad in each, and when to use them.
Instead of writing debug logging code, you can take advantage of the IDE tools. No more log statements forgot here and there!
Use git hooks to prevent code formatting and static analysis from making your CI unhappy.
After one year of keeping the project's settings into VCS, I share my new findings. What worked? What didn't work, and how did we fix it? Read to the end for a bonus tip!
Changing the casing of some text has never been so easy as in your IDE!
How can you make sure everyone on the team is using the same IDE settings? Put the .idea folder in version control!