« « An introduction to design patterns — trying again

Learning…how to think ahead about big-picture coding problems » »

JavaScript Patterns – Chapters 1 and 2

Posted by on Jul 23, 2014 in Blog | No Comments

I certainly love stretching my mind and learning new things, but after weeks of reading Ruby and more strictly-typed languages, I breathe a sigh of relief every time I step back into JavaScript world. Some people like it, some people hate it, but for me, it’s just where I spend the most coding time, and where I feel the most, well, at home.

The first two chapters of JavaScript patterns was this week’s reading of the week, and it’s a testament to how far I’ve come, that the majority of the concepts are either things I already do, or more likely, things I know I should do. It’s also a reminder that as far as I have to go, I’ve also come quite far already, and should take some small pleasure in what I know now that I didn’t a year ago, nor when I joined the AP three years ago, nor when I started this journey five years ago.

These chapters mostly go over basic precepts of JavaScript. Now, that doesn’t mean basic precepts of programming. The authors make this distinction clear. To be precise, you won’t learn what a loop is here, but you will learn how the nuances of how you create this loop affects proper JavaScript style and performance.

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
return {
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….

« « An introduction to design patterns — trying again

Learning…how to think ahead about big-picture coding problems » »