Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

461–470 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#461

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…

For many C#, Java and C++ engineers Uncle Bob is their savior and GoF are the apostles. Everything should follow SOLID and clean principles and be implemented using design patterns.

One of the best things I could do for myself is to go back in time and tell my younger self not to care so much about the "right" design pattern, or the perfectly DRY way to represent a piece of code. I was definitely my worst enemy for a long time, because I thought SOLID and the GoF design patterns were more important than writing code that is easy to understand without hopping across multiple files in case one day in the future your system needed to do something totally different with a new database or filesystem, etc. I started to look for places to add design patterns, rather than letting them develop naturally. Most of the software I built had no need for such heavy abstraction and complexity, and I've only ever had to switch database systems twice ever in 20 years, and the abstraction did not help reduce time or complexity all that much in the end. It definitely wasn't worth the up front planning compared to just rewriting the sections that directly handled the database.

Maybe it's a right of passage to burn yourself badly enough over-architected solutions, where you finally start to understand you don't need all the complexity. Write the code for humans, as simple as you can. Keep large performance issues in mind, but only code around them when they become a problem or are extremely obvious. If anything, it's helped me to steer junior developers away from complex code, while encouraging them to try it out in their own time. Go ahead and figure things out on your own, but let's not do it on a shared codebase, please?

Re: Clean Code vs. A Philosophy Of Software Design

#462
post #74

I am biased ( a former coworker was an Uncle Bob fan, and was bent on doing everything by the book, with layers of abstraction, patterns, hexagonal architecture, lots of unit tests, no cutting corners, even as we did not know what exactly we want to build and needed an MVP ASAP) but I'll just say this: Ousterhout wrote TCL - widely considered one of the best C codebases - besides being a professor at Standford and ha…

Let's not forget that Uncle Bob, by the time of writing "Clean Code" had 4 decades coding experience.

Kenneth Copeland has been a pastor for 50 years and his theology and pastoral practice is still terrible. Years of experience is not a useful metric when you could instead look at results.

Re: Clean Code vs. A Philosophy Of Software Design

#463
post #294

Earlier quoted context omitted.

Yes, Uncle Bob is certainly capable of being pedantic. A friend of mine, a Smalltalk Consultant, partnered with him for a while. "With Uncle Bob, it's his way or the highway." His clean code work is certainly pretty dogmatic. As I recall, he says that Java is not object oriented. But if my memory serves me correctly, his book about C++ (Designing Object-Oriented C++ Applications Using the Booch Method) has some excel…

Bob's had a long life with too much success. He really believes in himself. But, I have to say that the other guy was aggressive and bad even though I am more inclined to agree with him. He willfully misrepresented Bob's ideas. I thought he presented more misguided certainty than Bob. No Bueno.

The "other guy" is John Ousterhout, author of the Tcl scripting language.

Although I can see why you might consider him more "aggressive", I personally think it matters much more that he was, in general, far more descriptive of his reasoning.

Merely having an opinion is the easy part; being able to clearly articulate the reason(s) why one has a particular opinion is far more important, especially in this kind of conversation, and I in that regard I repeatedly found UB lacking.

Re: Clean Code vs. A Philosophy Of Software Design

#464

Earlier quoted context omitted.

>> ... TDD is unlikely to help you solve problems that are beyond incremental changes. Thank you for expressing this niggling problem with TDD. Personally I just cannot use it for "new stuff", I need to explore and create direct with "real" code for anything non-obvious.

I'm more of a DTT man myself: Develop, Then Test.

+1

I think "code is carefully designed AND has a bunch of decent tests" places a codebase ahead of many tbh, even now, regardless of how it's produced

Re: Clean Code vs. A Philosophy Of Software Design

#466

Earlier quoted context omitted.

`createspecialString` is seven lines long though.

Then split it. All pure functions are easily decomposed into the most primitive units so even the most dogmatic ass hole can't talk shit. createSpecialString = createFormattedString . createNewString createFormattedString = Capitalizefirstletter . MakealllowerCase . AddNumberSuffix . createNewString(y) = removeLetterA . removeLetterB . ConcatwithWord(x) Or put it all on one line. createspecialString(y) = Capitalizefi…

Well, the most interesting thing about purely functional composition would be the ability to un(de)compose them, inlining the bodies until the resulting function is large enough to be worth the effort of reading it.

Re: Clean Code vs. A Philosophy Of Software Design

#468

Earlier quoted context omitted.

philosophy is the basis of reason, math, and science. it's sad that "engineers" don’t understand it or it's import.

Engineers believe in definitions. By definition, philosophy is not a scientific discipline, because as soon as a discipline becomes scientific it... stops being philosophy. As Alexander Pyatigorsky famously wrote, "the value of philosophy is in that nobody needs it".

what i meant was- it is a poor engineer indeed who doesn't understand the concepts of philosophy such as ethics, logic, and how that led to the scientific method.

science without philosophy is just scientism. it leads to engineers creating previously unimaginable horrors!

Re: Clean Code vs. A Philosophy Of Software Design

#469

Earlier quoted context omitted.

> Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? Honestly, no better indication of a very mediocre developer

My experience is that being fastidious about code formatting is independent of one's ability as a developer. i.e. not a good indicator either way.

I've inherited many sloppily formatted code bases that all contained mistakes which blended into the mess. Consistently styled code has the nice property that certain types of mistakes stand out immediately.

For example, there's a large chunk of code following an if statement, but it's indented the same as the body of the if. The dev overlooks the closing brace and puts the logic in the wrong place. Additionally, there is a nested if statement whose body is indented less than the surrounding code. It's hard to read, and error prone.

I can't imagine a "good" developer putting up with that, although I admit you don't have to be "fastidious" to prevent this type of thing.

Re: Clean Code vs. A Philosophy Of Software Design

#470
post #124
post #74

I am biased ( a former coworker was an Uncle Bob fan, and was bent on doing everything by the book, with layers of abstraction, patterns, hexagonal architecture, lots of unit tests, no cutting corners, even as we did not know what exactly we want to build and needed an MVP ASAP) but I'll just say this: Ousterhout wrote TCL - widely considered one of the best C codebases - besides being a professor at Standford and ha…

Biased against the approach of your former coworker and thus the "Clean Code" way? I assume it did not work out well, because you needed to move fast to build an MVP before trying to do it right?

Following Clean Code is not the right way to develop software in any stage of the project. It is a few opinions of someone who has not actually written any code of substance. In addition to Clean Code being a bad approach, it can also be a very slow process.
Post reply on HN