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

261–270 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#261

Post by ninetyninenine »

hakunin wrote: post #219
ninetyninenine wrote: post #216

Earlier quoted context omitted.

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.

Happened in a contrived example.

Re: Clean Code vs. A Philosophy Of Software Design

#262

Post by tremon »

kragen wrote: post #170
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…

Maybe some examples would clarify your intent, because all the candidate interpretations I can think of are absurd. The sin() function in the C standard library covers 2⁶⁴ cases, because it takes one argument which is, on most platforms, 64 bits. Are you suggesting that it should be separated into 2⁶⁰ separate functions? If you're saying you should pass in boolean and enum parameters to tell a subroutine or class whi…

That function covers 2⁶⁴ inputs, not cases. It handles only one case: converting an angular value to (half of) a cartesian coordinate.

Re: Clean Code vs. A Philosophy Of Software Design

#263

Post by Hasu »

> 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, not code.

Re: Clean Code vs. A Philosophy Of Software Design

#264

Post by kreetx »

randomNumber7 wrote: post #104
kreetx wrote: post #93

Earlier quoted context omitted.

It might just be that the divide of a getting-things-done developer and a bloat developer isn't really caused by Uncle Bob but merely correlates with it. I.e, good developers also agree with Uncle Bob, though apparently with a different interpretation of what he said.

Smart people read a book and critically think about it. The others think it was written by a superhuman and turn everything into religious beliefs.

I meant that the book is interpreted differently by different people. (That no-one takes it as religion, but that some read it as recommending to "create a mountain of unnecessary abstractions", and others read it that "add necessary abstractions".)

Re: Clean Code vs. A Philosophy Of Software Design

#265

Post by valenterry »

Kerrick wrote: post #253
mrkeen wrote: post #155

Earlier quoted context omitted.

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

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 asked for it").

> Thus, order.cancel(). The subject noun is left implicit, because it is redundant.

Ah, is that so? Then, I would like you to tell me: what happens if there are two systems (e.g. a legacy system and a new system, or even more systems) and the order needs to be sometimes cancelled in both, or just one of those systems? How does that work now in your world?

Re: Clean Code vs. A Philosophy Of Software Design

#266

Post by globnomulous »

ninetyninenine wrote: post #232
NeutralForest wrote: post #221

Earlier quoted context omitted.

But there are typical practices we agree are good: using a VCS, writing tests, write comments when needed, separate different level of abstractions, etc. Right? This comes from years of common experience in software. Over time we get to find patterns, common issues and ways to fix them, etc. It doesn't have to be strict patterns but overall strategies. If we don't do that then it's just vibes right? Where's the engin…

Nothing is fixed in stone. If you have strong typing and program with pure functions and immutability while utilizing union types and matching to the full extent you typically need very few unit tests for your code to work. You just need integration and e2e tests. I write very little unit tests as my coding style that employs static checks as viciously as possible doesn’t necessitate it. I would say only 30 percent o…

Could you give an example where you've used a "static check" where someone else might be likelier to use a unit test? I'm curious.

Re: Clean Code vs. A Philosophy Of Software Design

#268

Post by kragen »

narnarpapadaddy wrote: post #226
narnarpapadaddy wrote: post #223

Earlier quoted context omitted.

Think of it more like a “complexity distribution.” Rarely, a function with a single line or an interface with a single element or a class hierarchy with a single parent and child is useful. Mostly, that abstraction is overhead. Often, a function with 5-20 lines or an interface 5-20 members or a class hierarchy with 5-20 children is a useful abstraction. That’s the sweet spot between too broad (function “doStuff”) and…

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.

Re: Clean Code vs. A Philosophy Of Software Design

#269

Post by jjj123 »

ninetyninenine wrote: post #251
Ma8ee wrote: post #249

Earlier quoted context omitted.

Or maybe the smartest people understand that it is as important that less smart/experienced people than them can work with the code.

[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.

Re: Clean Code vs. A Philosophy Of Software Design

#270

Post by NeutralForest »

ninetyninenine wrote: post #255
NeutralForest wrote: post #250

Earlier quoted context omitted.

I don't really agree, unit test should test behavior, having types of not should not be a defining factor in the coverage. I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.

You don’t agree because you likely aren’t utilizing static checks to the extent that I do. Like there are no strings or numbers in my code. Everything is operating on strict union type boundaries. The only place where you have unbounded types like strings is on the interface to IO or state. I can code and not test behavior and have that behavior work reliably without tests. Key word is the unit trst. Typically IO and…

That's an interesting approach, I'd like to see an implementation of what you're talking about. What language are you using that has such an expressive type system?

Oh, I agree that there usually isn't a scientific method to programming. I think there could be though. Not for everything of course, some things will always be up to personal taste and interpretation but the cursor could probably be moved with some effort in analyzing existing codebases at scale, doing surveys, internal testing of different approaches in large companies. Something more akin to what you see in social sciences, even if it might be a bad word in some circles!

We probably won't agree but I legitimately enjoy hearing about how people code.

Post reply on HN