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

481–490 of 599 posts

Re: Goodbye, Clean Code

#481

Post by _y5hn »

JoeyJoJoJr wrote: post #406
TheRealDunkirk wrote: post #294

Earlier quoted context omitted.

Several years ago, I wrote a big chunk of code to analyze engineering data from an engine test cell, and display a graph of the results. Someone else had done the hard part; I was merely coding up a gloriously-complex Excel spreadsheet in C++. I grabbed data from a MySQL database, and labeled the row data like: row[combustion_air_mass_flow] + row[fuel_mass_flow] * row[specific_gravity_of_diesel]. (Or whatever; it's b…

This reminds me when a developer took over my codebase while I was on holiday. When I returned I had discovered that he converted all tab indents to spaces across the entire project. He completely destroyed my ability to perform diffs against earlier commits, because his preference was evidentially more important. Of course this was all justified with a link to Google’s coding style guide.

It destroyed your ability to exclude whitespace from diffs?

Re: Goodbye, Clean Code

#482

Post by kazinator »

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…

Not only DRY but YAGNI.

Unless you are sure you will need to separately evolve the initially duplicated cases, assume YAGNI: You're Not Gonna Need It (the repetitions).

Avoid repetition like the plague; when the new requirements arise that conflict with the reduced repetition, confront it at that time.

It's possible they they are bad requirements, in which case the clean, DRY code can support arguments against the requirements.

Treat the computer as more of an Analytical Engine, and less of a Jacquard Loom.

The special case behaviors for various shapes hinted at in the article:

> For example, we later needed many special cases and behaviors for different handles on different shapes.

This sounds like it might be a bad experience for the end user who has to learn annoying shape-specific handle quirks.

Re: Goodbye, Clean Code

#483

Post by _y5hn »

flavio81 wrote: post #460
_y5hn wrote: post #444

Earlier quoted context omitted.

Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.

>Except exceptions are rarely understood and used correctly by most programmers. That's just your opinion.

When applications and services still defaults to dumping full stacktrace and reporting programmer's errors, it's from longer-term experience also.

Re: Goodbye, Clean Code

#484

Post by _y5hn »

hota_mazi wrote: post #463
_y5hn wrote: post #444

Earlier quoted context omitted.

Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.

> 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 kinds of business logic states. I'm not saying the Go Way is perfect either, but it's at least a small step acknowledging the difference, rather than defaulting to dumping random programmer errors on unsuspecting users.

Errorhandling is easier when improving design. The problem is this takes time, thinking and effort.

Re: Goodbye, Clean Code

#485

Post by kazinator »

dkersten wrote: post #438
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…

> make it “generic enough to handle future use cases”. The answer to this is usually YAGNI. That is, don’t plan for a future you might never have. Code in a way that won’t back you into a corner, but you don’t know what the future’s cases might be (or if there even will be any) so you can’t possibly design in a generic way to handle them. Often you just end up with over-engineered generec-ness that doesn’t actually h…

The repetition is what is YAGNI!

Repeating code 7 times in preparation for separate evolution of those 7 cases is YAGNI, unless the requirements are on the table now.

Merging repeated code into one is something that is demonstrably needed now, not later.

Re: Goodbye, Clean Code

#486

Post by kazinator »

BinaryIdiot wrote: post #295
bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

> I also think that a salaried engineer who thinks that a piece of code he or she (but almost always he) wrote is "his" or "hers" is totally wrong. It's the company's code. While this is _technically correct_, this isn't how humans work. Humans attach their worth to things they do, even when they shouldn't. It's a difficult thing to avoid to most people so if you write some code, commit it and then later see a teamma…

The fix for this is to have a review system in place; you can then catch blatant code repetition before it goes in, and try to use your soft skills to guide the author toward a different solution such that they think it was their idea all along.

Re: Goodbye, Clean Code

#487

Post by einpoklum »

loup-vaillant wrote: post #452
einpoklum wrote: post #342

Earlier quoted context omitted.

> There isn't much code I wrote in my previous professional career that is still live That means your impact on the world has been very limited. You haven't contributed to the basis of what other coders used. Not that this is illegitimate - but I believe we should strive further. > the reason is vendors only make a profit because they need to generate cashflow constantly, and they do it by breaking the above rules un…

> You haven't contributed to the basis of what other coders used. What fraction of us can claim they have, really? Most developers work at the application layer, the last one. The more foundational your stuff is, the less of it there is, because it is reused everywhere. For similar reasons, very few people work on massively popular software. Most work on software that have only a couple users, or even just one (typic…

> What fraction of us can claim they have, really?

I think it's larger than you imagine. Just look at the code of GitHub, BitBucket, Sourceforge etc. Not to mention self-hosted commercially-developed FOSS.

> Most developers work at the application layer, the last one.

Well, that doesn't mean they have to work _only_ on that. Each developer uses a bunch of libraries, utilities and frameworks which are either FOSS or could use a FOSS alternative.

> For similar reasons, very few people work on massively popular software.

Well, yes, this is true, but you can work on somewhat-popular or even niche software which is still used by hundreds of thousands, or just thousands, of people. That's still very significant!

> Implying that every programmer worth their salt should have produced code other programmers use is just not realistic.

Well, drop the "have". I think programmers worth their salt should strive to produce code that other programmers use.

Morever - I believe that it's the visible code, and the free code, is what we should use as the model and the target of advice and improvement.

Re: Goodbye, Clean Code

#488

Post by kazinator »

woutr_be wrote: post #373
bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

I need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other engineers. It's a huge blow to team morale, and it gave me a fear of writing code in this team. Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no…

> Every time I wrote a piece of code, I wondered how long it would be there for.

The fix for that sort of thing is to have a satisfying, enduring side project where you're the boss: nothing is upstreamed that you don't like.

Then you can stop caring if your code at work gets replaced, and how fast.

Re: Goodbye, Clean Code

#489

Post by MattyRad »

There are at least 6 giant and contentious subjects covered in this one, short article:

- Code duplication (when it's appropriate)

- Code cosmetics/legibility

- Code scalability/flexibility

- Code review (protocols, how to perform them)

- Accepted widespread coding wisdom (abstractions, and shirking them, in this case)

- What defines a "junior" engineer (there are wildly different perspectives in this thread)

- Common courtesy (coworker interaction, etc)

Almost all out these are highly circumstantial to the type of project, codebase, language, culture, etc. I would like to see a productive conversation regarding any of these topics, but discussing so much at once in such circumstantial ways just leaves us talking past each other (the threads here are pretty clear evidence of that). I don't think this article has enough substance to cover any of these topics in any depth.

It's like if someone asked "What vehicle is the best vehicle?" Some people chime in with how much they like their brand of vehicle. Others say how trucks are better then cars. Others say that electric is the only choice. Others say cars made after 2010 are the best. The question is too broad so the responses aren't effective.

Re: Goodbye, Clean Code

#490

Post by aj7 »

endgame wrote: post #248
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…

From (I think) an old Joshua Bloch talk on API design, paraphrased: * If you generalise based on one example, you will get a flexible API that can handle only that example. * If you generalise based on two examples, you will get a flexible API that can switch between those two examples. * If you generalise based on three examples, you have a chance of abstracting over the common essence.

Until an example that “doesn’t fit” ?
Post reply on HN