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 d refers 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.
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!