“Write a blog post” they said, “It will be fun.” Okay, then, let’s talk about code standards.
This is something we’ve been discussing internally for quite some time; writing up a set of standards that we could use as a company to keep our code consistent and our sanity intact. Essentially, this is a document that allows us to open up anyone’s project and at least be able to read the code. Whether or not it’s logically laid out or even works is another story and outside the scope of this blog. We are, however, constantly reiterating these standards and will continue to update the actual document as we refine our views.
For those of you who may not be programmers yourself, I’m sure you remember writing standards from college; how exactly are you supposed to format that bibliography again? Well code is very similar, in that it probably doesn’t matter too much (heresy) how you format your code, and if you spell your variable names in camelCase or lowercase, but rather how easy it is for someone else to be able to read and interpret your code.
There are a lot of standards out there for things like this already. And because we write a lot of backend PHP code here at Sourcetoad, we like to use the PSR—or the “PHP Standards Recommendation”—to help our developers stay on speaking terms. However, the PSR doesn’t cover everything, and stylistically it doesn’t cover much at all.
Programmers are opinionated people by nature, it’s inherent to our profession. If your job was to solve hundreds of small logical problems every day, you too would need a mental framework to do so. This sort of work environment breeds opinions like a rabbit farm dosed with Viagra. As you can imagine, the small differences in those opinions can lead to disagreements, arguments, and even desktop sabotage. So! We sat everyone around the table and stated to talk. What I’ve done is draw up the first set of Sourcetoad’s own code standards. Their intention is to fill in the gaps in the PSR, and take stance on some the opinionated stuff.
We’ve decided to publish these because we think that they might be useful for other developers out there as well. These decisions won’t be right for everyone; they’re largely based on our own opinions, compromises, and are heavily influenced by Yii and Yii 2 (both of which are still heavily in use over here). However, this might make a nice chopping block for you to go off of, and to begin building your own opinionated standards to help alleviate programmer wars in your own house.
Please note that this is a living document and will continue to evolve as lunches run long and arguments persist…. So, for like, ever.
Here’s the link.
Enjoy!
