I haven’t read ahead yet — because “Spoilers!” (the Doctor Who fans know what I’m talking about) (I’m getting punchy because it’s late) but I bet all these foundations of JS are laying out the best ways to organize it, the patterns, as it were.
But even from the elementary text so far, I’m learning the why to some things I just knew the what of.
For example, I knew it was better to put opening brackets on the same line as a return statement
but I didn’t know why. Turns out JS using implied semicolons (it adds them in so you don’t have to!) can cause the return to just return undefined and execute, and just ignore the rest of your object.
Also, just because you can leave out brackets, if they only capture one line, doesn’t mean you shouldn. Because if you refactor your work, and now there are two lines, you have to worry about adding brackets. This is a meaningful point, esp. given what I’ve learned about refactoring, and it makes sense to not take shortcuts now and have to think mroe later.
Similar for comparing with === instead of ==. While there are some cases where you don’t need the third =, since you know exactly what the type of one side is, if you use == sometimes and === other times, you might be left guessing if == is being used intentionally or accidentally — best to just keep it consistent. That’s esp. important if others are reading our code.
A common thread in all of these books has been about how we spend more time rereading our code later when we come back to it, or how others have to “get into” it. i’ve long approached coding quite selfishly — I’ll deal with my poor practices later. But even Future Me gets upset with Past Me for what Past Me has done. I’m all about collaboration with others, and with future versions of myself (I’m really into the sci-fi metaphors tonight, but you see what I mean), so these standards will make that easier. And when others come back to your code, it’s often under pressure or stress, so we want to make things easier, not harder.
Anyway, these chapters reminded me of mostly things I know, but lended a nice “why” aspect to them. And as I start some new projects these days, they serve as a strong reminder to adhere to these ideas, and start out with the best practices in mind. To not just know what’s right, but do what’s right.
Thinking that way has helped me a lot with forays into Ruby lately, based on what I learned from the refactoring book. It’s changed my ability to communicate as a developer.
I’m beyond excited to keep that journey going with a language that feels a bit less like a new, tentative toy and more like an old friend. And yes, I’m aware I just called a programming language a friend. This is why I go out and away from the computer on the weekends.
More as we learn the next bit next week….