[kierenj]

Solution in C#: use named parameters: RaiseInvoice(taxInvoice: false, sendEmail: true)

[edflsafoiewq]

If you don't have named parameters, you can fall back to variables

  var taxInvoice = false
  var sendEmail = true
  RaiseInvoice(taxInvoice, sendEmail)

It's obvious, but people tend not to do it.

[wrs]

Sadly there is nothing that can tell you that you got those arguments backwards.

[gary_0]

Which is far more realistic than defining single-use enums all over the place.

I don't know why more languages don't have named parameters...

[kerkeslager]

Why is defining an enum "unrealistic"? It's at most 4 lines of very simple code to define an enum that replaces a boolean.

[kerkeslager]

That doesn't fix readability (is the invoice being raised not a tax invoice? Or are we not taxing the invoice being raised?).

That doesn't fix the possibility of adding a third possibility either (what if we separate non-tax invoices into two types of invoices?).

RaiseInvoice(InvoiceType::Tax, Notifications::Email);

[keithnz]

no, way better to make an options object then set the options you want, also works a lot better later when you want more options.

[HumblyTossed]

Way better use a bit pattern.

[worble]

You can't force the caller into using named parameters though. So when it's late at night, you're tired but also think you know better, there's nothing stopping you from doing RaiseInvoice(true, false) when you actually meant the inverse.