You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Deciding on a Style Guide

Recently a couple of groups here at work were brought together to try and standardize on a few things. The Software Development Community of Practice! Style guides came up. Everyone said they had no style guide and everyone agreed having a style guide would be worthwhile.

I had spent some time writing a style guide (customizing) so I was interested by this. I got to reflect on my style guide, how I’ve referred back to it in the year since I put it out there, and how I think it has helped or could help in this forum.

See the reason I created this style guide is not all that different from the reason these communities of practice are looking to create style guides. I was/am writing open source, and on the hope that someone will want to contribute to the project, I want a rule set defined so people won’t submit something unreadable.

For the community of practice, it’s a little different, but the spirit is the same. What they want is to have the option to point at something when a fellow developer is writing horrible code. The premise is you have a new developer and they don’t know how to write clean code.

The problem I have with this is everyone knows how to write clean code. And by everyone, I mean every professional software developer. If they’re not writing clean code, they’re not professional. Now that of course means if we are using student employees or taking in work from unknown outsiders (Open Source), that we are risking poorly written code being introduced and should therefore have a style guide. But if the premise is to have something for professional developers, I think it’s a waste of time.

Most style guides are 95% the same and we’re not talking about trying to enforce the 5% that is going to be different between individual developers. If ever a problem comes up with software developers where one is trying to say another’s code style is wrong, they should be able to say “google a style guide to see what best practices are” and be done with it.

Sadly, I’ve wasted more time arguing this than it would have taken to just agree, pick a guide that no one will ever use and move on.

Posted in Development, Open Source. Tags: , , . Comments Off on Deciding on a Style Guide »

Writing a Style Guide

I took a look at the style guides of all of the most popular frameworks.

Yii Style Guide
Codeigniter Style Guide
Zend Style Guide
Symfony Style Guide
CakePHP Style Guide

Yii is the simplest. They just tell you what should go in the Model, Controller and View. I actually believe that’s the best thing when thinking of a framework as a framework, since a framework shouldn’t be telling you how to write your code, and you should never be mixing your code within the framework. A framework is a tool, but it should be on the primary developer to decide on the style that’s right for them and their team. However, I do understand that most of these style guides are talking about their framework as a project, which of course it is

There are a lot of topics to consider in a style guide. A lot of things popped up as I looked at the different style guides that I hadn’t even considered.

File Names
Class Names
Method Names
Method Definition
Class and File Names Using Common Words
Database Table Names
Constants
Variable Names
Member Visibility (Private / Protected)
Indentation
Commenting
Control Structures
The PHP Tag
Comparing Return Values and Typecasting
Logical Operators
Debugging Code
PHP Errors
Whitespace
Linebreaks
Compatibility
One File per Class
Bracket and Parenthetic Spacing
Localized Text
One Statement per Line
Strings (When to use Single or Double quotes)
SQL Queries
Default Function Arguments
Associative Arrays
Unit Tests

Some of the style guides got so long I kind of got angry. Trying to enforce things like whitespace, logical operators or indentation is foolish. It’s just too much and it takes away from the things that are actually important.

So what’s actually important?

What’s important is what people are going to read. Nobody wants to read through a 30 page style guide, and they won’t. The best solution I’ve found is to have 2 style guides. The first, important style guide is to outline the very essential rules you want for your project. Try to keep it short enough to fit on one page so someone may actually read the whole thing. Then, if you choose, you can have a nitty gritty style guide that outlines how you want your variables named and if you’re an indent nazi. You can always refer back to the nitty gritty if someone is submitting code that you find repugnant.

My style guide for Quizmo
My nitty-gritty style guide for Quizmo

Posted in ATG, PHP. Tags: , , , , , , , . Comments Off on Writing a Style Guide »