21–30 of 152 posts
You can think of booleans as a built-in, two-value enum that has a common semantic meaning. Use booleans if this is suitable for your purpose; it will be suitable for many. That said... this article feels like a bit of a strawman. Does anyone by default use three booleans in cases that are arechetypical enums?
Solution in C#: use named parameters: RaiseInvoice(taxInvoice: false, sendEmail: true)
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...
The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).
function foo({bar, baz}) { ... }
foo({bar: 1, baz: false})
Solution in C#: use named parameters: RaiseInvoice(taxInvoice: false, sendEmail: true)
var taxInvoice = false
var sendEmail = true
RaiseInvoice(taxInvoice, sendEmail)
Tangential but coding in JS/TS, I often will go for object arguments to make things more readable. If you have a function like: foo(arg1: boolean, arg2: boolean, arg3: boolean) Then when you call it it will look like foo(true, false, true) which is not great for readability. Instead I move all the arguments into an object which makes each field explicit. Ie. foo({ arg1: true, arg2: false, arg3: true }) This also carr…
The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).
function foo({x, y, z=1}) { ... }
const x = 1; // Usually a complex computation instead.
const y = 2 * x;
return foo({x, y});The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).
https://www.youtube.com/watch?v=_ahvzDzKdB0
It's one of the best programming talks I've come across. For 1998, all his points on growing a new programming language are spot on.
And then Java became the opposite of a lot of the goals he enumerated.
The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).
Named parameters are easy enough to mimic in JS using objects and the spread operation function foo({bar, baz}) { ... } foo({bar: 1, baz: false})
And correct me if I'm wrong, nothing worse than an incorrect pedant.
Tangential but coding in JS/TS, I often will go for object arguments to make things more readable. If you have a function like: foo(arg1: boolean, arg2: boolean, arg3: boolean) Then when you call it it will look like foo(true, false, true) which is not great for readability. Instead I move all the arguments into an object which makes each field explicit. Ie. foo({ arg1: true, arg2: false, arg3: true }) This also carr…
Using object arguments is a great start, and I think using enums can also be powerful (if you're using string literal types). But often times I reach for explicit interfaces in these situations. IE:
type FooScenario = { arg1: true; arg2: true; arg3: true };
type BarScenario = { arg1: false; arg2: true; arg3: false; }
type Scenario = FooScenario | BarScenario;
...etc
This provides semantic benefits in that it'll limit the input to the function (forcing callers to validate their input), and it also provides a scaffold to build useful, complete test cases.
Tangential but coding in JS/TS, I often will go for object arguments to make things more readable. If you have a function like: foo(arg1: boolean, arg2: boolean, arg3: boolean) Then when you call it it will look like foo(true, false, true) which is not great for readability. Instead I move all the arguments into an object which makes each field explicit. Ie. foo({ arg1: true, arg2: false, arg3: true }) This also carr…
You can actually set up VSCode and probably other editors to show the parameter names inline with the values.