7 ms·

Is Clean Code Necessary?

49 points by coderjean1 10y ago

greenleafjacob 10y ago
Things aren't unconditionally necessary except in modal logic. In the real world things are conditionally necessary. Clean code is necessary... for ongoing development. Clean code is necessary... to allow developers to onboard quickly. Clean code is necessary... for reducing the cognitive overhead and avoiding mistakes. Unfortunately without stating these assumptions it's impossible to prioritize and be rational about development. It provides no guidance. Should we drop everything we're doing and "clean up" the code? Is it even worth investing in? These are questions that have different answers depending on the assumptions and simply saying it's "necessary" is insufficient.
retrogradeorbit 10y ago
Clean code is not an OO concept. It's a higher level concept. SOLID may help you achieve clean code in OO, but clean code does not mean "know SOLID".
- exclusiv 10y ago
  I agree, but for the bulk of software engineers it's probably on point. For many of us, it's nothing new, but I do think that it's remarkably easy to just rip code toward a deadline unconsciously without keeping these concepts in mind. If you do backend, the user doesn't give a shit about your clean code, so sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability needs of a project which only comes from experience.
  - maze-le 10y ago
    > If you do backend, the user doesn't give a shit about your clean code It's not about the user. Coding in a 'clean' way is something you do for your colleagues and maybe future colleagues, who will have to maintain and upgrade your software in the future. > so sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability I have seen quite some hacks that were intended as 'one-time-only' and 'we-refactor-this-later' solutions. I don't think any of these trade-offs payed out in the end. The proper work to refactor crappy code and reintegrate it into the system took a whole lot of time longer than implementing it correctly in the first place. The only situation where hacks like this are acceptable in my opinion are 'one-time-only' prototypes (where the prototype code does not find its way back into the codebase), where certain features are shown to a customer, and the rest are mockups.
    - warcode 10y ago
      Often I find that clean code is something I do for my future self too. Having some external factor break your algorithm and coming back to multiple nested loops and "i,j,k,l,x,y" variable names makes it take way too long to fix.
      - DonHopkins 10y ago
        Oh cringe. Please don't use "l" as a loop index! Don't use it for anything! Make it go away!
    - exclusiv 10y ago
      Yes it is about the end user. They don't care about your backend code. They want it to work and for it to perform. Your cleaner code means nothing to the user. Sometimes you have to put more time into frontend and you're up against a tight deadline. I'd opt for the UX in most circumstances. You're assuming that there are colleagues to work on it and that it will live indefinitely. Many projects, esp. those related to marketing, have a definite lifetime. You also mention prototypes as another use-case. Cleaner code as directed by the article is not always necessary.
  - fishnchips 10y ago
    And why would the user care about your clean code on the frontend? It's usually minified anyway. Clean code is not for the user, it is for you as a developer.
    - exclusiv 10y ago
      Yes you are correct, but I'm not talking about clean code on frontend. The user doesn't care about any code. If it works, it works. I understand clean code is for the developer(s). That's precisely my point. You don't always need to go through a SOLID checklist with your project. Sometimes you have deadlines, sometimes you're the only dev and you know the project will die post-launch. So if it works; you're good. I'm not sure why this part of my original comment is confusing or controversial: "sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability needs of a project which only comes from experience" A purist push for design patterns and paradigms for every project is not based in the real-world.
- erez 10y ago
  I think the author, being a Java guy is using OO and Java as a reference point, not arguing that "this isn't applicable to non OO development". Basically he's saying that remembering the principles and practices is essential in every level of the development.
k__ 10y ago
Encapsulation and modularization is necessary, nothing more. If you get this right, you can get away with a bunch of crappy thing, because you can easily throw them out in the future and reimplement them better.
- stinos 10y ago
  Really nothing more? I beg to differ after having to plough through lines of code just yesterday where, just to give some examples - each single line uses a different formatting style - variable names are hard to read abbreviations - variable/class names don't make sense - 5 is a level of indentation easily reached - there's almost as much dead code as live code - comments are grammatical nonsense and don't explain why the code is written the way it is
  - k__ 10y ago
    Can all be fixed rather easily, if there ha been good modularization. But yes, I prefer those things too, haha
    - cauterized 10y ago
      But to replace code, first you have to understand it.
      - k__ 10y ago
        Modules have an api and a responsibility, often this +any code helps to understand whats going on good enough
- deleted 10y ago
  [deleted]
- Kenji 10y ago
  Out of curiosity, what is the largest project you've worked on, k__ (as in, number of lines)?
Bahamut 10y ago
As with everything, it depends on your requirements, including timeline, shelf-life of application, and future maintenance/feature building. Sometimes, code is a one-off and it is better to write something that works rather than worrying about the perfect implementation. One should strive for clean code when one can, but all things have tradeoffs that have to be decided for/against.
hacker_9 10y ago
Depends on the definition of necessary. If you consider living a pleasant life necessary, then the answer is yes.
mdmoss 10y ago
I think the author's statement of the Liskov substitution principle is backwards; An object must be replaceable by a subtype, not a supertype.
- coderjean1 10y ago
  Yes you are totally right. I mistyped a word. Where it says supertype I actually meant subtype. I corrected the article.
dsego 10y ago
TLDR: Yes.
- arpa 10y ago
  And here I was expecting something that will shake the core beliefs and uproot good ole Uncle Bob; alas, not the case, yet another "Yes, clean code is good, unclean baaad"; I mean, the concept is great and all, but damn, stop preaching to the choir, it will get us nowhere...
mehwoot 10y ago
Liskov Substitution: An object can be replaced by supertype without breaking the program Shouldn't that be subtype? Or am I misremembering this?
- fishnchips 10y ago
  Yup, you remember it correctly.
- ethagnawl 10y ago
  You're correct. From Wikipedia[0]: > Liskov's notion of a behavioral subtype defines a notion of substitutability for mutable objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g. correctness). 0: https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle
  - Ntrails 10y ago
    Surely it follows logically anyway? Assuming sub/super are referring to inheritance (sorry, I'm a bad), a sub contains all of a super and more. Passing through an object with more shouldn't break anything. But a super might lack things the sub has, thereby breaking assumptions about what will be present. I feel like the principle would be broken by the objects/inheritance being badly used rather than the calling code though?
    - talideon 10y ago
      LSP doesn't specifically deal with inheritance; it's equally applicable to interface implementation.
  - coderjean1 10y ago
    Yes you are totally right. I mistyped a word. Where it says supertype I actually meant subtype. I corrected the article.
- 10y ago
berntb 10y ago
Today a discussion like this make me so jealous I get vertigo... :-) Yesterday evening I spent two hours just to trace and understand the dispatch for a really simple and small part of a big, old web application. (To save time, the answer to the question you want to ask is: "Yes, glad you asked. It really is from 1999. And no, they don't know the word refactoring.")
- DonHopkins 10y ago
  At least it's a good excuse to put on a Prince album while you work.
  - berntb 10y ago
    My music of the time was more singer songwriters, balkan gypsy, modern jazz and death/black. :-)
caleblloyd 10y ago
Is Clean Code Possible? Not if you're writing ES5 JavaScript for the browser.
- jomamaxx 10y ago
  This comment should not be downvoted. It's a hard realpolitik of web programming.
  - deleted 10y ago
    [deleted]
stupidcar 10y ago
Personally, I've found that heavy application of OO patterns leads to code that is very unclean, in terms of being "simple and direct". First developers apply the single-responsibility principle, and break down previously large but comprehendible classes in thousands of tiny components. While each component is trivial on its own, the truth of how they combine to produce a particular application feature is now hidden within an implicit object graph that cannot be understood by new developers, except through a torturous process of cross-checking and debugging until they have built a fragile mental model of what's going on. Next developers get embarrassed by all the new-ing up of components they're doing, so they introduce dependency injection. But rather than just injecting those things that have a genuine need for varying implementations, suddenly everything gets to be a service. Abstractions proliferate, factory factories appear, everything is behind an interface (with a single "default" implementation), and navigating the codebase becomes a nightmare.
- noir_lord 10y ago
  Not convinced it's the application of OO patterns that leads to bad code but bad programmers (at least in the major part). I've seen clean code bases in OO/functional and pure procedural and bad code bases in those as well. I think it's tempting to blame bad code on things like bad languages and bad architectural patterns because they are externalities and can be blamed without mentioning the gorilla in the room, bad programmers write bad code. I'm not clever so I don't write 'clever' code, I actually find it hard to work on code bases where they tried to be clever or do too much in one function/class. Architecture is like salt, a little enhances, a lot ruins. I don't write simple clear code out of any sense of purity or attempt to be 'clean' but because I know that in six months when I open this file it'll be me fixing it and I won't understand what the hell $me-6mths was thinking.
  - FranOntanaya 10y ago
    > Not convinced it's the application of OO patterns that leads to bad code but bad programmers There's one thing I would point at. When non OO code is bad you can usually point at the problem: bugs, performance, security issues, coupling, so on and so forth. OO code can be bad yet contain no debuggable issues. Once it's laid out, noone is going to "fix it" because it's not technically broken. It'll just rot due to lack of maintenance, until there's noone left with a good mental map of it and enough of the non-OO contents are broken enough that it gets replaced all at once.
raverbashing 10y ago
"Clean code" at this point in time sounds more like a inside joke for uncle bob fans to satisfy themselves with "Clean code" sounds a lot like "True Scotsman" SOLID is better but it still is subject to some subject interpretation
coldcode 10y ago
Clean code does not matter by itself; comprehensible code does. If you understand what you have you can reason about when it might go bad and avoid it; even if it does fail you can understand why and fix it; you can see what you need to do to modify it in the future. That's what matters.
snarfy 10y ago
It only matters if you value the code. Nobody cared if Space Invaders source code was a ball of mud that was hacked together once and never looked at again. It still made millions of dollars.
scotty79 10y ago
> Open-Closed: A class should be open for extension, but close to modification I hate when people do this. Closing class for modification is very easy, but opening it for extension requires predicting the future, which is impossible. Which coupled with being closed to modification destroys re-usability.

49 points by coderjean1 10y ago

Things aren't unconditionally necessary except in modal logic. In the real world things are conditionally necessary. Clean code is necessary... for ongoing development. Clean code is necessary... to allow developers to onboard quickly. Clean code is necessary... for reducing the cognitive overhead and avoiding mistakes. Unfortunately without stating these assumptions it's impossible to prioritize and be rational about development. It provides no guidance. Should we drop everything we're doing and "clean up" the code? Is it even worth investing in? These are questions that have different answers depending on the assumptions and simply saying it's "necessary" is insufficient.

retrogradeorbit 10y ago

Clean code is not an OO concept. It's a higher level concept. SOLID may help you achieve clean code in OO, but clean code does not mean "know SOLID".

exclusiv 10y ago
I agree, but for the bulk of software engineers it's probably on point. For many of us, it's nothing new, but I do think that it's remarkably easy to just rip code toward a deadline unconsciously without keeping these concepts in mind. If you do backend, the user doesn't give a shit about your clean code, so sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability needs of a project which only comes from experience.
- maze-le 10y ago
  > If you do backend, the user doesn't give a shit about your clean code It's not about the user. Coding in a 'clean' way is something you do for your colleagues and maybe future colleagues, who will have to maintain and upgrade your software in the future. > so sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability I have seen quite some hacks that were intended as 'one-time-only' and 'we-refactor-this-later' solutions. I don't think any of these trade-offs payed out in the end. The proper work to refactor crappy code and reintegrate it into the system took a whole lot of time longer than implementing it correctly in the first place. The only situation where hacks like this are acceptable in my opinion are 'one-time-only' prototypes (where the prototype code does not find its way back into the codebase), where certain features are shown to a customer, and the rest are mockups.
  - warcode 10y ago
    Often I find that clean code is something I do for my future self too. Having some external factor break your algorithm and coming back to multiple nested loops and "i,j,k,l,x,y" variable names makes it take way too long to fix.
    - DonHopkins 10y ago
      Oh cringe. Please don't use "l" as a loop index! Don't use it for anything! Make it go away!
  - exclusiv 10y ago
    Yes it is about the end user. They don't care about your backend code. They want it to work and for it to perform. Your cleaner code means nothing to the user. Sometimes you have to put more time into frontend and you're up against a tight deadline. I'd opt for the UX in most circumstances. You're assuming that there are colleagues to work on it and that it will live indefinitely. Many projects, esp. those related to marketing, have a definite lifetime. You also mention prototypes as another use-case. Cleaner code as directed by the article is not always necessary.
- fishnchips 10y ago
  And why would the user care about your clean code on the frontend? It's usually minified anyway. Clean code is not for the user, it is for you as a developer.
  - exclusiv 10y ago
    Yes you are correct, but I'm not talking about clean code on frontend. The user doesn't care about any code. If it works, it works. I understand clean code is for the developer(s). That's precisely my point. You don't always need to go through a SOLID checklist with your project. Sometimes you have deadlines, sometimes you're the only dev and you know the project will die post-launch. So if it works; you're good. I'm not sure why this part of my original comment is confusing or controversial: "sometimes it's a trade-off in deciding your approach knowing the lifetime requirements and maintability needs of a project which only comes from experience" A purist push for design patterns and paradigms for every project is not based in the real-world.
erez 10y ago
I think the author, being a Java guy is using OO and Java as a reference point, not arguing that "this isn't applicable to non OO development". Basically he's saying that remembering the principles and practices is essential in every level of the development.

k__ 10y ago

Encapsulation and modularization is necessary, nothing more. If you get this right, you can get away with a bunch of crappy thing, because you can easily throw them out in the future and reimplement them better.

stinos 10y ago
Really nothing more? I beg to differ after having to plough through lines of code just yesterday where, just to give some examples - each single line uses a different formatting style - variable names are hard to read abbreviations - variable/class names don't make sense - 5 is a level of indentation easily reached - there's almost as much dead code as live code - comments are grammatical nonsense and don't explain why the code is written the way it is
- k__ 10y ago
  Can all be fixed rather easily, if there ha been good modularization. But yes, I prefer those things too, haha
  - cauterized 10y ago
    But to replace code, first you have to understand it.
    - k__ 10y ago
      Modules have an api and a responsibility, often this +any code helps to understand whats going on good enough
deleted 10y ago
[deleted]
Kenji 10y ago
Out of curiosity, what is the largest project you've worked on, k__ (as in, number of lines)?

Bahamut 10y ago

As with everything, it depends on your requirements, including timeline, shelf-life of application, and future maintenance/feature building. Sometimes, code is a one-off and it is better to write something that works rather than worrying about the perfect implementation. One should strive for clean code when one can, but all things have tradeoffs that have to be decided for/against.

hacker_9 10y ago

Depends on the definition of necessary. If you consider living a pleasant life necessary, then the answer is yes.

mdmoss 10y ago

I think the author's statement of the Liskov substitution principle is backwards; An object must be replaceable by a subtype, not a supertype.

coderjean1 10y ago
Yes you are totally right. I mistyped a word. Where it says supertype I actually meant subtype. I corrected the article.

dsego 10y ago

TLDR: Yes.

arpa 10y ago
And here I was expecting something that will shake the core beliefs and uproot good ole Uncle Bob; alas, not the case, yet another "Yes, clean code is good, unclean baaad"; I mean, the concept is great and all, but damn, stop preaching to the choir, it will get us nowhere...

mehwoot 10y ago

Liskov Substitution: An object can be replaced by supertype without breaking the program Shouldn't that be subtype? Or am I misremembering this?

fishnchips 10y ago
Yup, you remember it correctly.
ethagnawl 10y ago
You're correct. From Wikipedia[0]: > Liskov's notion of a behavioral subtype defines a notion of substitutability for mutable objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g. correctness). 0: https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle
- Ntrails 10y ago
  Surely it follows logically anyway? Assuming sub/super are referring to inheritance (sorry, I'm a bad), a sub contains all of a super and more. Passing through an object with more shouldn't break anything. But a super might lack things the sub has, thereby breaking assumptions about what will be present. I feel like the principle would be broken by the objects/inheritance being badly used rather than the calling code though?
  - talideon 10y ago
    LSP doesn't specifically deal with inheritance; it's equally applicable to interface implementation.
- coderjean1 10y ago
  Yes you are totally right. I mistyped a word. Where it says supertype I actually meant subtype. I corrected the article.
10y ago

berntb 10y ago

Today a discussion like this make me so jealous I get vertigo... :-) Yesterday evening I spent two hours just to trace and understand the dispatch for a really simple and small part of a big, old web application. (To save time, the answer to the question you want to ask is: "Yes, glad you asked. It really is from 1999. And no, they don't know the word refactoring.")

DonHopkins 10y ago
At least it's a good excuse to put on a Prince album while you work.
- berntb 10y ago
  My music of the time was more singer songwriters, balkan gypsy, modern jazz and death/black. :-)

caleblloyd 10y ago

Is Clean Code Possible? Not if you're writing ES5 JavaScript for the browser.

jomamaxx 10y ago
This comment should not be downvoted. It's a hard realpolitik of web programming.
- deleted 10y ago
  [deleted]

stupidcar 10y ago

Personally, I've found that heavy application of OO patterns leads to code that is very unclean, in terms of being "simple and direct". First developers apply the single-responsibility principle, and break down previously large but comprehendible classes in thousands of tiny components. While each component is trivial on its own, the truth of how they combine to produce a particular application feature is now hidden within an implicit object graph that cannot be understood by new developers, except through a torturous process of cross-checking and debugging until they have built a fragile mental model of what's going on. Next developers get embarrassed by all the new-ing up of components they're doing, so they introduce dependency injection. But rather than just injecting those things that have a genuine need for varying implementations, suddenly everything gets to be a service. Abstractions proliferate, factory factories appear, everything is behind an interface (with a single "default" implementation), and navigating the codebase becomes a nightmare.

noir_lord 10y ago
Not convinced it's the application of OO patterns that leads to bad code but bad programmers (at least in the major part). I've seen clean code bases in OO/functional and pure procedural and bad code bases in those as well. I think it's tempting to blame bad code on things like bad languages and bad architectural patterns because they are externalities and can be blamed without mentioning the gorilla in the room, bad programmers write bad code. I'm not clever so I don't write 'clever' code, I actually find it hard to work on code bases where they tried to be clever or do too much in one function/class. Architecture is like salt, a little enhances, a lot ruins. I don't write simple clear code out of any sense of purity or attempt to be 'clean' but because I know that in six months when I open this file it'll be me fixing it and I won't understand what the hell $me-6mths was thinking.
- FranOntanaya 10y ago
  > Not convinced it's the application of OO patterns that leads to bad code but bad programmers There's one thing I would point at. When non OO code is bad you can usually point at the problem: bugs, performance, security issues, coupling, so on and so forth. OO code can be bad yet contain no debuggable issues. Once it's laid out, noone is going to "fix it" because it's not technically broken. It'll just rot due to lack of maintenance, until there's noone left with a good mental map of it and enough of the non-OO contents are broken enough that it gets replaced all at once.

raverbashing 10y ago

"Clean code" at this point in time sounds more like a inside joke for uncle bob fans to satisfy themselves with "Clean code" sounds a lot like "True Scotsman" SOLID is better but it still is subject to some subject interpretation

coldcode 10y ago

Clean code does not matter by itself; comprehensible code does. If you understand what you have you can reason about when it might go bad and avoid it; even if it does fail you can understand why and fix it; you can see what you need to do to modify it in the future. That's what matters.

snarfy 10y ago

It only matters if you value the code. Nobody cared if Space Invaders source code was a ball of mud that was hacked together once and never looked at again. It still made millions of dollars.

scotty79 10y ago

> Open-Closed: A class should be open for extension, but close to modification I hate when people do this. Closing class for modification is very easy, but opening it for extension requires predicting the future, which is impossible. Which coupled with being closed to modification destroys re-usability.