Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

Post reply on HN
Print view View original

421–430 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#421

Post by allemagne »

Jach wrote: post #35
tikhonj wrote: post #31

Earlier quoted context omitted.

What's there to dislike so much in APOSD? The book struck me as giving mostly reasonable advice, none is which was overly prescriptive. None of the things I disagreed with struck me as egregious .

Here's mostly from what I wrote down after reading it. Indeed, the "reasonableness" is part of the problem. What's agreeable is mostly only so because it's such a straightforward platitude. "Things that are not important should be hidden, and the more of them the better. But when something is important, it must be exposed." Ok? Anyone want to argue to the contrary? This is not teaching or learning anything new or of…

He could have chosen a different word besides "complexity" but I don't really think it would have affected much. The subjective easy/hard is specifically what Ousterhout is trying to talk about.

Ultimately the problem he is (and all of us are) facing is that "good software design" can't really be measured with the right linting ruleset or static analysis. So if you're trying to break the concepts down each level, while still maintaining a scope that should include all software, that probably means it's impossible not to come off as squishy and non-specific at several points. I still think he strikes a really good balance in general here.

I agree that there could be more discussion around context and audience. Ousterhout says "if you write a piece of code and it seems simple to you, but other people think it is complex, then it is complex", but then what can possibly be done if everyone on my team was replaced with new hires who had next to no experience writing code? Did the same codebase go from simple to complex?

Re: Clean Code vs. A Philosophy Of Software Design

#422

Post by cowboylowrez »

loganmhb wrote: post #267

Plenty of people are ragging (justifiably) on Clean Code, but I really admire by contrast Ousterhout's commitment to balanced principles and in particular learning from non-trivial examples. Philosophy of Software Design is a great and thought-provoking read.

Philosophy of Software Design seemed more pragmatic to me.

Re: Clean Code vs. A Philosophy Of Software Design

#423

Post by jolt42 »

analog31 wrote: post #298
hliyan wrote: post #196

Earlier quoted context omitted.

To restate something I've said here last month: I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygien…

Granted, while I program a lot, I'm not employed as a programmer per se. My impression is that programming is easy and fun, but software develoment is hard and laborious. Things like hygiene are among the differences between the two.

100%. Dealing with legacy issues is much more laborious and also complicates hygiene.

Re: Clean Code vs. A Philosophy Of Software Design

#424

Post by ad_hockey »

Something I find odd about Uncle Bob's style is the preference for reading and modifying shared state over pure functions that take args. It makes me do a double take when I read a method registerTheCandidateAsPrime() (taken from UB's rewrite) that doesn't take a candidate arg.

How would you unit test those methods? You'd have to directly set the field values, then call the method, then assert on the fields. If the answer is "you don't unit test private methods" then that's completely fine, because I agree with that (perhaps this is implicit from the private keyword, I don't know Java). But I'm struggling to imagine how you would get to those private methods with such a strict adherence to TDD as Bob recommends. Methods like increaseEachPrimeMultipleToOrBeyondCandidate() are quite complex, and would be tricky to build up using TDD if you couldn't exercise them directly.

If nothing else, surely Bob's approach is not thread safe. Call PrimeGenerator3.generateFirstNPrimes() concurrently and they'll trample all over each other. John Ousterhout's stateless version doesn't have that problem.

Re: Clean Code vs. A Philosophy Of Software Design

#426

Post by tqwhite »

wglb wrote: post #294
ilitirit wrote: post #145

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…

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.

Re: Clean Code vs. A Philosophy Of Software Design

#427

Post by seanwilson »

WillAdams wrote: post #419
seanwilson wrote: post #399

Earlier quoted context omitted.

> It's better credentials and experiential basis than most other programming books. When considering coding advice, I just don't find credentials or the results of a coding experiment matter much, especially if it involves students. I run through the scenarios in my head and pick the option that makes sense given the context and competing priorities. > I think it is remarkable that the author switched from "modules s…

Thanks. At a quick glance, that book seems to align well with APoSD --- what aspects do you believe run counter to it?

The books aren't that similar I found. The Google one is more about practical tips on the dev process of scaling and maintaining software in teams, rather than focused on code.

Re: Clean Code vs. A Philosophy Of Software Design

#428

Post by arp242 »

wesselbindt wrote: post #274
felizuno wrote: post #248

Earlier quoted context omitted.

Clean Code zealots are consistently some of the least likable, least productive, least pragmatic people I have ever worked with. I've had multiple clients where the whole team is threatening to quit unless the CC zealot is fired. And when they are fired guess what - bugs go down, shipped features go up, and meetings become productive. "Idiots who froth at the mouth" is an understatement IMO

This too seems like a fairly hardline stance to take. I think it's not surprising that you'd have a hard time collaborating with people you'd refer to as unlikeable, unproductive, unpragmatic, overzealous, frothy idiots. It reminds me of the standard joke about veganism: "how do you know someone is vegan? Don't worry they'll tell you" It's a very ironic joke, because the people I hear talking about veganism the most…

Well I am vegan, and let me tell you, some vegans are completely insufferable. While it's true that the people ranting about vegans outnumber the insufferable vegans, there is a core of truth to it.

I didn't read all 416 comments in this thread, but I've definitely worked with some people who religiously follow Clean Code to the point of toxicity. Perhaps the most bizarre example I encountered was the person who insisted that they're a backend dev, that they should never have to open the UI to test anything as tests should always be sufficient, and would continue pushing bugs in to production because the early "startup days" had produced some pretty crappy code with limited (or no!) tests. It was completely unworkable. The team literally had a party after he left. That was after two people had quit in large part due to this person.

I have also worked with some people who generally liked Clean Code but didn't follow it religiously in spite of what works for this specific project. That's fine: that's just a normal type disagreement like Python vs. Ruby or where to put the braces or whatever: you talk to each other, and reach some solution that reasonably works for everyone.

And the "reactionaries" are mostly just normal folks who want to get stuff done.

Re: Clean Code vs. A Philosophy Of Software Design

#429

Post by CyberDildonics »

layer8 wrote: post #348
CyberDildonics wrote: post #247

Earlier quoted context omitted.

John Carmack would disagree with Uncle Bob and John Carmack actually programs. My own experience is that with an IDE that can collapse a new scope in the middle of a function, you can make large functions that accomplish a lot and are very clear by writing a comment and starting a new scope. If something is going to be called multiple times a new function makes sense, but this idea that anything that can eventually r…

The problem with collapsing is that you need to know a priori which sub-scopes are independent and hence collapsible and which aren’t. Meaning, you have to analyze the unfamiliar code first in order to know which sub-scopes you might want to collapse. And, given an already-collapsed sub-scope, due to it being collapsed you can’t see if it reads or mutates some local variable. The benefit of extracted functions is tha…

you need to know a priori which sub-scopes are independent and hence collapsible and which aren’t.

What does independent mean? I would just collapse them all because they were meant to be collapsed in the first place.

you have to analyze the unfamiliar code first in order to know which sub-scopes you might want to collapse

Unfamiliar? I wasn't refactoring and collapsed them all.

The benefit of extracted functions is that you know that they are independent of the implementation details of the caller (i.e. can’t possibly depend on or modify local variables of the caller other the ones passed as arguments).

That's true to an extent, but this is more of a way to make monolithic functions simple, which then makes the program simpler over all because you can avoid lots of tiny little functions. What you can end up with is programs that do non trivial things but don't have tons of functions confusing the issue.

Pragmatically this isn't really a problem. The whole "it isn't exactly a 1:1 replacement" isn't the point. You can still put in comments and const references if you really want to.

IDE affordances are fine, but I’m opposed to requiring reliance on them for reading and understanding code, as opposed to writing.

Why would it be required? The alternative is that you still have these commented sections with their own scope but they aren't collapsed. You can always work on it without the IDE and when you go back to the IDE it still works.

The reality of it is that you can see a broad overview of a function then see details one section at a time and you don't even have to go skipping around to other parts of the file or other files to do it.

Re: Clean Code vs. A Philosophy Of Software Design

#430

Post by beryilma »

"Uncle Bob" is not a software engineer (as he calls himself) and anything he says on the subject is theoretical at best, and snake oil at worst. Can anyone point to any substantial piece of code that he wrote before he can be taken seriously. The code pieces at his GitHub repos, other than style, etc., are just simplistic stuff.

It is probably OK to be thinking on issues related to a field (i.e., software engineering) without being a practitioner in the field, but producing fads-du-jour and selling them as solid (pun intended) theories and expecting to be taken seriously is just ludicrous to me.

Post reply on HN