Developing Code Standards for Teams

Sep 15, 2015

“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!

 

RECENT POSTS

The Agile Manifesto in Practice: Part 1

The Agile Manifesto in Practice: Part 1

  How Sourcetoad Values People Over Process The software development process can involve a lot of uncertainty for both development teams and clients alike, especially in the early phases of a project. How can the long-term vision of an application be balanced...

What to Consider When Building HIPAA-Compliant Software

What to Consider When Building HIPAA-Compliant Software

In 1999, the Department of Health and Human Services (HHS) passed the Health Insurance Portability and Accountability Act (HIPAA) as a measure to protect personal health information (PHI) and allow people control of their healthcare records. The HITECH Act was enacted...

The Evolution of Buy Now, Pay Later in eCommerce: Part 2

The Evolution of Buy Now, Pay Later in eCommerce: Part 2

In Part 1, we talked about the rapid growth of Buy Now, Pay Later (BNPL) and discussed its expansion across industries. In Part 2, we will consider how impending regulation may shake up the short-term lending space.   Impending Regulation of BNPL While consumers...