Dattatraya Anarase

Posted on Aug 18, 2017

Advantages(!) of Dirty Code

#cleancode #programming #tdd #unittesting

Originally posted on my blog site.

First and foremost advantage for me is that I don't need to define it; ðŸ˜Š! Almost everyone, who have written any kind of program, knows what dirty code is; whether or not everyone realizes it is another story.

Internet is flooded with principles, rules, techniques, best practices, how-to steps to write code. And now-a-days almost every programmer is also talking about some kind of techniques to follow while writing code in respective programming languages. While using such techniques in writing code we have to follow lots of rules and best practices. Ultimately it puts many constraints to write code freely, slows us down, makes us fail to achieve time-lines of deliveries, and much more pain than any real programmer can imagine.

Here is high-level summary of side-effect of following such practices:

Takes lot of time to name things
Needs unnecessary separation between modules
Makes us write lot of extra code which never will be in product builds
Not allowing to add comments
Force to make intentional errors first and then solve them Let's get into more details of these side effects and see how painful they are.

Naming Things

Many people around internet talks about giving meaningful names to variables, functions, classes, modules and their necessity. But why it is so necessary? What will happen if you name a variable d instead of numberOfDaysInTrailPeriod?

int d = 10;
int numberOfDaysInTrailPeriod = 10;

No error will be generated by compiler and nothing is going to break runtime either.
Similarly this

int rdsTrail(){//code}
int remainingDaysInTrailPeriod(){//code}

Come on, let's not waste our time thinking appropriate and meaningful names for things.

If we ourselves in future or anyone else is going to work on this code later will debug and understand what int d and what int rdsTrail() stands for.

De-coupling of Modules

This is another most discussed topic under some techniques when writing bigger projects which contains many modules interacting with each other. This is also brought on when writing interfaces for modules. I don't understand what makes them think to hide implementations behind these interfaces? They call it some kind of abstraction.
No one is going to disturb that implementation. Here we are already tired implementing new features and fixing bugs; and why should we go and change others' implementations.
And why should we keep fine separation between modules if they are interacting with each other so intensely and so frequently? We have written modules for our project and our project is useless if we remove any of the modules. Then why think as if we are going to use each module separately and independently.

If in future we need to replace any module then just modify respective code according to new module, or if need to reuse it in any other project just rewrite it.

Unit Tests

Yet another myth of programmers, just to put more and more efforts and time writing simple piece of code which will take no more than a minute. The main purpose of unit testing is to see if our code is working as expected or not, but if there are QAs and testers sitting next to us why should we bother about testing code by ourselves?
Unit testing unnecessarily forces us to split our big good fat functions to smaller chunks. Putting limit to number of lines in functions also puts limit to our speed of writing them. Also why would we always follow the rule of single responsibility and top to bottom flow of functions calls? It's of course going to slow us down.

If anyone wants to test workability of code after making some changes or adding more code then he/she should just have to give program to testers.

Readability

People also says that code should written in a way that not only computers but also humans can understand it. Again, if we tried to follow this rule then we need to waste our time writing code which can easily be understood by another programmers just by reading it. But, simply, if we are having such beautiful and powerful IDEs why programmers need to read code instead of run it and watch output direct.
Another constraint they put here is no more comments in code. All the IDEs support adding comments in code. Instead of trying to make it understandable by just reading code, let's put comments wherever needed to explain. In above example, we can add comment like

int d = 10; //number of days in trail period

There is nothing wrong in this, neither compiler throws error nor compiled build will include these comments.

If we are worrying about understandability of our code by reading, let them understand it by debugging it or by reading console logs or simply by reading comments.

TDD

Now I can use this word, NIGHTMARE! TDD is nothing but a nightmare to all programmers, particularly to one who actually follows it. Make a mistake, correct it; again make another, correct it... How silly is this? And this flow, believe me, creates another parallel program that is bigger than actual program, also takes more than double time. And what purpose this serves is forces us to follow all above rules.
To make even very small modifications we need to first modify respective tests or to add small code we need to first write test. That is we have to think about test first and then implementation; isn't it time consuming?

Instead of let tests drive our development why can't we go straight forward and start without making any errors.

At the end

I would like to argue you about not fall for what people are saying and just ignore following side-features of our code:

Easy to read, understand
Easy to replace modules, algos
Easy to debug and fix bugs
Easy to modify and reuse
Easy to add new features We can think of these whenever it's required in future. So just chill and write a code that just works!

You know what do I mean by this blog post...!!!
(Image Courtesy: rathod.milan053@gmail.com)
If you are on either side of coding, dirty side or whatever the other side, please leave comments and give a ðŸ‘ !

References: Uncle Bob's Clean Code

Latest comments (29)

Christian Vasquez • Jan 8 '18

Thanks for sharing this Dattatraya, this is one of my favorite post on all dev.to 😂!

Luis Ventura • Nov 29 '17

You urgently need to add a disclaimer at the beginning of the post stating the (poorly executed) sarcasm in this post. It does feel as a legit article and even though there's a very important point in it to be made.

It's been around since August and I saw it on an sponsored post if I'm not wrong. Add some //comments to state your intentions. Otherwise it's very clever.

Hung Luong • Nov 26 '17

The scary part is even when this is satire, there are actual people out there thinking these exact same things.

Chantal Roth • Aug 21 '17

Despite the sarcasm, I think there is a point to some of it :-).
I have seen teams where the TDD is so extreme that people would write tests just because one has to write tests (because otherwise the code metrics would not pass), instead of focusing on the tests that matter.

Because at the end, all these tests don't help if the most important tests are missing, plus it adds so much overhead (tests have to be maintained), that it can be counter productive. I feel that sometimes people take the rules to literally without thinking about why the rules exist and when they make sense.

I have seen code where the modularization is taken to such an extreme, with long hierarchies interfaces and so many levels of code and gazillion tiny classes with hardly any code, making the code much less readable.

In general I think people need to take any rule with a grain of salt, and break it occasionally when it makes sense, and not blindly accept them.

Chantal Roth • Aug 21 '17

Even if this is sarcasm, I think there is a point to some of it :-).
I have seen teams where the TDD is so extreme that people would write tests just because one has to write tests (because otherwise the code metrics would not pass), instead of focusing on the tests that matter. Because at the end, all these tests don't help if the most important tests are missing, plus it adds so much overhead (tests have to be maintained), that it is really counter productive. I feel that sometimes people also take the rules to litterally without thinking about why the rules exist and when they make sense. I have seen code where the modularization is taken to such an extreme, that the end results is gazillion interfaces and levels that are never used at the end, making the code less readable. In general I think people need to be more critical of any new paradigm :-). So to me, pieces like this help to think about what we are doing and why :-).

Eric Lafontaine • Aug 20 '17

Please Don't add anything... I wasn't sure at first until i've read the tdd part XD. It's a nice "take thing into perspectives"

Samuel A. • Aug 20 '17

Brilliant! This article is brilliant! Effectively and accurately depicting careless and selfish dirty coders state of mind (and I know some), while subtly emphasizing the utmost necessity of such tools and conventions. The strong reactions only confirm the accuracy of what you wrote, take it as compliment! I myself was getting crazy reading your post :)
But I'd like to hear the dirty coders, what are your arguments in favor of your coding style? And please forget about speed, which is nothing more than an illusion, giving you immediate satisfaction and coming at you like a boomerang when maintenance comes...