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

111–120 of 599 posts

Re: Goodbye, Clean Code

#111

Post by cc81 »

Rapzid wrote: post #82
mntmoss wrote: post #51

Earlier quoted context omitted.

The code is not large enough to need maintenance at a fine-grained level. There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it. The feature is done, and we are into code golf and speculation, neither of which are productive uses of time. In my experience the success rate of speculative refactors like the one author made has p…

The author also didn't sound like a particularly senior engineer at the time for many reasons. So the original code author and the "boss" may have been taking into consideration timelines and future work/requirements coming down the pipe. A very valid reason could have been as simple as "We are re-visiting this in a couple sprints after feedback and will have a better idea of how it needs to change. The extra day spe…

I heard something like: "The second system you design will be the most over engineered piece of shit ever"

I don't know who said it but it has been very true for me and my close friends who work in software development. I remember first starting software development and I started to read up on "how to do it right" in the Java/C# world back when XML was everywhere.

I had first started to expand my skills after university by building my own blog (who didn't at that time?) but thought I should rebuild it according to "best practices".

Hoooooly shit that was a poorly architected and designed piece of software. The example in the blog was of course not as poor of an example as my creation but I feel that many end up in this trap after they have some experience that they need to do everything "right" and they don't have the experience to evaluate if it is worth it.

However I also think a good workplace have a healthy mix because those youngsters will also push the old guard to learn new things and introduce new technology. Just need a balance between using 0.1-alpha libraries and things that were released 10 years ago.

Re: Goodbye, Clean Code

#112

Post by kilroy_jones »

At first I wrote ugly convoluted code.

Then, upon seeing the light I wrote clean and organized code.

Now I write what many see as ugly convoluted code because I see further down the line than they do.

Re: Goodbye, Clean Code

#113

Post by DelightOne »

arendtio wrote: post #90
renox wrote: post #77

Earlier quoted context omitted.

In the language maybe but both Rust and Zig show that it's possible to have much less 'bloat' for error handling even without using exceptions. I'd say that go designers have still work to do: Zig especially show that you can be a 'simple' language and yet have both sane error handling and generics.

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

On the error branch, how do you do code coverage?

Re: Goodbye, Clean Code

#114

Post by babarock »

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…

One of the areas where I really like "incidental duplication" is in tests.

Tests can sometimes be very repetitive and identical, and it's tempting to want to refactor it in some clever way. That's almost never good.

On top of the reasons laid out in parent comment, tests also function as unofficial documentation. I like having everything explicit in there, it makes them easier to read and understand.

Re: Goodbye, Clean Code

#115

Post by bsaul »

franciscop wrote: post #47

This should rightfully be on the front-page of HN. I've gone through something almost the same as Dan Abramov here, and I feel it's difficult to impossible to explain this and you have to experience it yourself. The tricky bit is where to draw the line, which I've learned only after pouring thousands of lines of code and I understand is a bit different for everybody. The rule of three[1] was a very useful rule of thu…

The more time passes, the more i consider coding to have a strong aesthetic component. What makes it complex is that there are two kind of "aesthetics":

- the code itself

- the abstractions that the code represents.

You can have very "clean looking" code (short functions, short files, no repetition, etc. ) that is in fact modeling a problem in the most convoluted way. And the other way around : a bit of repetition, but the concepts behind are completely obvious.

And most of the time, nothing falls completely into one category, and the way you'll decide where to draw the line is almost a matter of taste.

Re: Goodbye, Clean Code

#116

Post by marcus_holmes »

arendtio wrote: post #90
renox wrote: post #77

Earlier quoted context omitted.

In the language maybe but both Rust and Zig show that it's possible to have much less 'bloat' for error handling even without using exceptions. I'd say that go designers have still work to do: Zig especially show that you can be a 'simple' language and yet have both sane error handling and generics.

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, error check" becomes the routine pattern of your code and it looks weird if you don't check for errors (which is as it should be).

2. The point of Go's error handling is that it isn't magic. There's nothing special about error values, and they are handled exactly the same way as every other variable in the system. The only thing the language defines about errors is that they have a method called Error that returns a string. That's it. This means that you can create complex error handlers if you need it, entirely within the standard language. This is extremely powerful.

The Go team's examination of the language error handling is interesting because it seems there's a conflict between newer Gophers who don't like the verbosity of it (but don't realise the power it brings) and the older Gophers who are used to the verbosity and appreciate the power. Almost exactly like TFA. The repitition looks ugly if you don't appreciate the reasons for it.

Re: Goodbye, Clean Code

#117

Post by shultays »

I worked with someone that considered code repetition as a force of evil that needs to be fight at all costs. Some of his refactors were valid, other not so much and made everything more awkwars to work and more resiatant to change. It wasnt a pleasent experience.

Re: Goodbye, Clean Code

#118

Post by stevewilhelm »

> We were working on a graphics editor canvas, and they implemented the ability to resize shapes like rectangles and ovals by dragging small handles at their edges.

It's a dirty shame their development team had to build a graphics editor canvas from scratch.

Re: Goodbye, Clean Code

#119

Post by marcus_holmes »

Hendrikto wrote: post #96
lilyball wrote: post #73

Earlier quoted context omitted.

I have 2 rules I use when determining whether to duplicate code or to refactor: 1. How many duplications are there? If the code is duplicated once, that's fine. If it's duplicated twice (so 3 instances of it), then it's time to consider refactoring, subject to the next rule. 2. Why is the code duplicated? If it's "incidental duplication", i.e. code that happens to look the same, don't refactor. Only refactor if there…

> attempt to predict the future Sounds very error prone…

This. I wait until the feature is mature, and has been used by actual people. There's no point trying to clean up code that hasn't finished evolving, or that I don't understand fully.

It also means I have a tidy stack of refactoring to do when I'm bored or need a quick motivational win :)

Re: Goodbye, Clean Code

#120

Post by BubRoss »

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…

One big way I prevent this from happening is to treat classes as interfaces to data structures and keep everything that isn't about accessing the data elsewhere. Conversions to other data types go somewhere else. In fact I don't want my data types depending on any other data types at all.

When doing this any of this repetition or evolution can stay out of the data structures themselves so that they can be reused without irrelevant baggage.

Post reply on HN