It can be a struggle to answer this age-old question. It’s arguable that some very successful products weren’t originally concerned about quality and have become massive hits (see Facebook). And if it worked for them, then why can’t it work for everyone?
I was lucky enough to get an advanced copy of John Sonmez’s latest book project The Complete Software Developer’s Career Guide — even though this post is a month after the public release. This book will come as no surprise for anyone who follows John since he’s been publishing every chapter as he writes it on his blog at Simple Programmer.
The book’s goal is to provide any aspiring or established software developer with the advice and resources needed to make informed decisions throughout their career. It can accompany you from your first day working as a developer to your last.
Speak to any developer and they will tell you that code quality is important to them. Every developer’s definition of quality code will be affected by their experience, background and education, making it impossible to pinpoint a single definition. Defining code quality, then, is not an easy task.
There’s a huge collection of books, blogs and StackOverflow threads discussing code quality. Out of all those references, there’s 11 common code quality traits that stick out. But those traits are broad, and it’s often unclear how to put them into practice. For that reason, every trait in this article has a list of suggested best practices to get the most out of it in any project.
GitHub is becoming the one-stop shop for developers looking to work on open-source and private projects. In an effort to improve its foothold within the developer community, the company has recently improved its code review functionality and launched a marketplace for 3rd party developers to integrate with GitHub. This makes it a good time to look at how to make the GitHub experience more amenable to code review.