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

211–220 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#211

Post by ninetyninenine »

bena wrote: post #192
einpoklum wrote: post #181

Earlier quoted context omitted.

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 noticed the worse someone is in a language, the worse they format it. People then develop fastidious code formatting rules because they realize well formatted code is easier to read and extend. Then people realize it’s the organization of the code, not the rules themselves. They have preferences, but don’t treat those preferences as “the one true way”. So people with fastidious rules are in that middle ground of…

Disagree. Highly disagree.

Smarter people write shittier code.

Clean code is for stupider people.

Think about it. It’s because smart people don’t need clean code. It’s so trivial to them and so readable that they really don’t need things to be ultra clean and well formatted.

So the tendency to have this ocd need to write clean code among smart people is random. They either have it or they don’t give a shit.

But among stupid people it’s not random. They need clean code because they are not smart enough to understand code that isn’t clean.

Re: Clean Code vs. A Philosophy Of Software Design

#212

Post by Terretta »

overgard wrote: post #67

Bob's comments on... commenting.. are so bizarre that I can't help but think that he just refuses to concede the point rather than admit he might have been wrong about it. Like, the paranoia around incorrect/stale comments is fairly absurd, I've been coding for 20 years across many code bases, and I can't even recall a time when I've been significantly mislead by a comment which caused a significant waste of time. Ho…

> so bizarre ... what the hell is that supposed to tell someone?!

I liked this bizarre comment. It was like seeing a physical geometry proof for trig. Or like thinking about primes while riding a bike for an hour.

In 10 - 15 seconds this comment offered a flash of appliable intuition into primes I'd not appreciated before.

Granted, the bulk of that was first gathering that the top 3 rows of digits were a series turned sideways (printing them rotated would have made that instant). Joys of plaintext.

But then the pattern popped, and the code, including the optimization, made sense, but now from the "grok", with MTOWTDI.

Neither their commentary nor their function names and comments, caused the grok. I could "accept" the assertions, but to me neither naming nor comments were intuitively self-evident the way the diagram was.

Both of them commented on having to dwell on what the code was doing to consider refactoring. Once this flash happens, one no longer needs reference code at all, it's just another property of primes.

Re: Clean Code vs. A Philosophy Of Software Design

#213

Post by valenterry »

mrkeen wrote: post #155
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…

> Your Order class has a collection of Product items, but you can update an order, cancel a order, repeat an order, etc. This behavior should be member functions. This is how to fuck up OO and give it a bad name: order.update(..) // Now your Order knows about the database. order.cancel(..) // Now your Order can Email the Customer about a cancellation. order.repeat(..) // Now your Order knows about the Scheduler. What…

Aw, you described it so much nicer than me. I feel bad now.

Re: Clean Code vs. A Philosophy Of Software Design

#214

Post by ninetyninenine »

sudobash1 wrote: post #10

There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control. For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a m…

I don’t see anything wrong with those names. A bit hard to parse but the name moves with the function call while a comment does not.

It’s annoying to look at but when you actually read the function you know what it does. A more elegantly named function is less annoying to read but less informative and doesn’t provide critical information.

The name just looks ugly. But it’s like people have this ocd need to make things elegant when elegance is actually detrimental to the user. Can you actually give a legitimate reason why a method name like that is stupid other then its “hard to parse”. Like another user said… use snake case if you want to make it easier.

Re: Clean Code vs. A Philosophy Of Software Design

#215

Post by ninetyninenine »

slotrans wrote: post #59
sudobash1 wrote: post #10

There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control. For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a m…

> I will completely forget why I wrote it that way. This is the main reason for comments. The code can never tell you "why". Code is inherently about "what" and "how". The "why" must be expressed in prose.

Why not put the prose in the name of the function?

Re: Clean Code vs. A Philosophy Of Software Design

#216

Post by ninetyninenine »

hakunin wrote: post #42
mbo wrote: post #15

Earlier quoted context omitted.

While I am not a Uncle Bob-style "no comments"er I do love a ridiculous method name. I pay very close attention to that method and the context in which it is called because, well, it must be doing something very weird to deserve a name length like that.

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)

This doesn’t happen in reality. Your program does so many things that practically speaking short names work for a lot of functions in the program. It’s like English. There are big words and there are small words and usually to communicate a combination of big and small words are used.

Nobody practically communicates with big words. A long function name only pops up when needed.

Re: Clean Code vs. A Philosophy Of Software Design

#217

Post by holoduke »

ninetyninenine wrote: post #211
bena wrote: post #192

Earlier quoted context omitted.

I’ve noticed the worse someone is in a language, the worse they format it. People then develop fastidious code formatting rules because they realize well formatted code is easier to read and extend. Then people realize it’s the organization of the code, not the rules themselves. They have preferences, but don’t treat those preferences as “the one true way”. So people with fastidious rules are in that middle ground of…

Disagree. Highly disagree. Smarter people write shittier code. Clean code is for stupider people. Think about it. It’s because smart people don’t need clean code. It’s so trivial to them and so readable that they really don’t need things to be ultra clean and well formatted. So the tendency to have this ocd need to write clean code among smart people is random. They either have it or they don’t give a shit. But among…

Reality is that you have to work with different levels of intelligence. Your stack must be understandable also for the "common" programmer. Otherwise goodluck finding people.

Re: Clean Code vs. A Philosophy Of Software Design

#218

Post by spacechild1 »

motorest wrote: post #85
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…

> 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…

> What machines do with it is of lower priority. Why? Because a programmer's time is far more expensive than any infrastructure cost.

This assumes that code runs on corporate infrastructure. What if it runs on an end user device? As a user I certainly care about my phone's battery life. And we aren't even talking about environmental concerns. Finally, there are quite a few applications where speed actually matters.

> Comments is a self-admission you failed to write readable code, and you can fix your failure by refactoring code into self-descriptive member functions.

Self-explaining code is a noble goal, but in practice you will always have at least some code that needs additional comments, except for the most trivial applications. The world is not binary.

Re: Clean Code vs. A Philosophy Of Software Design

#219

Post by hakunin »

ninetyninenine wrote: post #216
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)

This doesn’t happen in reality. Your program does so many things that practically speaking short names work for a lot of functions in the program. It’s like English. There are big words and there are small words and usually to communicate a combination of big and small words are used. Nobody practically communicates with big words. A long function name only pops up when needed.

It happened in the article we’re discussing, and seems to be something Robert advocates for.

Re: Clean Code vs. A Philosophy Of Software Design

#220

Post by klysm »

sudobash1 wrote: post #10

There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control. For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a m…

Encoding temporal dependencies (or exclusions) between methods is hard. You can get partially there by using something like a typestate pattern (common in rust).
Post reply on HN