In our previous blog, we discussed some of the tips to write clean code. However, those are not just enough for better programming. Instead, there are some points to take care which helps in writing more better code.
And, here in part 2, we will majorly focus on those points which were not been covered in Part1 such as Exception Handling, Data Structures & Unit Test. So, let’s begin with Data Structures.
Object and Data Structures
Before moving forward let’s understand both these terminologies. In brief, Object is just about storing data & Data Structures is about how to manipulate that data.
Data structures make it easy to add new functions without changing the existing data structures. OO code(using objects), makes it easy to add new classes without changing existing functions.
Tips:
Variables should be private so that we can change their type or implementation when required. There is no need to add getters/setter to each variable to expose them as public.
Hiding implementation is not just a matter of putting a layer of functions between the variables. Hiding implementation is about abstractions! We do not want to expose details of data but rather express data as abstract terms.
Exception Handling
Try and extract try-catch blocks into separate well-named functions. Having them mixed with other code just confuses the structure of the program. As it is already mentioned in Robert C Martin Clean Codebook that Function should do one thing & Error handling is one thing.
Prefer returning Exceptions instead of Error Codes.
Each exception that you throw should provide enough context to determine the source and location of an error.
Don’t return & pass null:
Returning null from methods is bad, but passing null into methods is worse. Unless you are working with an API that expects you to pass null, you should avoid passing null in your code whenever possible.
Unit Tests
Three Laws of TDD(Test Driven Development)
- First Law You may not write production code until you have written a failing unit test.
- Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
- Third Law You may not write more production code than is sufficient to pass the currently failing test.
Clean tests follow five other rules that form the above acronym:
Fast Tests should be fast. They should run quickly. When tests run slow, you won’t want to run them frequently
Independent Tests should not depend on each other. One test should not set up the conditions for the next test. You should be able to run each test independently and run the tests in any order you like.
Repeatable Tests should be repeatable in any environment. You should be able to run the tests in the production environment, in the QA environment, and on your laptop while riding home on the train without a network. If your tests aren’t repeatable in any environment, then you’ll always have an excuse for why they fail. You’ll also find yourself unable to run the tests when the environment isn’t available.
Self-Validating tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass. You should not have to manually compare two different text files to see whether the tests pass. If the tests aren’t self-validating, then failure can become subjective and running the tests can require a long manual evaluation.
Timely tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable.
So, this was all about writing clean code for better programming.
If you like this blog, please do show your appreciation by hitting like button and sharing this blog. Also, drop any comments about the post & improvements if needed. Till then HAPPY LEARNING.
