Store the associated labels in "k": k=['Underweight','Normal','Overweight']
Find the first BMI step which is greater than the provided BMI: t.find(v=>w/(h^2)<=v). For example, it will return 25 if the processed BMI is between 18.5 and 25.
Find the associated array index: t.indexOf(...), in order to get the same element in the label array: k[...]. For example, if 25 is returned, it will fetch k[1], hence "Normal"
Finally, if no label is found (hence, if the BMI is greater than 30), return "Obese"
That is an interested method, but come back at your code in a few months with absolutely no explanation and I do think that it is not going to be that easy.
I think that a code should be self explanatory (especially to newcomers on your codebase) and, even if this one is a tour-de-force in terms of one-liner, it is not self explanatory. 😉
That is why, I would find that a switch case method would be better.
I completely agree with you on this one! (Hi fellow french dev!) I tend to try to golf a lot in these challenges, even though I completely agree on the fact that it's as ugly as it can be. That way, I can discover new principles (like the reduce method, that I hated a few months back even if it is really useful) that I can later use on my projects or at work.
Indeed, this challenge was clearly made for a switch/case solution, but as I had some free time I though I could try something different haha
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well, I tried something different:
Apart from being ugly, it works like this:
t=[18.5,25,30]
k=['Underweight','Normal','Overweight']
t.find(v=>w/(h^2)<=v)
. For example, it will return25
if the processed BMI is between 18.5 and 25.t.indexOf(...)
, in order to get the same element in the label array:k[...]
. For example, if25
is returned, it will fetchk[1]
, hence"Normal"
"Obese"
I like it!
That is an interested method, but come back at your code in a few months with absolutely no explanation and I do think that it is not going to be that easy.
I think that a code should be self explanatory (especially to newcomers on your codebase) and, even if this one is a tour-de-force in terms of one-liner, it is not self explanatory. 😉
That is why, I would find that a switch case method would be better.
I completely agree with you on this one! (Hi fellow french dev!) I tend to try to golf a lot in these challenges, even though I completely agree on the fact that it's as ugly as it can be. That way, I can discover new principles (like the
reduce
method, that I hated a few months back even if it is really useful) that I can later use on my projects or at work.Indeed, this challenge was clearly made for a switch/case solution, but as I had some free time I though I could try something different haha