It's probably time to stop recommending Clean Code
-
It may not be possible for us to ever reach empirical definitions of "good code" or "clean code", which means that any one person's opinion about another person's opinions about "clean code" are necessarily highly subjective.
Because 'dirty code' is so much more fun
-
It may not be possible for us to ever reach empirical definitions of "good code" or "clean code", which means that any one person's opinion about another person's opinions about "clean code" are necessarily highly subjective.
Because 'dirty code' is so much more fun
There once was a whore from Nantucket, Who thought clean code was like a bucket With bits going in, and bits going out, Oh nevermind, :elephant: it!
-
It may not be possible for us to ever reach empirical definitions of "good code" or "clean code", which means that any one person's opinion about another person's opinions about "clean code" are necessarily highly subjective.
Because 'dirty code' is so much more fun
Clean code goes to production, Dirty code goes everywhere...
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
It may not be possible for us to ever reach empirical definitions of "good code" or "clean code", which means that any one person's opinion about another person's opinions about "clean code" are necessarily highly subjective.
Because 'dirty code' is so much more fun
I thought that book was horrible; one of the worse books on coding I've read.
-
It may not be possible for us to ever reach empirical definitions of "good code" or "clean code", which means that any one person's opinion about another person's opinions about "clean code" are necessarily highly subjective.
Because 'dirty code' is so much more fun
Let us see. First came OOP. After 20 years, suddenly you start getting articles on why it is not the panacea it was touted to be. Then came Agile. Some 20 years later, you start getting talks on why Agile doesn't work in large corporations. Along came Clean Code and Clean Architecture. Now somebody is saying those emperors don't have any clothes on. But the snake oil salesmen are not out of tricks yet. Now you get functional programming. That ought to be good for another 20 years. And you are all wondering -- nay, enraged -- how programs written in the 60-year-old COBOL still work flawlessly.* Perhaps the programmers in the old days put a little bit of their heart and soul into their work. And did not go around disparaging others who worked with different languages on differently architected machines. But today we have programmers who believe that they are possessors of the Ultimate Truth -- as in Unix, C, etc -- and they are wondering why they are unable to develop good application systems and are grasping for the newest tools, methodologies, frameworks, etc. Maybe a little humility would be in order. *I can sit halfway around the world in India and withdraw cash from my account in a small regional US bank from an ATM belonging to a local Indian bank, all because those programs were written in COBOL, tested and put into production on mainframes in the early 1970s by programmers who made do with COBOL, IMS and CICS and not bitterly complain about how they didn't have access to awk, grep or pipes; or that they had to use the Waterfall methodology; or any number of other "blame the tool" excuses.
-
Let us see. First came OOP. After 20 years, suddenly you start getting articles on why it is not the panacea it was touted to be. Then came Agile. Some 20 years later, you start getting talks on why Agile doesn't work in large corporations. Along came Clean Code and Clean Architecture. Now somebody is saying those emperors don't have any clothes on. But the snake oil salesmen are not out of tricks yet. Now you get functional programming. That ought to be good for another 20 years. And you are all wondering -- nay, enraged -- how programs written in the 60-year-old COBOL still work flawlessly.* Perhaps the programmers in the old days put a little bit of their heart and soul into their work. And did not go around disparaging others who worked with different languages on differently architected machines. But today we have programmers who believe that they are possessors of the Ultimate Truth -- as in Unix, C, etc -- and they are wondering why they are unable to develop good application systems and are grasping for the newest tools, methodologies, frameworks, etc. Maybe a little humility would be in order. *I can sit halfway around the world in India and withdraw cash from my account in a small regional US bank from an ATM belonging to a local Indian bank, all because those programs were written in COBOL, tested and put into production on mainframes in the early 1970s by programmers who made do with COBOL, IMS and CICS and not bitterly complain about how they didn't have access to awk, grep or pipes; or that they had to use the Waterfall methodology; or any number of other "blame the tool" excuses.
:thumbsup: A good candidate for post of the month.
Robust Services Core | Software Techniques for Lemmings | Articles
-
:thumbsup: A good candidate for post of the month.
Robust Services Core | Software Techniques for Lemmings | Articles
Thanks.
-
It may not be possible for us to ever reach empirical definitions of "good code" or "clean code", which means that any one person's opinion about another person's opinions about "clean code" are necessarily highly subjective.
Because 'dirty code' is so much more fun
I agree with the article. There are good advices in SOLID, GoF design patterns, automated tests and so on but they should be taken as such, guidelines to keep in mind when implementing solutions. Trying to be compliant at all the costs with strict rules is wrong. You should use common sense and eventually discuss with other peers what's the best solution. Each project has its own needs and software is a mix of art, creativity and science. A developer should not obsess if to use this or that design pattern, number of lines per method or number of unit tests. Do what you think makes really sense and improve code quality, compatibly with the deadlines. I guess developers obessing with rules are not doing this job for passion but just for the salary. On the othe hand "gurus" claiming they own the unique source of truth are often smart guys trying to avoid the hard work of writing code and make easy money becoming popular. What kind of super applications they wrote in the past? Probably not many, they are great at theory but nothing special at practice.
