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

Don't be clever

stitcher.io

Post reply on HN
Print view View original

111–120 of 231 posts

Re: Don't be clever

#111

Post by xamolxix »

pphysch wrote: post #101
dmoy wrote: post #99

Earlier quoted context omitted.

I think GP means "make a tiny change [after generation, outside of the generator, and persist that change independent of the generator code]", which is where all the demons are waiting Modifying the generator itself to do something different every time, and doing GP's stated "regenerate and throw away the old stuff" is in line

It's not modifying the generator. The generator may be a proprietary black box. It's wrapping the generator in a bash script that pipes the result through AWK, etc.

> It's wrapping the generator in a bash script that pipes the result through AWK, etc.

Which is itself a generator

Re: Don't be clever

#112

Post by dmoy »

pphysch wrote: post #101
dmoy wrote: post #99

Earlier quoted context omitted.

I think GP means "make a tiny change [after generation, outside of the generator, and persist that change independent of the generator code]", which is where all the demons are waiting Modifying the generator itself to do something different every time, and doing GP's stated "regenerate and throw away the old stuff" is in line

It's not modifying the generator. The generator may be a proprietary black box. It's wrapping the generator in a bash script that pipes the result through AWK, etc.

Sure, that's orthogonal. If you wrap the generator in your build system and still always regenerate, it's effectively the same. And also, I think, not what GP was talking about

Re: Don't be clever

#113

Post by sjducb »

lijok wrote: post #11

At a consulting gig I did, we were bootstrapping a brand new python engineering team for a new line of products. We chose the frameworks, set standards via decision records, wrote a template service that you would copy paste, and build on top. Cross cutting concerns were pulled out into a library that all of these services installed. Most things were standardized, all APIs felt like they were written by a single pers…

If you feel confident refactoring some code then you have been able to read and understand it easily. If you can read and understand it easily then it’s good code, leave it alone.

Re: Don't be clever

#114

Post by hgsgm »

jader201 wrote: post #97
fuzzy2 wrote: post #88

Earlier quoted context omitted.

This is sometimes also called scaffolding, which I think is a better term. Code generation often means (compile-time or otherwise) generation of code from something else (like .proto definitions). Code that is not supposed to be modified by the developer and will be overwritten automatically.

I've also seen "scaffolding" used to generate code that shouldn't be manually modified. E.g.: https://learn.microsoft.com/en-us/ef/core/managing-schemas/s...

That's someone who doesn't know what words mean.

When a building is built, the scaffolding isn't an immutable part of the final product.

Re: Don't be clever

#115

Post by ChrisMarshallNY »

As always, when making "one-size-fits-all" statements, my answer is "It depends."

In many cases, I use inheritance and polymorphism, as well as extension, to make my code incredibly adaptable. It's basically habit.

It is not always so easy to scrutinize (even by Yours Truly), but I document it well, and the structure can sometimes make tasks that might take days, take minutes (This has happened many times in the project I'm working on, now).

A couple of weeks ago, one of the team needed a fairly large change to the operation of one of my screens. I was pretty reluctant, because it was one of those "Just one little change" things that actually translates to a massive codebase hit.

However, when I reviewed the code (which I hadn't touched in a while), I found that I had left some fairly good hooks in the base class, so it actually took about five minutes to give them what they wanted.

Re: Don't be clever

#116

Post by sjducb »

BoxFour wrote: post #48

The issue at hand is not about cleverness. Code was devised to address a specific problem (DRY), which it did quite elegantly. Then, the situation evolved, rendering the solution inappropriate. When a controller starts to deviate from the standard approach, it's best to refrain from inheriting from the base controller and instead create custom ones. Once all controllers operate independently, the base class can be sa…

Experience will tell you that this happens often, and it’s often better not to DRY in the first place.

Re: Don't be clever

#117

Post by lopatin »

wallmountedtv wrote: post #34
jbandela1 wrote: post #15

> Yes, I had failed to see the proper solution: a class generator — so that I didn't have to manually copy code again No, please don't. This is jumping from the frying pan into the fire. If you think abstract base classes can be clever and hard to understand, code generators can be even more so. In addition, because code generators are a one way conversion, and the generated code evolves independently and the code ge…

As a blog post with the title "Don't be clever" ending up with the author's answer being an even clever-er solution, than talking about the hidden fight against complexity in software, was an odd ending note.

To me the most ironic part was calling CRUDController clever in the first place. There could have been clever solutions to reduce the code repetition, but using inheritance to force a naive abstraction on every future programmer isn't it.

Re: Don't be clever

#119

Post by xwowsersx »

CaptArmchair wrote: post #108
xwowsersx wrote: post #104

Not disagreeing with the core assertion in this post because I think the author is correct that you can absolutely over-engineer things. But one thing I don't quite understand. > Some controllers had to do some things a little differently. .... > And young me? I just kept going. Adding the proverbial knobs and pulls to my abstract class Aren't the ways in which the concrete implementations vary supposed to be in the…

I think the point of the author was that as a young - implied: inexperienced - developer he was blinded by the power of being able to describe the world in code; and inadvertently got stuck in the rabbit hole. Learning to take a step back and discern the best fitting abstractions that allow modeling the business domain is a learned skill. There's a difference between learning about object inheritance in school, and a…

For sure. I meant to say that was _one_ of the points the author was making. You're absolutely right about what the core sentiment/point of the post was.

Re: Don't be clever

#120

Post by OhMeadhbh »

jbandela1 wrote: post #15

> Yes, I had failed to see the proper solution: a class generator — so that I didn't have to manually copy code again No, please don't. This is jumping from the frying pan into the fire. If you think abstract base classes can be clever and hard to understand, code generators can be even more so. In addition, because code generators are a one way conversion, and the generated code evolves independently and the code ge…

What's wrong with macros? I use them every day. They're fine.
Post reply on HN