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

531–540 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#531

Post by d0mine »

narnarpapadaddy wrote: post #283
abhis3798 wrote: post #121

Earlier quoted context omitted.

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…

Even one use case may be enough e.g., if one class accepts another then a protocol (using Python parlance) SupportsSomething could be used to decouple two classes, to carve out the exact boundary. The protocol may be used for creating a test double (a fake) too.

Re: Clean Code vs. A Philosophy Of Software Design

#532

Post by dang »

ninetyninenine wrote: post #524
bena wrote: post #520

Earlier quoted context omitted.

So we're talking about two people? Not a huge sample size. Not to mention, 150+ puts one in the 99.9th percentile. One in a thousand. So out of every thousand people you meet, one of them probably had an equivalent IQ. That being said, I guarantee that there are way more people on these boards with equivalent levels of intelligence and that those people also know several people with equivalent levels of intelligence.…

[flagged]

Could you please stop breaking the site guidelines? We've already had to ask you once. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it. Note this one:

"Please don't sneer, including at the rest of the community."

It's reliably a marker of bad comments and worse threads, and you've unfortunately been doing it repeatedly.

If you know more than others and are smarter and more above-average than others, that's great—in that case please share some of what you know so the rest of us can learn. If you don't have time or don't want to do that, that's fine too—but in that case please don't post. Posting putdowns instead doesn't help anybody, and it degrades the container.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

Re: Clean Code vs. A Philosophy Of Software Design

#533

Post by dang »

bena wrote: post #444
ninetyninenine wrote: post #414

Earlier quoted context omitted.

>This is essentially using your own belief as proof that your belief is correct. You say I haven't been around the smartest people because I say the smartest people don't do what you claim. You are saying "I'm right therefore you are wrong". Maybe you haven't been around the smartest people. I have quantitative evidence of this. There IQs were above 150. >Complex is easy. Simple is hard. And yes, some things are inhe…

[flagged]

> It's almost like you are saying whatever you think will make you right in the moment.

Please don't cross into personal attack, no matter how wrong another commenter is or you feel they are. It just makes things worse. We've had to ask you this before.

https://news.ycombinator.com/newsguidelines.html

Re: Clean Code vs. A Philosophy Of Software Design

#534

Post by lmm »

dgb23 wrote: post #514
lmm wrote: post #499

Earlier quoted context omitted.

IME the most time consuming maintenance issues are due to inconsistent code, which is usually a result of trying to avoid "abstractions and indirection" and keep it straightforward. A bunch of classes that just call each other is annoying, but trying to solve that by inlining the code results in something worse.

I agree. But here are other ways of accretion of code inconsistencies: - Premature abstractions that are subsequently worked around around the edges. - Automation built on top of wishful thinking instead of how people actually prefer to work. - Inconsistent naming and file structure. - Adopting many advanced or hyperspecific styles and techniques instead of leaning on more basic ones that already solve a problem. I f…

> I find it way easier, to go from more primitive, consistent, "inlined" code to more sophisticated abstractions that clearly solve emergent problems at a later point in time, than changing the direction of already factored, high level code.

Depends. If you reach the codebase at the point where it's already accumulated subtle differences between codepaths that should be the same, that's far harder than inlining and rearranging something that's been factored badly, IME.

> A caveat here is that many of these inconsistency factors come from adopting third party dependencies.

I find the exact opposite. Developing too much internally creates a lot of inconsistency. If you hit an incompatible change in a third party dependency, odds are a lot of other people have hit the same thing and can tell you what to do.

Re: Clean Code vs. A Philosophy Of Software Design

#535

Post by lmm »

Copenjin wrote: post #511
lmm wrote: post #486

Earlier quoted context omitted.

> which contains brilliance like requiring pair programming for every line of code written Because it works. Have you tried it?

Force it on people, you'll see how much it works. Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone. Just do proper code reviews. Middle ground.

IME code reviews are a bullshit half-measure that ends up as the worst of all worlds. It's tragic that so many companies settle on them as a compromise position.

Re: Clean Code vs. A Philosophy Of Software Design

#536

Post by chillpenguin »

regularfry wrote: post #173
jacobsenscott wrote: post #113

I was around before the clean code movement, and like all software movements, it was a reaction to real problems in the software industry. Massive procedural functions with deeply nested conditionals, no structure, global variables, no testing at all. That was all the norm. Clean Code pushed things in a better direction, but it over-corrected. In many ways APOSD (published in 2018) is a correction against the excesse…

I believe that there is a genuine physiological effect that makes it a good idea to have the area of code that you need to think about fit entirely on one screen, without scrolling. There is probably an upper limit to the screen height where that limit is useful: I would believe a 100-line function to be above it and a 24-line function to be safely below it, but I wouldn't want to hazard a guess in the middle. It's a…

I agree. I once attempted this on a javascript project (a personal project, not at work), after reading about APL/J/K people and their philosophy. My constraint was: I should never have to scroll. I also aimed to have as few files as possible.

The result was surprisingly pleasant, and it changed how I feel about this sort of thing. I think the Clean Code approach makes a lot of sense when you are working on a big project that contains lots of code that other people wrote, and you rely on IDE features like jumping to definition, etc. But if you can write code that fits on one screen without scrolling, something special happens. It's like all the negative aspects of terse code suddenly vanish and you get something way simpler and overall easier to work with and understand. But you really have to work to get it to that point. A middle ground (terse code but still spread out over lots of files, lots of scrolling) would be the worst of both worlds.

Re: Clean Code vs. A Philosophy Of Software Design

#537

Post by mrkeen »

0xbadcafebee wrote: post #272

> For me, the fundamental goal of software design is to make it easy to understand and modify the system. I use the term "complexity" to refer to things that make it hard to understand and modify a system. This explains everything that's wrong with modern software. When you design a Formula 1 race car engine, the purpose of engine design is not to "make the engine easier to modify". It's to win races. And that depend…

This is what the soft in software means. It needs to be able to be adapted and change with its requirements.

My favourite story from a previous job was working with high-speed scanners, OCR, data quality, typo correction - that kind of thing.

The pipeline did its job well enough. But later we got a new contract where we accepted email submissions (where the customer had scanned stuff themselves). The guys couldn't hook that into the pipeline, so they set up a new pipeline - to print out the emails so they could then be scanned into the existing pipeline.

I still get a good laugh about that to this day.

Re: Clean Code vs. A Philosophy Of Software Design

#538

Post by mrkeen »

jdmoreira wrote: post #403

Uncle Bob probably the biggest scammer in Software. What a complete pile of garbage. So much energy wasted in all these design patterns, SOLID and other OOP bullshit. Turns out you can just pass immutable data in and get immutable data out. Who would have guessed? The whole 90s - 00s Java OOP garbage still gives me nightmares

FWIW Uncle Bob has been preaching functional for more than 10 years now.

https://youtu.be/7Zlp9rKHGD4

Re: Clean Code vs. A Philosophy Of Software Design

#539

Post by mrkeen »

Kerrick wrote: post #485
valenterry wrote: post #477

Earlier quoted context omitted.

> the order can decide whether to fulfill that request. In my world of thinking, orders don't make decisions. If I go to the business team and say "the order decided to" they'll look at me funny. And for good reasons.

Go back and read what I said about subject nouns and object nouns. When converting OO concepts to English for non-programmers, it is indeed confusing to say “the order decided not to”—you say “the order couldn’t be” instead. I highly recommend reading the two books I recommended for further perspective on the topic. OO is predicated not on the idea that data is a bag of dead bits on which operations are performed, bu…

> I highly recommend reading the two books I recommended

From "Object-Oriented Analysis and Design with Applications" (3rd edition) by Grady Booch:

p.52: Separation of Concerns

  We do not make it a responsibility of the Heater abstraction to maintain a fixed temperature. Instead, we choose to give this responsibility to another object (e.g., the Heater Controller), which must collaborate with a temperature sensor and a heater to achieve this higher-level behavior. We call this behavior higher-level because it builds on the primitive semantics of temperature sensors and heaters and adds some new semantics, namely, hysteresis, which prevents the heater from being turned on and off too rapidly when the temperature is near boundary conditions. By deciding on this separation of responsibilities, we make each individual abstraction more cohesive.

Re: Clean Code vs. A Philosophy Of Software Design

#540

Post by gabrieledarrigo »

Copenjin wrote: post #511
lmm wrote: post #486

Earlier quoted context omitted.

> which contains brilliance like requiring pair programming for every line of code written Because it works. Have you tried it?

Force it on people, you'll see how much it works. Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone. Just do proper code reviews. Middle ground.

Pair programming should never be forced, but when applied... Jeez, it's powerful!
Post reply on HN