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

281–290 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#281

Post by ninetyninenine »

jjj123 wrote: post #269
ninetyninenine wrote: post #251

Earlier quoted context omitted.

[flagged]

Okay so your definition of “smart” sounds different than the definition everyone else in this thread is using. Sounds more like you’re talking about “genius” to me, specifically in a savant type way where they are incapable of relating to average people.

No. I’m talking about genius. Not savant. Savants likely can’t relate to your emotions. Geniuses can. The difference is just if it takes them 1 second to parse what takes you 5 minutes to do the same they often don’t realize this unless you tell them.

That being said what I talk about lives on a gradient. The smarter you are the greater degree of tendency you have to write shitty code.

The cleaner your code the higher possible chance you are stupider. It’s not a definitive sign but there is a correlation.

Re: Clean Code vs. A Philosophy Of Software Design

#282

Post by WillAdams »

begueradj wrote: post #91
imjonse wrote: 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.

Do not make the mistake of the craftsman who claims to have 20 years of experience, but in truth only has 1 year of experience repeated 20 times.

Re: Clean Code vs. A Philosophy Of Software Design

#283

Post by narnarpapadaddy »

abhis3798 wrote: post #121
narnarpapadaddy wrote: post #47

Earlier quoted context omitted.

Implicitly, IIRC, the optimal ratio is 5-20:1. Your interface must cover 5-20 cases for it have value. Any fewer, the additional abstraction is unneeded complexity. Any more, and your abstraction is likely too broad to be useful/understandable. The example he gives specifically was considering the number of subclasses in a hierarchy. It’s like a secret unlock code for domain modeling. Or deciding how long functions s…

This is a good rule of thumb, but what would be a good response to have interfaces because, "what if a new scenario comes up in the future"?

When doing the initial design start in the middle of the complexity to abstraction budget. If you have 100 “units of complexity” (lines of code, conditions, states, classes, use cases, whatever) try to find 10 subdivisions of 10 units each. Rarely, you’ll have a one-off. Sometimes, you’ll end up with more than 20 in a group. Mostly, you should have 5-20 groups of 5-20 units.

If you start there, you have room for your abstraction to bend before it becomes too brittle and you need to refactor.

Almost never is an interface worth it for 1 implementation, sometimes for 3, often for 5-20, sometimes for >20.

The trick is recognizing both a “unit of complexity” and how many “units” a given abstraction covers. And, of course, different units might be in tension and you have to make a judgement call. It’s not a silver bullet. Just a useful (for me at least) framing for thinking about how to manage complexity.

Re: Clean Code vs. A Philosophy Of Software Design

#284

Post by WillAdams »

Hasu wrote: post #263

> I bemoan the fact that we must sometimes use a human language instead of a programming language. Human languages are imprecise and full of ambiguities. Using a human language to describe something as precise as a program is very hard, and fraught with many opportunities for error and inadvertent misinformation. This quote from Uncle Bob is shameful, considering that he has made 100% of his career on writing English…

An interesting contrast to it is Ousterhout's observation:

>If you can visualize a system, you can probably implement it in a

>computer program.... This means that the greatest limitation in writing

>software is our ability to understand the systems we are creating.

Though interestingly it is in marked contrast to a different statement in the "Software Design Book" Google mailing list:

>John Ousterhout, Aug 21, 2018, 12:30:15 PM

>I've never felt that graphs are a particularly useful way of describing software structure.

>The interactions between classes end up so complicated that the graph becomes an unreadable mess.

>Also, I'm not sure that the complexity of a graph representation of software correlates with its

>practical complexity (the graph representation might look very complicated, but the software might

>still be pretty easy to maintain).

and I'd be interested if someone knows of a text/video/interview which resolves that twain, or what sort of visualization is advocated for/recommended.

Re: Clean Code vs. A Philosophy Of Software Design

#286

Post by bluGill »

dgb23 wrote: post #280
bluGill wrote: post #227

Earlier quoted context omitted.

Clean Code is trying to operate at a layer far more important than efficiency: code maintenance. In the vast majority of cases computers are fast enough that you don't need to worry about efficiency. (part of this is any modern language provides all the common algorithms that are already highly optimized and easier to use than the writing them by hand and so the common places where you would want to worry are already…

From personal experience, the most time consuming maintenance issues arise because of the following things: - third party dependencies, compatibility issues, breaking changes - code that is bloated with abstractions and indirection - performance issues, especially when worked around via caching etc. - bad error handling - inconsistent data Simpler code that can be followed and stepped through in a straight forward ma…

It sounds like you have been lucky enough to avoid some of the worst code practices of history. Good for you.

I hope you can come up with a good answer to fix the problems you cite. I haven't seen anything I have confidence in.

Re: Clean Code vs. A Philosophy Of Software Design

#287

Post by WillAdams »

froh wrote: post #245
chillpenguin wrote: post #26

Earlier quoted context omitted.

"john ousterhout's book is the only book on how to write software that has any actual evidence behind it." This is false and hopefully no one takes you seriously when they read that. There are books about empirical methods for software engineering, for example, which actually seek to find real evidence for software engineering techniques. See Greg Wilson's work, for example. There are lots of other architecture/desig…

Greg Wilson indeed is tremendously helpful in facilitating "the industry" to think about our craft: https://github.com/gvwilson edit: wow, in his project "It will never work in theory" he's fairly sober about the ability of "the industry" to reflect on "the craft" https://neverworkintheory.org/ > about the project: > People have been building complex software for over sixty years, but until recently, only a handful o…

The annals of the IEEE and ACM would argue against:

>only a handful of researchers had studied how it was actually done

I am pretty sure that there are more than 5 references to papers in APoSD.

Re: Clean Code vs. A Philosophy Of Software Design

#288

Post by narnarpapadaddy »

kragen wrote: post #268
narnarpapadaddy wrote: post #226

Earlier quoted context omitted.

And with respect to function behavior, I’d view it through the lens of cyclomatic complexity. Do I need 5-20 non-trivial test cases to cover the range of inputs this function accepts? If yes, function is probably about the right level of behavioral complexity to add value and not overhead. If I need only 1 test or if I need 200 tests it’s probably doing too much or too little.

That's not what cyclomatic complexity is, and if you think 5–20 test cases is enough for sin(), open(), or Lisp EVAL, you need your head examined.

You’re right, I suggested two different dimensions of complexity there as a lens into how much complexity a function contains. But I think the principle holds for either dimension.

I don’t think you need only 20 test cases for open(). Sometimes, more than 20 is valid because you’re saving across some other dimension of complexity. That happens and I don’t dispute it.

But the fact that you need >20 raises the question: is open() a good API?

I’m not making any particular judgment about open(), but what constitutes a good file API is hotly contested. So, for me, that example is validation of the principle: here’s an API that’s behaviorally complex and disputed. That’s exactly what I’m suggesting would happen.

Does that help clarify?

Re: Clean Code vs. A Philosophy Of Software Design

#289

Post by MobiusHorizons »

runevault wrote: post #34
MobiusHorizons wrote: post #18

Earlier quoted context omitted.

> instead it presents what look like rules that you shouldn't be breaking if you want to be a good programmer. I see this a lot, especially among more junior programmers. I think it likely stems from insecurity with taking responsibility for making decisions that could be wrong. It makes sense, but I can’t help but feel it is failing to take responsibility for the decisions that are the job of engineering. Engineerin…

I always think of this as the programmer version of "No one got fired for choosing IBM." that was a common phrase about executives back in the day. Do the thing that you can just point to "experts" and blame them.

That is a helpful comparison. I guess it is risk aversion at the core. At some point risk aversion becomes abdication of decision making to others, which seems broken in roles that are specifically hired for making decisions, but that’s even more true of executives.

Re: Clean Code vs. A Philosophy Of Software Design

#290

Post by LudwigNagasena »

ninetyninenine wrote: post #225
getnormality wrote: post #12

Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?

Yes. This works but only if the functions are pure and using pure function composition. Uncle bob doesn’t mention this. createspecialString(y) = Capitalizefirstletter . MakealllowerCase . AddNumberSuffix . removeLetterA . removeLetterB . ConcatwithWord(x) CapitalizeFirstLetter(a) = a[0].upper() + a[1:] MakeAllLowercase(a) = map(a, (t) => t.lower()) Addnumbersuffix(a) a + 3.toString() RemoveLetterA(t) = filter(t, (s)…

`createspecialString` is seven lines long though.
Post reply on HN