Not wrong, but funnily enough, it’s a linting rule win. I’d go nuts if I didn’t have my type checks and my linters. My current L, though, is setting up the projects initially and dealing with the configuration files if I raw dog it, but that’s a problem with ESLint configs and the ecosystem as a whole having to deal with those headaches. So in the end, the JS devs got clever and shifted the blame to the tooling. 😅
Lemminary
Compulsive comment editor, all in good faith.
#Sorry not sorry for the edit
- 0 Posts
- 6 Comments
Joined 2 years ago
Cake day: August 13th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Lemminary@lemmy.worldto Programmer Humor@programming.dev•Been there, done that, would not recommend2·16 hours agoThere are dozens of us! But also, I have a masochistic tendency to update my old code to use the new language features and make it somewhat readable.
Same here. My brain interprets them as one long run-on sentence and throws a parsing error.
Explanation for nerds
The reason is the JS compiler removes whitespace and introduces semicolons only “where necessary”.
So writing
function myFn() { return true; }
Is not the same as
function myFn() { return true; }
Because the compiler will see that and make it:
function myFn() { return; true; }
You big ol’ nerd. Tee-hee.
That’s TypeScript. I can tell by the pixels defining a type above.
😬