3 ms·
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: boolea
by _fat_santa 2y ago
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 carries the advantage that you can quickly add/remove arguments without going through an arduous refactor.
- ervine 2y agoBig time.
- presentation 2y agoYou can actually set up VSCode and probably other editors to show the parameter names inline with the values.
- nine_k 2y agoSame for JetBrains IDEs.
- someoneontenet 2y agoHow is this done for js?
- thamer 2y agoAs far as I know it is not a native feature, but inline hints for parameter names can be added with a VSCode extension called "Inline Parameters for VSCode": https://marketplace.visualstudio.com/items?itemName=liamhammett.inline-parameters https://marketplace.visualstudio.com/items?itemName=liamhamm... The only languages it supports are JavaScript, TypeScript, PHP, and Lua. I can confirm that it works for JavaScript and TypeScript, I haven't tried the other two. A similar extension named "Inline Parameters Extended for VSCode" supports a different set of languages: Golang, Java, Lua, PHP, and Python. It seems to be a fork of the aforementioned.
- xigoi 2y agoI hate inlay hints because they usually add unnecessary clutter. I prefer to use languages that allow you to add them manually when needed.
- mjlawson 2y agoOne of the things that's often not considered with these kind of interfaces, is whether or not they're actually possible. For instance, arg3 might only be true if arg1 is also true. Or arg3 may not be false if both arg1 and arg2 are also false. 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.
- fernandotakai 2y agoyou can force named arguments in python by using * after any non-named args. example: In [1]: def my_func(first, *, second, third): ...: print(first, second, third) ...: In [2]: my_func(1, second=2, third=3) 1 2 3 In [3]: my_func(1, 2, 3) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) Cell In[3], line 1 ----> 1 my_func(1, 2, 3) TypeError: my_func() takes 1 positional argument but 3 were given In [4]: def my_func_2(*, first, second, third): ...: print(first, second, third) ...: In [5]: my_func_2(first=1, second=2, third=3) 1 2 3 In [6]: my_func_2(1, second=2, third=3) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) Cell In[6], line 1 ----> 1 my_func_2(1, second=2, third=3) TypeError: my_func_2() takes 0 positional arguments but 1 positional argument (and 2 keyword-only arguments) were given