I mean if I were to change that option string generator, I could make a numeric for loop from 1 to 12, left-pad a zero for the value, and lookup the month label from a label array or create a Date object and use its formatting options to output the label. I loop over an array of objects with a value and label. With ES6 I could do that with a .map() operation.
It's inelegant but it does what it says on the tin. Can't have an off-by-one error if you don't use loops or indices.
- Why not check the length of the string before the switch? - Why return a string which is (meant to be) identical to a variable? - Why not set the regex into a variable and then only have one if-block?
"Don't repeat yourself" is a very good rule for many very good reasons, but a big one is that you don't have to change 10* different places to change 1 thing, which gets rid of a whole class of extremely common bugs. Also, it makes it much more obvious what the code is doing, since your brain only needs to parse 10 different one-line assignments instead of 10 different six-line blocks.
* Replace "10" with whatever the actual number is.
The function is formatted and it does what it suppose to do. It can be refactored to make it less code.
I'm not entirely sure how you came to that conclusion. Lookup tables and format strings have been around for... well, I'd guess almost a century.
https://en.wikipedia.org/wiki/File:Forgotten_edits_in_copypa...
Duplication is never pretty, but when it's as local as here, it's pretty much harmless. Duplication that's not obviously duplication, that's a problem. This is not that.
To answer your question, in 3 places, a few lines apart from one another.
Duplication displays exponential growth.
There's a lot to be said for boring, easy to understand code.
I have seen modern JavaScript that can be just as bad as this.
At least it's not a minified blob built up from dozens of repos whose primary purpose is to make its authors look (feel) productive/prolific.
Now I just want to figure out all of the food analogies for bad code patterns...
I used to call it "Spaghetti Code". But I recently learned that it's incorrect. "Spaghetti Code" only refers to programs with messy and unclear control flows (especially unstructured programs that abuse goto), it's not the correct term for code with useless repetitions.