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 ...
For further actions, you may consider blocking this person and/or reporting abuse
I have almost nothing to say that I could summarize in the time I have for this. I am stunned anyone could actually (seemingly) seriously express these thoughts.
"Why test my own code, when there's an entire department of other people to test it?" - Are you that selfish that you don't care about what garbage you produce to other people, and you're happy to just make it "their problem" as soon as possible? Are you that ashamed of your work that you literally don't care? I just cannot comprehend this. I take pride in the fact that when I finish a task I can say with a reasonable level of confidence "it works as intended", without having to shove the responsibility of figuring out if it does to someone else.
"Takes lot of time to name things" - Do you really not comprehend WHY this is done? Because when you use
int d = 10;that might make sense to you right there and then, but it won't make sense, even to YOU, in a year or two after you've not seen that code for a while. Then nobody knows what that code does, or why it does what it does, and most importantly what it's intended to do. Seriously now? Of course you don't have to go to ridiculous lengths as you do with your particularly poor examplenumberOfDaysInTrailPeriod[sic], just usetrialDaysor similar and it's MUCH clearer thand."Needs unnecessary separation between modules" - What magic book of rules has told you to unnecessarily separate modules? Move code into modules when it makes sense, i.e. when you need the same code somewhere else and want both of those uses to update at the same time. If there is no reason to avoid duplication, don't just deduplicate for the sake of deduplication.
"Not allowing to add comments" - Another mind-blowing statement from a magic book of rules you must have stashed in your shelf. Yes, add comments to places worth comments. However, if your code needs comments, you should probably think about why it's so unclear that it needs comments. There are valid answers that lead to the decision "yes, adding a comment is the right choice".
"The main purpose of unit testing is to see if our code is working as expected or not" - AND much more importantly than to check if what you wrote now works, it is to ensure it also works in the future, and to notice when it breaks due to an unexpected interaction with another change somewhere else possibly by someone else.
"Unit testing unnecessarily forces us to split our big good fat functions to smaller chunks." - Where exactly does it say that in the name "unit testing"? Write your big functions if you want to, just write tests for them as well. I really can't think of a single unit testing framework that enforces a maximum number of lines or your code will fail, but many organizations do enforce that kind of rules for various reasons, mainly readability.
"I don't understand what makes them think to hide implementations behind these interfaces?" - Clearly you don't. One obvious BIG reason is so the implementation can be changed without all the uses being changed. Have a search function? Great, make a clear search interface so when you upgrade from your current search solution to a better system only the code inside the search implementation has to be changed and nothing outside it, assuming you did a good job.
"Force to make intentional errors first and then solve them." - What on earth are you talking about? TDD has nothing to do with INTRODUCING an error first and then solving it, but instead e.g. when you try to solve a bug, you first write a test that reproduces that bug and then you fix it, so you can confirm that you actually fixed the bug. Some people might go to extremes with it by first writing a full set of tests for their code that they haven't written at all, but not even that is as ignorant at what you're proposing, that TDD is "a nightmare". The point of it is to have good unit test coverage so you notice when something breaks and you have good ways to check if you have actually fixed the issue later on.
"So just chill and write a code that just works!" - What an incredibly ignorant statement to make after you've proposed you write code without any tests, and is an unreadable and unmaintainable mess. Good luck with your "just works" when you shove the garbage you produced to your QA department.
In short this post seems like a disastrous tantrum -post by an ignorant non-professional. Take pride in your work, strive to make great code that is maintainable and understandable to other people as well and long after you leave the company. Take everything this post says as something to avoid. The person who wrote this should not be working as a programmer.
I tried my best to put it in sarcastic manner, but may be I fall short to reach clear sarcasm
Glad I read this comment... This article is upsetting
Fair enough. I thought from the title that it must be satire, but the way it is written makes it sound like you are 100% serious.
Thanks for the clarification.
You really should place a "This is supposed to be sarcasm people" disclaimer in the article, because it's blowing up all over and it's going to damage your reputation as a developer at this rate.
sarcasm
Keep your day job.
Calm down. It's pretty clearly satire.
As an avid satirist, I have to disagree. None of the classic signals of satire are present, and I suspect that you and I have both met people who could write something like this in complete seriousness.
Admittedly, the response is pretty harsh. The article indicates a lack of experience rather than total lack of aptitude for software development.
Nah, assuming lack of satire I don't think it was harsh at all.
It sounds like the person HAS some experience, and that experience has taught him about TDD, Unit Testing, naming, etc. and they decided against all those things as simply slowing them down from doing their thing.
A person following these guidelines would generate more work for others than they would solve with their own work, i.e. they would generate negative effort towards solving problems. Simply having them not be around would make any company do better.
This would highlight a problem with personality rather than lack of experience.
I will try to be respectful, but this post actually upsets me, and I disagree with everything that you have said. In fact, I tend to think that any seasoned developer would take issue with your tenet of "clean code doesn't matter."
Your argument for dirty code is that it reduces the amount of effort required of the developer. Nothing could be further from the truth. Writing code is relatively easy, and writing cohesive, DRY, modular code with well-named methods and variables is only slightly harder than writing spaghetti code with poor variable names (once you know how to do the former). On the other hand, reading clean code is several orders of magnitude easier than reading poor code. And almost every developer spends far more time reading code (a prerequisite for modifying it, building upon it, or fixing it) than writing it.
My counterpoints to each of your statements are as follows:
Naming things. You say that a developer can just debug your code and find out what
drefers to. What if your app has more than one variable? If you're dealing with a complex feature that uses seven, eight, or a hundred variables, you'll go absolutely nuts if they're all named alphabetically--you'll forget what the first one is for before you've figured out what the sixth one is for. Also, forcing another developer to enter debug mode in order to understand your code is a terrible tax to impose on them. On the other hand, there is no downside to well-named variables, even ones with very long names. The extra characters will have no impact post-compilation. But they will make your code easy to understand on sight, which will save you and others a lot of time and effort. Yes, it takes a few extra seconds or minutes to think of a good variable name. But software developers are expected to think hard about their job.Loose coupling. You say that you don't understand the value of interfaces. Here it is: a good interface prevents you from having to read an entire module in order to use it. Have you ever read the documentation for a third-party library or package? Thank goodness you don't have to read the code itself to figure out how to use it. A good module hides everything that you shouldn't have to know about or think about. That makes your job easier. You say that "no one is going to disturb that implementation." That's a false and dangerous assumption; the nature of code is change. Every popular package on GitHub has been through several versions, and there's even a commonly-accepted versioning system (semver) based on the idea that interfaces should remain mostly stable. This can only happen when those interfaces are as simple and as sensible as possible.
Unit tests. The main purpose of unit tests is not to see if our code is working or not, but to allow us to modify and extend it without breaking anything. It is instant almost-proof that your changes are correct. Unit tests also make it easier for other developers to understand your code, by allowing them to see the outputs for a given set of inputs. You may have QA testers on your team, but they are human--this makes them imperfect, inconsistent, and slow. Furthermore, they can tell you when something is wrong, but they can't tell you where the problem is, whereas a unit test can. Unit tests are far superior at their intended use. Additionally, there's no such thing as a "big good fat function". The best functions are clear about their purpose and intent, and usually composed of many smaller functions. This makes their functionality shareable and gives you more confidence when fixing a problem in an isolated area of the function.
Readability. Your claim that it's easy to understand code by executing it is superficial at best. Most applications aren't lone functions with well-defined outputs; they're complex and multi-faceted, with incredible amounts of business logic being evaluated under the hood. And at some point, you will have to understand the code itself in order to maintain it. There's no way around that. And no software guru has ever recommended that you stop writing comments--just that you shouldn't use comments as a replacement for good code. I have rarely seen a comment that was as useful as a good variable name.
TDD. The purpose of TDD isn't to intentionally make mistakes. It's to prove that our software does what we originally intended it to do. You write a unit test for the code that you're about to write (it fails, but this is not a mistake). You implement code that satisfies the test. And you're done. It's literally two steps. Yes, this takes time. Yes, unit tests can be bulky. But this gives you confidence in your code, piece-by-piece, that you cannot achieve any other way, and prevents you from making little mistakes that may someday break production code.
Writing dirty code doesn't just waste a lot of time (for you and other developers). It results in a project that cannot scale or be maintained. If you walk into a project with multi-thousand-line functions, no shared code, overcomplicated interfaces, and no unit tests, you will be constantly frustrated until you rewrite it or move on to a different project. Dirty code is never dependable and you can never be sure that it's working right.
If we were perfect developers, perhaps we could just "go straight forward and start without making any errors." But we're not; we all write bugs. Writing clean code is an invaluable mark of humility in a developer, because it signals that they recognize their imperfections, and are willing to put a little more effort into their work product so that it can be understood by others, fixed when it is broken, modified when it's no longer sufficient, and deleted when it's no longer needed.
I wish you luck in your programming career and fully expect that you'll discover the value of clean code sooner or later.
Cunningham's Law states "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
I tried to write as if I'm dirty coder and how would I react if someone told me about clean coding. I saw people thinking in a way I wrote in this post. I wrote it straight forword thinking anyone who knows little bit about clean code would disagree with me and eventualy realize that this is dirty coders point of view. I put sketch at the bottom which depicts the fact that dirty coders likes to code as they are doing since they started and don't want to adopt clean coding standards. I hope this will clears the air.
Yes, that's good to know. There are two issues you should consider here:
I didn't understand your sketch. Maybe it needs a caption.
This is a classic case of Poe's Law. It's possible that a dirty coder reading this would feel that they've gained justification for their actions, which would damage their career and make a heavy workload for those who work with them.
With satire or parody, I find it's almost always wise to clearly label it as such. I'd feel bad for you if a potential employer found this article and thought you really felt that way!
Guys, as some mentioned its confusing, plz tell if I should add some 😊or 😜 in post to make it clear that this is nothing but a satire and sarcasm!
I wasn't sure it was satire and sarcasm until I saw your discussion comment.
I would add this at the very top:
#define SATIRE 1
#define SARCASM 1
And this at the very bottom:
#undef SARCASM
#undef SATIRE
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"
Yes please add something to make it more clear that this is sarcasm.
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...
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.
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 :-).
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.
Sarcasm it's supposed to be funny. If it's not funny, it's not sarcasm.
If I were you, of just delete this post. Before hiring, I'd find this with your name on it and it's not obviously sarcastic.
As a developer i'll quit if I had to maintain code not tested... Naming convention on variables and functions is essential to me too, I use name casting to do so. If you follow your article you end with unmaintainable spaghetti code in my personal opinion.
Why quit? For me, it's a challenge to maintain code not tested. As one of my fellow architect said, "any code that isn't tested, is legacy code". Writing tests for legacy code it's one of my favorite parts of a project. I feel like a little Sherlock Holmes.
The scary part is even when this is satire, there are actual people out there thinking these exact same things.
Thanks for sharing this Dattatraya, this is one of my favorite post on all dev.to 😂!
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"