Basic Coding Standards and Guidelines

Naming conventions in coding are important for maintainability and quality.

Without a standard to follow, each developer (and sometimes each file) will take on a standard of its own (or be just a random mash of whatever).

Deciding on a standard as a group is tougher than it sounds. Discussing standards leads to holy wars. Whenever there are two ways to do something, invariably the rebellious ones will pick the opposite of what the established group prefers.

Here is what makes the most sense to me if I were to start from scratch on a project:

Camel Case (aka medial capitals):

Used for variables and method names:
public function getLogin() { … }
private String loginId;
private String lastSearchTerm;


Upper Camel Case (aka PascalCase):

Used for class names.
public class MyObjectRules
public class SquirrelNutZippers



Underscores are great for long variable names, table names, field names:
var logins_in_group_count = 10;

Underscores are especially good in constants:
public static final int MAXIMUM_LIMIT = 42; //java
define(“MAXIMUM_LIMIT“, 42); // php


Other Symbols:

Hyphens, and other symbols are rarely used in most modern languages these days. Avoid getting fancy with special characters.


Standard Indentation and Formatting:

Standard rules for indentation, code formatting, comments, and white space is important. Editors like IntelliJ and Eclipse can do a lot of this automatically. Pick a standard that makes sense, looks good, and go with it. Older standard are too aggressive about line length and end up doing a lot of ugly wrapping. Most developers today are either on wide screen laptops, or have dual monitors. Given new technology and tools, a line length closer to 160 is more reasonable.

If you employ an automated build (which you should on a large project), there are tools that can scan for deviations from your configured standard (see Sonar).


Private Class Variables:

Decorating member variables (eg private class variables) with a m, or an _, is something I used to do, but no longer do unless coding to a standard that requires it. These decorators become ‘warts’ in code. Modern IDE’s make it easy to track down variables. Why add cruft?


Delineating the type of the variable in its name:

In the old days, there was no auto completion or tool tips, so it was very helpful to encode the variable type in its name. For example:

int iCount;
String sName;

With modern tools, this is crufty and needless. Revised:
int count;
String name;

Much cleaner.


Case Conventions when Naming Database Objects

When it comes to naming database tables and fields, consistent naming conventions are important. When done right it makes life easier later. There are several layers to consider: RDBMS explorer tools, SQL queries, and Object Relational mapping tools/frameworks.

A data model has many users (backend coders, application coders, ETL tools, etc). This is not to say they all couldn’t be loosely coupled and do their own thing. The point is, going with something sensible to start with can save everybody time.


Database Objects:

Different RDBMS navigation tools like pgAdminIII, MySQL Work Bench, HeidiSQL, SequelPro, DB Visualizer, MSSQL Management Studio… all have their own take on how to represent the list of tables and columns in a database. Some preserve case, others send everything to lower case (this might be a configuration option, like in MySQL, or it might be your GUI tool trying to be helpful). For this reason, camel case isn’t always a good answer. Using underscores to separate words and naming tables and columns in lower case has been a good fit for me. This avoids debate about how to name a field like login_id, it could be named as any one of the following {Login_Id, Login_ID, loginid, LoginId, loginId, loginID}.

For example, here is a simple schema with three entities: Logins, Groups, and many to many between Logins and Groups, named based on the underscore convention: int
login.user_name varchar(250) int varchar(250) int
group_login.group_id int
group_login.login_id int

Without underscores as a visual break, some tools display listings like grouplogin.groupid, which is a harder for the eye to parse.


SQL Conventions:

I prefer to capitalize all the SQL keywords, like CREATE, ALTER, SELECT, WHERE, and use the underscore notation for columns and fields.

SELECT * FROM login WHERE user_name LIKE ‘john%’;



OR Mapping Layers:

If you are using a framework like Django, Hibernate, Symfony, etc that is capable of scanning the database schema and generating objects based off column names, take care to align your field names with the behavior of the framework so getters and setters come out readable.


Closing Thoughts:

I’m not going to talk about where to put the curly braces. What I do believe in is consistency. If the code base is inconsistent, then they are in the wrong place!

This entry was posted in Code, For New Developers and tagged . Bookmark the permalink.

Comments are closed.