Hacker News Reader

Comment by snarfy | Hacker News Reader

It never stays that way. It starts as

    foo(int x, do_bar_t)

With time, it turns into

    foo(int x, int y, do_bar_t)

and eventually

    foo(int x, int y, int z, int w, do_bar_t)

It's too tempting to add 'just one more' flag. You de-duplicate common functionality but increase overall complexity.

View on HN

Part of the job is to know when to call it quits and refactor, there's no hard rule. In most cases I'll take a 130 line procedure with three flags that don't heavily interact with each other over three almost-identical 100 line functions.

Porque No los Dos?

In languages with good support for functional features, you can curry and compose functions to your heart's content, allowing you to reuse similar logic and take better advantage of type systems like TypeScript's

It comes down to how deep the type system of a language support this kind of operation. It'll work well with TS, Rust, but it doesn't add much to golang, C++.

But well, usually dynamicizing statically-known types yields premature abstraction

I would actually call it "atomization" more than abstraction, but I agree it can often be premature

Put the flags into a class and pass the class around.

s/class/typed object/ -> "How to write Typescript"

Only, I don't use ints as "flags," so you're doing it wrong. And you're using the slippery slope fallacy, assuming that I'm a DRY absolutist. I'm not. Like I said, it's not always a good thing, and you can definitely overdo it.

The valid complaint about the implementation I show would be that the do_bar logic is at the very top with no preamble, and it may be simpler for the caller to simply call bar(x) in that case. But adding necessary-looking complexity would detract from the clarity of the implementation (and damn c++'s verbosity, it already looks like hot garbage IMHO)

> Only, I don't use ints as "flags," so you're doing it wrong. And you're using the slippery slope fallacy, assuming that I'm a DRY absolutist. I'm not.

You might not "use ints as flags" but a lot of maintenance programmers who know nothing about your idea, have never seen the code before, don't know how the application works or even what it does, will do just that.

What you're describing is multiple policy failures. Why are these "maintenance programmers" implementing novel features? Why are they novices that are unfamiliar with the language and its best practices? Why are these novice-rogue-developer-maintainers' contributions not being reviewed by more competent developers?

Moreover, if these unrestricted-novice-rogue-developer-maintainer-rhinoceri are going to do whatever the hell they feel like, completely disregarding the patterns and practices that I have established in my code, does it matter what I have done?

Because novice programmers are cheaper and businesses make decisions based on short term cost. Especially when projects get old.

I know all that. But you didn't address my point: if management has thrown all good practices to the wind, how am I to blame for the horrendous outcomes?

This is a tangent, but I’ve never seen the real world work this way. You’re being paid to be the DRI for the code base. You will be blamed because you’re being paid for it to be your responsibility. Actually horrendous outcomes, which can only be related to breaking functionality rather than code prettiness, can be prevented.

I'm not blaming you I'm saying most of the time management will pick the cheapest option. That leads to bad outcomes for a lot of legacy software. That then leads to someone spending more money replacing the legacy system

Quit jobs where management is that bad.

And the issue with too many behavioural flags is that now the function (and the implementor) has to deal to all possible combinations, even though by specs only a small subset would be allowed.

Reply on news.ycombinator.com