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

541–550 of 599 posts

Re: Goodbye, Clean Code

#541

Post by Stratoscope »

a1369209993 wrote: post #528
Stratoscope wrote: post #262

Earlier quoted context omitted.

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…

> The Rule of 3 is a great rule, except when it isn't. "Rules are for the guidance of wise men and the obedience of fools." It's unfortunate that you had to deal with a fool, but that's not a indictment of the particular rule that they picked to follow off a proverbial cliff. Edit: fixed ambiguous quote formatting.

Thanks for your reply. I just want to note that what appears to be a quote in your comment ("Rules are for the guidance of wise men and the obedience of fools") is not something I wrote at all. If you still have time to edit the comment, I might suggest changing that so it doesn't look like you quoted me.

Re: Goodbye, Clean Code

#542

Post by bjornjajajaja »

gameswithgo wrote: post #433
Stratoscope wrote: post #262

Earlier quoted context omitted.

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…

Every single rule or advice in programming is good until it isn't. OOP is good until it isn't, function programming is good until it isn't, premature optimization is the root of all evil until it is the root of all good. For some reasons humans have this deep need to try and boil things down to bulleted lists which in the domain of programming are just incredibly not useful.

This is because programming is an art. It has fundamental components (objects, functions, templates, iterators, etc) like in visual design (point, line, shape, value, etc).

I think engineers should read the old and the new C++ books and master that language to know the evolution of all these paradigms and how to use them. There’s so much wisdom in the “Effective C++” series and Gang of Four and “C++ Templates: The complete guide“ to name a few.

Problem is in this “start up culture” to bang things out and get them working the art is left behind. Just like many other arts.

Re: Goodbye, Clean Code

#543

Post by latchkey »

vgrafe wrote: post #439
latchkey wrote: post #242

Earlier quoted context omitted.

Of course, we all have had that experience! So you have a choice... realize it is going to happen and learn to deal with it in a productive manner, or just continue to get upset about it. I know which choice I'm working towards...

Are you suggesting that a dev acting like this without consulting the team should be considered normal/expected? Not sure how to address a move which is unproductive in its nature "in a productive manner" unless being proactive and preventing those rewrites to happen, unless needed and discussed with the team. But in my personal experience the team's decisions were always ignored by the coder in question. edit: I sho…

Since this is a fairly common dev experience (rewriting code), that the team meet together to set a policy as a group. Similar to code format standards, why not talk about code maintenance standards?

Re: Goodbye, Clean Code

#544

Post by [deleted] »

seattle_spring wrote: post #524
luord wrote: post #504

Earlier quoted context omitted.

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

The article was literally about that, and your first line says "nah I'm good."

[deleted]

Re: Goodbye, Clean Code

#545

Post by kbutler »

erik_seaberg wrote: post #15
boffinism wrote: post #9

I think this highlights an important nuance to the Don't Repeat Yourself maxim. It's not just about whether two bits of code are similar now. It's about whether, when they change in future, they are likely to change in the same ways. If not, then DRYing up the code now is only making more work for yourself down the line.

I've always found the https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle , where you derive from classes instead of editing them in-place, sort of appealing for this reason.

Prefer extension via composition for more flexibility than via inheritance, which tends to create overly rigid hierarchies.

Re: Goodbye, Clean Code

#546

Post by [deleted] »

seattle_spring wrote: post #524
luord wrote: post #504

Earlier quoted context omitted.

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

The article was literally about that, and your first line says "nah I'm good."

[deleted]

Re: Goodbye, Clean Code

#547

Post by user5994461 »

celticmusic wrote: post #540
user5994461 wrote: post #423

Earlier quoted context omitted.

Just leave the job already. I've only seen that once in my career. One developer rewriting existing code constantly, to such an extreme degree it's unfathomable. He rewrote large amount of scripts (often overnight). Other developers would wake up the next day or continue the project next week, only to find a swath of issue reported by users and the project is gone (rewritten and moved). Did that for while, destroying…

I specifically state it was a contract and you're talking about a job. this reminds me of Steve Yegge. He did a post on the difference between employed developers and entrepreneurs, and how they're completely different creatures. You've allowed yourself to become a pet and you've given up the ability to care about your work for food and you think it's a moral failing in others who have not. You're to be pitied.

Same thing. Do you realize that the average tenure in permanent positions is around a year nowadays? It's not longer than the usual contractor.

Re: Goodbye, Clean Code

#548

Post by Gibbon1 »

scarface74 wrote: post #465
bcrosby95 wrote: post #276

Earlier quoted context omitted.

The rule of 3 usually is in reference to small scoped abstractions, not whole modules or subsystems. We're talking about extracting a short function, not significant and potentially thorny chunks of code. But I guess no one explicitly spells this out, so I could see where someone could become confused.

The rule of 3 usually is in reference to small scoped abstractions, not whole modules or subsystems. We're talking about extracting a short function, not significant and potentially thorny chunks of code. I would say it’s for entire features sometimes. For instance, we are a B2B company. We have features on the roadmap or a feature might be suggested by a client. Either way, you hit the jackpot if you can get one cli…

That's been my experience doing embedded stuff. Customers will tell you they want a feature. You'll implement it then find out they don't need it enough to devote resources to utilize it on their end. So then it just lingers in the code base. And never gets real world testing. Lately I've been pulling unused features and consigning the code to the land of misfit toys. Just so I don't have to maintain them.

Re: Goodbye, Clean Code

#549

Post by hermitdev »

bjornjajajaja wrote: post #542
gameswithgo wrote: post #433

Earlier quoted context omitted.

Every single rule or advice in programming is good until it isn't. OOP is good until it isn't, function programming is good until it isn't, premature optimization is the root of all evil until it is the root of all good. For some reasons humans have this deep need to try and boil things down to bulleted lists which in the domain of programming are just incredibly not useful.

This is because programming is an art. It has fundamental components (objects, functions, templates, iterators, etc) like in visual design (point, line, shape, value, etc). I think engineers should read the old and the new C++ books and master that language to know the evolution of all these paradigms and how to use them. There’s so much wisdom in the “Effective C++” series and Gang of Four and “C++ Templates: The co…

I was part of an uncredited team interviewed by Meyers for "Effective Modern C++". Always thought ir was somewhat ironic. At the firm (declined acknowledgments because they shun media attention) we werent even using a C++11 compiler on either Linux or Windows at the time. Yet, at least two of the patterns, I recognize as being at least a partial contributor to.

Myself, I lost track of C++ standards changes with C++17, and Ive not been using C++ for the last several years.

I still love the power and speed, but right now I'm dping more ETL work, and Python is a better and more productive language for that.

Re: Goodbye, Clean Code

#550

Post by d_burfoot »

I think this guy learned exactly the wrong lesson. The lesson he ought to have learn is to avoid premature optimization - he tried to refactor the code too soon after is was originally created. He should have waited a while so that the additional requirements were fleshed out before trying to create abstractions.
Post reply on HN