Software Standardization

Why Standardize Software Styles?

As a mechatronics firm, we write a great deal of software. When handing software over to clients it is important that there is a certain look and feel that is consistent with Pocobor’s standards. One reason for this is that if code is standardized internally it makes it easier for co-workers performing code reviews, because they are used to seeing that style (since it’s the same style they write in!).

Another reason is marketing. A basic assumption is that any code that leaves Pocobor will be robust, dependable, and easy to follow. Having the same style allows clients to become comfortable with Pocobor’s brand of coding. But if our style changes from project to project (or within one project depending on which one of us wrote it) then our clients will not be able to recognize Pocobor code. Furthermore, they would have to get used to a new style for every project.

Why Would it be Easier to Read Standardized Code?

The main reason it’s easier to read code written in the same style is because of consistent naming conventions, function structure, and other stylistic aspects. So, when you see a variable named “EmployeePtr” you know a) that it is a global variable because its first letter is capitalized and b) it’s a pointer because all pointers in your particular style has “Ptr” at the end of the variable name. There are other ways to do this, for instance there could be a software convention where the same variable would be “pEmployee_g” (just an example). In this case the “p” proceeding “Employee” indicates a pointer variable and “g” indicates a global variable. The point here is that if everyone in your firm/lab uses the same style it will be much easier to read one another’s code.

How Do I Standardize My Firm’s/Lab’s Code?

Creating a standard programming style is challenging because everyone develops their own styles and habits through professors they had at college, blogs they read, and just from programming for years upon years. Initially, we thought we would sit down and create a programming style guide from scratch. We immediately realized how foolish that would be because there are already a lot of very good style guides created by experienced programmers.

After much googling and reading opinion upon opinion of what constitutes good programming style, we ultimately decided to go with Linus Torvald’sLinux Kernal C Coding Style“.  If your are not familiar with him, he is the person who initiated the development of the Linux Kernel and now acts as the project’s coordinator.

There are other style guides out there, but we liked and chose this one. The most important thing is to standardize your code style (using an established style guide), not the specifics of the style guide you choose.

What About Concepts not Covered in the Style Guide?

Often, one guide may not be enough to cover every aspect of code. You can fill in the blanks yourself or you can find other documents that discuss issues such as file templates or variable naming styles like camel case (e.g. “employeeName” vs. “employee_name”, where the first is an example of camel case naming convention). Ultimately, the goal for us was to find a style that we thought would produce the best code, and then to make sure we all use it.

Be Sociable, Share!