5 ms·

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

• mycall 4y ago
  Put the flags into a class and pass the class around.
  • 0xCMP 4y ago
    s/class/typed object/ -> "How to write Typescript"
• klyrs 4y ago
  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)
  • kwhitefoot 4y ago
    > 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.
    • klyrs 4y ago
      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?
      • xupybd 4y ago
        Because novice programmers are cheaper and businesses make decisions based on short term cost. Especially when projects get old.
        • klyrs 4y ago
          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?
          • nomel 4y ago
            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.
            • deleted 4y ago
              [deleted]
          • xupybd 4y ago
            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
• mixedCase 4y ago
  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.
  • culi 4y ago
    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
    • valand 4y ago
      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
      • culi 4y ago
        I would actually call it "atomization" more than abstraction, but I agree it can often be premature
• gpderetta 4y ago
  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.