Clean Code: Introduction


Two years ago I have switched from Java/Kotlin Android development to JavaScript Full Stack web development. Because of that I have a lot of new insights that I want to share with the reader. One of the biggest realizations I have had is no matter what platform or language or framework you are using, the fundamental Clean Code principles DO NO CHANGE. 

These series is dedicated to [re]discovering the Clean Code principles. Strongly influenced by "Clean Code" by Robert C. Martin, I will be covering the most important principles to writing clean, readable and maintainable code.

Good developers are modern craftsman. Knowing how to make your code do what you want it to do is easy. Making that code maintainable is the real challenge. As new abstract languages and frameworks are created, and as number of programmers doubles every 5 years, knowing how to write clean code is the most important challenge for any developer.

Good code matters!

Working mess is NOT better than nothing. It is actually worse. Bad code can bring a company down, it can bring a network down. Bad code costs money and if the code is mission critical, it can cost lives. Recent incidents with Boeing MAX has showed us the dangers of bad code.  

Make it Right!

"Going back to clean up the code" usually means NEVER. How many times have you sworn to go back to clean up and refactor the code, to find yourself months later cursing the mess it has snowballed into. The messier the code the more productivity is lost while adding new features. Every developer spends extra time trying to works with messy code. It might take longer to write clean and thought out code from the start but in the long run its exponentially more productive for the future development on that code base. Messy code requires developers to understand the entire code before making any changes. Productivity pressure makes the developers make a bigger mess over time. So redesigning the code takes more time and effort than keeping it clean from the start.

Attitude is key!

Unprofessionalism leads to bad code. Managers obsess with schedule, good developer obsesses with good, quality code. The only way to consistently meet deadlines is to keep the code as clean as possible. Messy code will bring projects to a snail pace and cause developers to miss deadlines. 

What should it look like?

  • Code has to be "elegant" or pleasing to look at.
  • Must do one thing well. Bad code tries to do too much.
  • Restricts to only one way of doing a thing rather than many.
  • Looks like it was written by someone who cares.
  • Small abstractions help move fast and change underlying implementation if needed.
  • Ratio of reading code to writing code should be actively lowered.
  • Code that is easy to read is easy to work with.
Hopefully this introduction convinced you of the importance of writing good code, and gave you some ideas to get your started. In the next post we will be covering specific techniques and rules to help you write clean code.


Comments

Post a Comment

Popular posts from this blog

Android Architecture Components : LiveData

Image
Live Data : Life-cycle aware Observables As an Android developer you often have to work with data that is dynamic and changing with user input, device configuration changes, or even time changes. On top of this as a developer you have to respect the life-cycle of an Activity of Fragment that contains this dynamically changing data: stop updates onStop() or onPause() and restart the updates onStart() and onResume() . Examples of this is location data, countdown timers, user's list selections and any other type of dynamically changing data. Lets see how we can make these tasks easier using LiveData . We will demonstrate LiveData by creating a self contained timer. Subclass LiveData LiveData object is set active when the observer's lifecycle is stated or resumed . And the LiveData object is set inactive when the observer's lifecycle is stopped or pause . In our TimerLiveData we start timer when  onActive() is called and stop the timer when  onInactive() is
Read more

Building a Cryptocurrency with Kotlin : Part 1

Image
Kotlin has been becoming more and more mature with every release. We arguably have the most concise modern programming language that currently exists. With language idioms like data classes, extensions, kotlin objects, delegated properties, lambdas and of course, the latest version of Kotlin adds coroutine support. Lets talk about Node.js for a second.  Node.js  helped us to create many amazing websites and services, and provides numerous modules to make our lives as developers easier. But just because a tool is good enough does not mean we should stop innovation there. Kotlin is now Node.js' competitor because Kotlin's powerful language idioms enable us to create a powerful and fast framework for building asynchronous servers and clients, called  Ktor . Lets go back in time for a moment. Back in 2008 a small C++ side project was started by Satoshi Nakamoto. This project would change the world for ever. 10 years later Bitcoin managed to inspire dozens of crypto currency pro
Read more

Clean Code: Meaningful Names

Image
     Names are everything! Files, classes, functions, variables all need a name, therefore we should cate about good names. Good names save more time than they take. Coming up with good descriptive names that don't confuse the developer who has to read the code in the future may come with no effort to some, but for others it may feel like a constant struggle. Readable, and intuitive names are a foundation of clean code. Let's take a look at some key principles that will help you come up with good names in your code. Intention Revealing      The name of a variable, function or class must answer questions. Why does it exist? What it does? How is it used? A variable named instance or number is not descriptive enough and requires the user (developer) to figure out the context and the type of the variable in order to know what it does, a better approach would be changing the names to userAccount and balance respectively. Naming should be explicit and explain the context and oper
Read more