Early Returns
It was my very first code review. Three years of college had led up to this moment: my internship mentor would tell me his thoughts about my code. It would be the very first time a professional would judge what I had written. Sure, it might seem like a small thing not even worth mentioning in hindsight, but it felt big back then.
I was confident. I had considered every pattern and principle I had learned in class. I had taken care of code formatting, just like I had to do when writing code with pen and paper during my three-year study in college. There were more comments than code to explain my reasoning, making sure there was no room for confusion.
I started the assignment two days ago, and my mentor had deliberately given me freedom to code without looking over my shoulder. I was building a Google Analytics dashboard — an API integration, basically — for a custom-built CMS. Any of their websites would soon pull in the most relevant data from Google Analytics and display custom rendered graphs on the CMS' dashboard. It was a pretty high-impact feature, and I was honored to work on it.
I was far from done, of course, but the base layer was ready. My code could now synchronize the necessary data between the Google Analytics API and the project's database; the part that my mentor would be reviewing today.
"You know," he said, "I noticed something. Do you only write one return statement in a function?"
"Erm, yes," I replied, a bit surprised this was the thing he mentioned. "I learned you should only ever write one return statement per function to keep it clean," I continued, trying to defend my coding style.
"Yeah," he sighed, "you know, don't pay too much attention to what they tell you in school. That "one return statement rule" is so outdated and no one really follows it anymore. The rest seems good, carry on!"
And that was it, the code review was done. I have to admit, I was kind of taken aback; this was not how I expected it to go. I also didn't know whether I agreed with my mentor or not. I think I personally liked having only one return statement per function. Early returns seemed… ugly to me, in a way; but I couldn't really tell you why exactly.
Nevertheless, I went back to my desk without complaining and got to refactoring my functions to use early returns instead.
That's how I got confronted with one of the few certainties any programmer will really ever have: differences in code style opinions.
Naturally, there is a lot to say about early returns versus one return statement per function. You might even have thoughts about it right now. However, this book won't teach you the definitive answer to that question. Neither will it give any answer to any programming question you might have.
This book isn't about patterns, principles, or best practices; in fact, there's barely any code in it. It's about the many things I've learned along the way being a professional programmer, and about the many, many mistakes I made along that way as well.
It's what I wish someone would have told me years ago, and I hope it might inspire you.
How to read this book
This book is written as a story: my advice would be to sit down somewhere comfortably and read it through. Because it's a story, it's important that you read it chronologically without skipping chapters or jumping around.
It isn't just meant to be a past-time read, though. This book's goal is to make you think and reflect on your own programmer's journey. If you're reading the paperback version, you'll find one or two note-taking pages at the end of each chapter. These are meant for your own story. You could choose to read through the book once without taking notes and then go through a second time to write down your reflections; or do it all at once — up to you!
Yes, I hereby give you permission to scribble in a book.
If you're reading a digital version, my recommendation would be to have a note-taking app or paper at hand. My personal preference is to use pen and paper, but you choose what works best for you.
Enjoy!