Becoming A Better Developer With Clean Code - Read Time: 6 Minutes
📅 September 02, 2018
•⏱️5 min read
Introduction
Are you constantly striving to become a better developer through practice and doing stuff that scares the shit out of yourself?
If your one of the above, that's great i welcome you and let's start cracking then.
If you had never heard about the term Clean Code. It's totally alright cause i had never heard about it myself. while i was studying in university.
So this will be great primer for you to gain confidence to becoming better in our craft as a software craftsman.
What is Clean Code?
In layman terms Clean Code is basically a set of principles that you should consider.
When your developing software for your own sanity and others who had inherited your code when your gone.
It is made popular by Uncle Bob, who wrote the book called "Clean Code - A Handbook of Agile Software Craftsmanship",
In his book he layouts a ton of useful and common sense ways on developing software.
Which he has experience over the years working with developers developing software.
Stumbling Across Clean Code
I had stumbled across the book because i had been watching a lot of developer Youtube channels like Simple Programmer and Chris Hawks.
Which they talk about him and the benefits of reading the book to become a better developer.
What i had founded is the benefit of maintainability and reusability of existing code that i had wrote from 3 or 6 months ago.
As a developer especially in fast paced environment like a Startup.
It had benefited me immensity in how i approached in writing software.
Taking consideration of controlling technical debt that arises when we try to move at a fast pace to deliver value to our clients.
Boy Scout Rule
On average as a developer, we spend roughly 10:1 of our time in reading code vs writing code.
Therefore the time spent on reading, could be better spend on writing effective code along with our test cases.
This resulted in the rule by Uncle Bob, Which is the Boy Scout rule that came in the form of always leave your code better than you found.
This means that we should always improve or refactor existing code to be understandable and easier to read.
With a much better reading experience for anyone who takes over your code.
This makes it much easier for anyone to refactor and enhance a existing piece of code at a much faster pace.
I believe as a developer as you grow in your experience, you will have compilation of horror stories about messy code.
Which might took hours upon hours to fix a bug or an error that had occured in the piece of messy code.
Naming Things is Hard
As a developers we always have a trouble with naming things for a software project.
Regarding on certain features to be implemented by a general consensus on how we should build our software.
They range from pun jokes to scientific terms that only the developer.
Who wrote that particular piece of knows what does it really mean.
From RLList, ArrayBRB, ZomAdptH to lubbadubdub, which are one the few of weird names in the past for my variables, functions or classes.
That till this day makes me wonder why did i came out with those names in the first place in the past.
3 Ways for Better Naming
In Clean Code context, we should always strive to give better names for our variables, functions, classes.
Uncle Bob listed down a few pointers in giving better names below.
1) Pronounceable names - We remember better when we are able to form words from it.
Naming your variables. functions or classes has another advantage which is the ease of conversation in a engineering discussion.
2) Searchable names - It's much easier to search for a certain piece of code when we name it in a way that it is searchable in your program.
For example by searching for a variable that is called SetDateTime is much easier to be founded than setDDMMYYYY.
3) Intention Revealing Names - your names should always be able to show your intent before looking at the block of code.
Without much interpretation from you, anyone should understand what does it do without going in deeper.
Take for example StoreCustomerDetails or CreateCustomer is much easier to understand at a glance compared to CNewCust or StoreCustD.
The More the Merrier for Arguments in a Function
In the past i would unconsciously write functions with more than 2 arguments.
You might think there is no harm in writing multiple arguments in a function.
In fact by having multiple arguments, this increases the readability and makes the program complex to understand because it became longer to read due to validation of each arguments.
Therefore it is recommended to keep your arguments in a function to be less than 2 arguments and keeping your functions to be less than 30 lines.
You could also bypass this advice. By passing in arrays or lists as part of arguments if there is a real need for more arguments in the function.
Conclusion
Overall as a developer, i would heavily recommend anyone who's interested to be successful as a software craftsman,
To find the book in your local library or purchase the Clean Code book.
Due to wealth of both common sense and practical piece of advice for developers
Who would like to work less in maintaining messy legacy code that you will thank yourself for in the future when you have to rewrite or enhance your legacy code.
PS: Enjoy 20% discount from your purchase of the "Clean Code" By Robert C. Martin when you shop at Book Depository. All you need to do is to click on the link below.
PSPS: I had been their long time customer and i always look forward to their Reader Designed bookmarks when i receive the delivery.
Links
Clean Code : A Handbook of Agile Software Craftsmanship by Robert C. Martin
Boy Scout Rule to Coding
https://deviq.com/boy-scout-rule/
Why Naming Things Is Hard
https://hilton.org.uk/blog/why-naming-things-is-hard