5 ms·

Disagree. You deliberately call it beautiful code, whereas in reality it is clean code. Clean code is not more expensive to deliver than ugly code. It just r

Disagree. You deliberately call it beautiful code, whereas in reality it is clean code. Clean code is not more expensive to deliver than ugly code. It just requires a better calibre of developer i.e. a developer who can express features in a style which others can understand. Once you have clean code you can take on features more easily and quickly. You can also change personnel more easily. Most importantly of all you can get better confidence that changes won't introduce side affects. The problem is there are not many people who can do this. No-one in their right mind (Fowler, Uncle Bob, included) say code should be beautiful as some kind of vain exercise in style over substance.

ricw 13y ago
Absolutely correct. And what clean code leads to is more maintainable and more easily update-able code. Beauty or ugliness is absolutely not a feature. Its a sideline to what clean code is. Maintainability is totally the high order bit here. And its totally worth getting it right (or at least approximately). Its the anti-thesis to ugly code.
- planetjones 13y ago
  That's exactly what I was trying to say: "beautiful code is a byproduct of clean code". Clean code is the important part. Thank you!
tsahyt 13y ago
I agree with you disagreeing. The article really blurs the line between mere code formatting, which can be completely automated to adhere to some guidelines, coding paradigms and software design/architecture. I'd argue that, for a product that needs to extendible and maintainable, well thought-out software design is at least as important as working code. It takes a bit more planning up front, specifying the system to be developed in terms of well-understandable and well-documented patterns but this time (and hence money) is not lost. It pays back double during both the initial implementation and maintenance. A well thought out software design takes a lot of tasks off the people who go to implement it. It clearly specifies which parts are to interact and how they can be expected to behave. Therefore it fosters modularity and independent development of modules, which speeds things up and makes maintenance and extending the product easier. And that is what we really want after all. We want to get code and therefore products out quickly, we want to avoid bugs, we want to make sense of the whole thing after a couple of months have passed in order to implement NewFeatureX™. There are numerous approaches to this. Object-orientation is just one way to do it and sometimes it's not the best way. After all, all these paradigms and schools of thought are but tools to get the job done and as always, it's a good idea to chose the right tool for the job. The other thing is actual code "beauty" (however one may define it), which ultimately means readabilty. This is important too but it highly depends on what people are used to. That's why there're often coding standards for a given project or a company. Everybody gets used to them and no one needs to rethink when reviewing the code of other developers. There's no better or worse there. The only thing of importance is that it shouldn't be possible to pinpoint who exactly wrote a certain piece of code by just looking at it. If it looks like you wrote it, you'll understand it that much easier because it takes all the burden of messing with strange-looking syntax away. The "just-get-it-done" approach to software engineering just doesn't work for projects of a certain size. That's probably why we call it "engineering" in the first place.

ricw 13y ago

Absolutely correct. And what clean code leads to is more maintainable and more easily update-able code. Beauty or ugliness is absolutely not a feature. Its a sideline to what clean code is. Maintainability is totally the high order bit here. And its totally worth getting it right (or at least approximately). Its the anti-thesis to ugly code.

planetjones 13y ago
That's exactly what I was trying to say: "beautiful code is a byproduct of clean code". Clean code is the important part. Thank you!

tsahyt 13y ago

I agree with you disagreeing. The article really blurs the line between mere code formatting, which can be completely automated to adhere to some guidelines, coding paradigms and software design/architecture. I'd argue that, for a product that needs to extendible and maintainable, well thought-out software design is at least as important as working code. It takes a bit more planning up front, specifying the system to be developed in terms of well-understandable and well-documented patterns but this time (and hence money) is not lost. It pays back double during both the initial implementation and maintenance. A well thought out software design takes a lot of tasks off the people who go to implement it. It clearly specifies which parts are to interact and how they can be expected to behave. Therefore it fosters modularity and independent development of modules, which speeds things up and makes maintenance and extending the product easier. And that is what we really want after all. We want to get code and therefore products out quickly, we want to avoid bugs, we want to make sense of the whole thing after a couple of months have passed in order to implement NewFeatureX™. There are numerous approaches to this. Object-orientation is just one way to do it and sometimes it's not the best way. After all, all these paradigms and schools of thought are but tools to get the job done and as always, it's a good idea to chose the right tool for the job. The other thing is actual code "beauty" (however one may define it), which ultimately means readabilty. This is important too but it highly depends on what people are used to. That's why there're often coding standards for a given project or a company. Everybody gets used to them and no one needs to rethink when reviewing the code of other developers. There's no better or worse there. The only thing of importance is that it shouldn't be possible to pinpoint who exactly wrote a certain piece of code by just looking at it. If it looks like you wrote it, you'll understand it that much easier because it takes all the burden of messing with strange-looking syntax away. The "just-get-it-done" approach to software engineering just doesn't work for projects of a certain size. That's probably why we call it "engineering" in the first place.