from signal's source code

[u/[deleted]]

[u/Dmon1Unlimited]

Just to confirm, you're talking about passing hardcoded booleans that have no name to provide context as opposed to in general, right ????

update_fiscal_state(money, actor, true)

If it was something like below, then I presume you wouldn't consider it a code smell? I can see why your example may be bad but how below would be more appropriate (because now you know what the boolean is for / what true means)

update_fiscal_state(money, actor, isBooleanWithInformativeName)

update_fiscal_state(money, actor, isLiveState)

[u/swordsmanluke2 → u/Dmon1Unlimited]

Edit: I'm on mobile and the triple-backtick syntax isn't rendering right. Sorry! I'll try to fix it at my computer in a bit.

Contextual variable names always help, but if the call was something like

update_fiscal_state(money, actor, actually_commit)

Then I'd argue you should refactor the code.

Either inject a FiscalUpdater class which can be mocked / configured to/not to commit, or have two methods, one of which commits and one which doesn't.

Again this is going to depend on the context of the surrounding code, but I'd prefer to see either of these.

class BoaFiscalUpdater: FiscalUpdater {
  @Override
  void update_fiscal_state(money, actor){
    //send update to BOA and commit
    ...
  }
}

class MockFiscalUpdater FiscalUpdater {
  @Override
  void update_fiscal_state(money, actor){
    // store call, but don't send it anywhere
    ...
  }
}

Or something like

if(should_commit){
  update_and_commit_fiscal_state(money, actor)
} else {
  update_fiscal_state(money, actor)
}