Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Clean Code

overreacted.io

Post reply on HN
Print view View original

501–510 of 599 posts

Re: Goodbye, Clean Code

#501

Post by [deleted] »

marcus_holmes wrote: post #116
arendtio wrote: post #90

Earlier quoted context omitted.

If someone else is looking for examples too, I found those: https://www.reddit.com/r/Zig/comments/99zlc9/exceptions_or_e...

I thought all of this until I got used to Go's error handling. There's a couple aspects to this: 1. After a while, the "if err != nil {" becomes a single statement in your mind, and you only notice it if it's different (like trapping things that should error with "if err == nil {"). In other words, it only feels verbose if you're not used to it. After a while, the regular rhythm of "statement, error check, statement,…

[deleted]

Re: Goodbye, Clean Code

#502

Post by lleolin »

When I look at his example I still sense a compelling sense to create some kind of abstraction. It's just that the example abstraction he chose to make is somewhat esoteric and arguably over-solves the problem. The author isn't suggesting a different, perhaps simpler abstraction, but forgoes abstractions entirely.

Re: Goodbye, Clean Code

#503

Post by luord »

_pmf_ wrote: post #476
luord wrote: post #470

> Let clean code guide you. Then let it go. Nah, no offense to the react fans but I'd rather listen to Fowler than to this guy. Sure, there are very specific exceptions where repeated code is an asset instead of a liability (and many of them are, appropriately enough, when dealing with graphics), but they are that: very specific . For 99% of situations, we ought to follow the principles (obligatory IMO).

I think you're confusing Fowler and Uncle Bob.

Well, I mentioned Fowler because of this: https://martinfowler.com/tags/clean%20code.html

Though he and Uncle Bob agree on many of these things so one could replace one for the other in my comment, I think.

Re: Goodbye, Clean Code

#504

Post by luord »

seattle_spring wrote: post #471
luord wrote: post #470

> Let clean code guide you. Then let it go. Nah, no offense to the react fans but I'd rather listen to Fowler than to this guy. Sure, there are very specific exceptions where repeated code is an asset instead of a liability (and many of them are, appropriately enough, when dealing with graphics), but they are that: very specific . For 99% of situations, we ought to follow the principles (obligatory IMO).

Do you have specific experience that suggests that hyper-generalizing code before you even know about multiple use cases is beneficial over carefully extracting shared logic only when needed? If I to pick one single practice junior engineers employ that ultimately bites everyone in the ass, it's a blind adherence to generic code and DRY at all costs.

> Do you have specific experience that suggests that hyper-generalizing code before you even know about multiple use cases is beneficial over carefully extracting shared logic only when needed?

I've gone over my comment three times now and I'm yet to see where I even implied something like this. Could you tell me how you got this from my comment? I do want to see how I could send the wrong message so I can word myself better in the future.

Just in case, one of the principles I follow is "premature optimization is the root of all evil".

Re: Goodbye, Clean Code

#505

Post by drdaeman »

altitudinous wrote: post #244

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…

> Users don't care about clean code. They only care about the end product.

I'd disagree. Both code and compiled product are products, with different users. Your code's users care about the code. Your product's users care about the product.

The "whatever works" approach works for a solo developer of non-free software products, where there are no other users of the code. Or for one-off scripts that aren't meant to be used as code after they serve their purpose. Whenever there are other people who get to work (in any sense) on your code, things become more complicated.

Which doesn't mean code must be somewhat "clean" to some standards. IMHO, the only thing that matters is that every user of the code can understand its logic and feel good (or, at least, doesn't feel bad) working on it.

Re: Goodbye, Clean Code

#506

Post by scarface74 »

Stratoscope wrote: post #262
scarface74 wrote: post #25

Earlier quoted context omitted.

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

The Rule of 3 is a great rule, except when it isn't. I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different…

If the compiler didn’t catch it, doesn’t that say it was modeled incorrectly?

Why not have an IAirSpace interface or an abstract AirSpace class with two specializations? If there were processes that could handle either it should take an AirSpace class, one that could only handle one or the other took the specialization.

If the steps were the same for handling both, have step1...step(n) defined in the concrete class and have a coordinating “service” that just calls the steps and takes in an IAirSpace.

Re: Goodbye, Clean Code

#507

Post by scarface74 »

labawi wrote: post #424
_y5hn wrote: post #420

Earlier quoted context omitted.

Are you sure merging code for different datafeeds would be better though? In such cases, what is identical and what is not, should be references to eachother in comments. But you don't know beforehand which approach would be better, unless you know the datafeeds will stay the same as now. The sad story here is that if you know the datafeeds will stay pretty static, there's little to gain making an advanced abstractio…

If you have a 95% match on something nontrivial (and it likely won't diverge significantly), I'd go for merging even with 2 cases. At least merge most of the common parts. Reading a couple of ifs, and some not-quite duplicate procedures seems much better than having a complete 2-set in cross-refenenced files.

Why are you reading a couple of ifs instead of having the two similar things represented by separate classes with shared functionality in a common class? Or even if you prefer composition to inheritance you could still make it work cleaner without a bunch of if statements.

Re: Goodbye, Clean Code

#508

Post by sitkack »

speedplane wrote: post #388
burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

> don’t extract repetitive code right away, try and build the feature you’re working on with the duplication in place first. I have a similar rule of thumb: when you do a thing the first time, just get it working. When you do a similar thing a second time, just get it working. When you do a thing a third time, pull it together as a cohesive abstraction. This is a silly generalization, but the point is that you genera…

And the abstractions are not abstracting over the correct things so they are actually a net negative. One has to reason about the abstraction AND the problem domain.

I find it helpful to work with ADTs of values, lists and maps. No OO, just functions for selection and projection. The majority of programming is figuring out the nuances of the domain and getting something working. Code is actually an impediment to that.

Re: Goodbye, Clean Code

#509

Post by hota_mazi »

_y5hn wrote: post #484
hota_mazi wrote: post #463

Earlier quoted context omitted.

> Except exceptions are rarely understood and used correctly by most programmers That's pretty condescending. The mechanism for exceptions has been around for more than 20 years, it is well understood by most programmers. The problem is that error handling is hard. Exceptions are an adequately sophisticated solution to that hard problem. Go's approach only encourages ignoring errors (since the compiler never enforces…

Is it really: Are programmers omniscient then that they can trap all kinds of exceptions correctly from external code? It's a sophisticated method that dumps the problem on the user instead. Golang also output stack traces and even supports panic() if one wants to have something similar to handling exceptions. The difference is that this is used for classes of errors that ideally are programmer error, and not for all…

Go didn't discover anything. Java's runtime and checked exceptions are already the direct consequence of errors being of two kinds: recoverable and non recoverable.

Go's approach is inferior to Java's in all ways.

Re: Goodbye, Clean Code

#510

Post by gherkinnn »

iamaelephant wrote: post #213
madeofpalk wrote: post #194

Earlier quoted context omitted.

What are some examples of React's focus on shorthand and abstraction? React is fairly small and doesn't really encourage much at all. The one 'battle' that I often find myself in is "should this be a seperate component?" but that's more of a people problem and something that every language and framework will have.

Hooks.

HoCs
Post reply on HN