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

351–360 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#351

Post by wglb »

lmm wrote: post #132
motorest wrote: post #94

Earlier quoted context omitted.

> "It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. See, this is the sort of lazy ignorance that adds nothing of value to the discussion, and just reads as spiteful adhominems. Domain models are fundamentally an object-oriented programming concept. You model the business d…

> Domain models are fundamentally an object-oriented programming concept. They are not. > You model the business domain with classes, meaning you specify in them the behavior that reflects your business domain. I have better tools for doing that. > In Domain-Driven design, with its basis on OO, you implement these operations at the class level, because your classes model the business domain and implement business rul…

> I care whether it results in effective, maintainable software with low defect rates.

This is what it is about. All the other things that have been invented need to be in service of this goal.

Re: Clean Code vs. A Philosophy Of Software Design

#352

Post by yuliyp »

hliyan wrote: post #196
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…

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…

Systems need to be able to handle all kinds of stresses placed on them during their useful life. The runtime bytecode/machine code/config is what deals with the actual running of the system. The code is what deals with the engineers making future modifications to it. The monitoring system deals with being able to allow operators to ensure the system stays up. All of these affect the reliability and performance of the deployed system during its lifetime. All of them are a part of the design of the system.

Re: Clean Code vs. A Philosophy Of Software Design

#353

Post by Kerrick »

valenterry wrote: post #265
Kerrick wrote: post #253

Earlier quoted context omitted.

We have a disagreement about the core of OOP. In English, a simple sentence like "The cat eats the rat" can be broken down as follows: - Cat is the subject noun - Eats is the verb - Rat is the object noun In object-oriented programming, the subject is most often the programmer, the program, the computer, the user agent, or the user. The object is... the object. The verb is the method. So, imagine the sentence "the cu…

> So, imagine the sentence "the customer canceled the order." > - Customer is the subject noun And this is wrong. Because the customer did not cancel the order. The customer actually asked for the order to be canceled. And the order was then canceled by "the system". Whatever that system is. And that is the reason why it is not expressed as customer.cancel(order) but rather system.cancel(order, reason = "customer ask…

> The customer actually asked for the order to be canceled.

This is why many object-oriented programmers prefer to talk about message passing instead of method calling. It is indeed about asking for the order to be canceled, and the order can decide whether to fulfill that request.

Re: Clean Code vs. A Philosophy Of Software Design

#354

Post by hakunin »

Pxtl wrote: post #347
hakunin wrote: post #42

Earlier quoted context omitted.

That’s exactly why you should save that length only for a method that’s indeed doing something weird. If every method is long, the codebase turns into noise. (IOW I agree)

I used to work this way, but I found that every non-trivial method involves edge-cases and workarounds documenting them the method name destroyed readability.

The only point I was making is that short name signals that nothing unusual is going on, and long name signals that you have to pay extra attention. I never suggest to replace a comment with a long name. Here's my 4 reasons to leave a comment: https://max.engineer/reasons-to-leave-comment Comments are crucial for "why", and additional context. Name shouldn't go beyond "what". More on that here: https://max.engineer/maintainable-code (Check the "What" section that focuses on naming).

Re: Clean Code vs. A Philosophy Of Software Design

#355

Post by WillAdams »

kragen wrote: post #149

Crucial context here: Ousterhout is one of the great programmers who built the free software world we live in today, and Uncle Bob is a faker. Ousterhout is not without his problems (Stallman famously called him a "parasite" on the free software community, as well as fervently disagreeing with his technical taste) but he's written truly world-changing software. By contrast, Uncle Bob is a windbag book author who has…

Curious what Stallman has to say about Robert C. Martin --- looked, but couldn't find anything....

Re: Clean Code vs. A Philosophy Of Software Design

#356

Post by wglb »

overgard wrote: post #60
zbentley wrote: post #4

It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript. Stylistic refactors that induce performance regressions, extremely long and tortured method names for three-line methods, near-total animus towards comments ... regardless of who is right/wrong about what, those takes seem like sophomoric extremism at its worst, not reasoned pragmatism that can be ap…

I haven't seen a lot of evidence that Martin really has the coding chops to speak as authoritatively as he does. I think when you become famous for giving advice or being an "expert", it can be difficult to humble yourself enough to learn new things. I know personally I've said a lot of dumb things about coding in the past; luckily none of those things were codified into a "classic" book. What strikes me about the ad…

> I haven't seen a lot of evidence that Martin really has the coding chops to speak as authoritatively as he does

From what I can deduce, his major coding work was long in the past, and maybe in C++.

Re: Clean Code vs. A Philosophy Of Software Design

#357

Post by allemagne »

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…

A genius architect/Formula 1 engineer can design a building/engine that fits all the requirements astonishingly perfectly, but if the builders have difficulties understanding it, or later contractors can't figure out how to maintain or fix anything, then it's only a perfect design in theory and an awful design in reality. It's not a nice-to-have to make people's lives a little easier, it defines the success of the project. The genius architect/engineer can insist that the complex design reflects the underlying domain as much as they want but at some point they will have to back that up to someone else who isn't a genius.

Obviously, writing code such that a first year comp sci student can understand what's happening and can start contributing immediately is absurd, but at the same time nobody builds anything in a vacuum. There's a certain legibility required within any context you're designing something for.

Re: Clean Code vs. A Philosophy Of Software Design

#358

Post by kragen »

WillAdams wrote: post #355
kragen wrote: post #149

Crucial context here: Ousterhout is one of the great programmers who built the free software world we live in today, and Uncle Bob is a faker. Ousterhout is not without his problems (Stallman famously called him a "parasite" on the free software community, as well as fervently disagreeing with his technical taste) but he's written truly world-changing software. By contrast, Uncle Bob is a windbag book author who has…

Curious what Stallman has to say about Robert C. Martin --- looked, but couldn't find anything....

Not about Martin. About Ousterhout. 27-30 years ago.

Re: Clean Code vs. A Philosophy Of Software Design

#359

Post by igouy »

wglb wrote: post #341
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?

It is a bit weird. However, a friend of mine was a professional Smalltalk programmer. He claims that his median line count of methods, over his 17 year career, was 4. It is harder to do in other languages--it seems that C would be on the order of 10. Clearly it is a rule that can lead to complexity of too many methods, compromising whatever gain smaller methods give you.

> median line count of methods

Auto-generate getters and setters for every instance variable and that will drag the average down. (Maybe a lot of those getters and setters should not have existed.)

Re: Clean Code vs. A Philosophy Of Software Design

#360

Post by namuol »

yxhuvud wrote: post #236
namuol wrote: post #110

Earlier quoted context omitted.

Forget about the code itself and focus on the results. What I mean by that: Good code is code that has proven itself by surviving quietly in a long-living project that has changed a lot over many cycles of new engineers (experienced or otherwise) being onboarded. The less you hear people complain about it but the more you find people using or relying on it in some way, the better the code. If people are loud about ho…

No, because then you end up reading old C-code that are IFDEF mazes and think that is good code. No, to see good code you usually have to look at what experienced people write when they get to greenfield something new.

So you think code that is ugly is bad code? Or is it that it uses janky/outdated features? What makes it good if not its lifetime value?

Surely you don’t just presume the quality of code based on the person who wrote the code, right?

Post reply on HN