function getMonthName(monthNumber) {
const date = new Date();
date.setMonth(monthNumber - 1);
return date.toLocaleString([], { month: 'long' });
}
The rake has nothing to do with JS (which I agree is cursed, but for its own reasons, not this).
You have called a function in a way that does not give a consistent value (Date()). Such functions are hardly the preserve of JavaScript. You’ve failed to adequately deal with the range of values produced, with code that tries to insist that the “31st February” can be a meaningful date in February. You should accept that this is your mistake and learn to (better) avoid side effects where possible.
Also, the function isn’t side effecty since it doesn’t make implicit references outside its scope.
Edit responding to your edit:
Also, the function isn’t side effecty since it doesn’t make implicit references outside its scope.
The Date() function’s output varies according to something other than its input (and even the rest of your program). Using its output without accounting for that variation means that your function, as originally written, also gives inconsistent return values, varying according to something other than its input, because it does, in fact, reference something outside the function. If it did not, the results would only depend on the monthNumber argument, and would always be consistent. I don’t know what you call that, but I view it as a side effect.
As you have said, the rake is that months have different lengths, and you need to account for that. But that’s not one of JavaScript’s many issues.
The idea is to get the current data that will have the current year, month, day in it, and then to query this date for the previous month. A sane API would just throw an error when the date is out of range. A Js API will quitely give you nonsense instead. Again, side effects have absolutely nothing to do with anything here.
You’ve replied while I was editing, so see that regarding what I mean by side effects.
As far as throwing an error when you try to create “31st February”, this wouldn’t actually help much, since the error would still only occur on some days of the year, because your original code doesn’t account for the range of outputs from Date() when called without arguments.
To perform correctly, your code needs to normalise the day of the month, or just create the date more explicitly to begin with, but this is a calendrical issue, not a JavaScript one.
Side effects are when your function has a reference to some state outside its scope and modifies that state. A function that produces different outputs when it’s called, such as getting a current time is not an example of a side effect. Again, the issue here is that Js tries to infer what to do with a bad input, a number outside acceptable range, instead of simply rejecting it.
My point isn’t that you can’t write a better function that’s less error prone, but the fact that Js allows such things to happen in the first place. It’s a very easily avoidable problem at the API level.
