4 ms·

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.

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.