Skip to content

Instantly share code, notes, and snippets.

@eddieh eddieh/style.adoc
Created Mar 31, 2016

What would you like to do?
Universal Code Style

Universal Code Style

There are three important principles related to coding style. All three principals should be followed.

First, follow the base guidlines for whatever language you happen to be working in. Usually this means you try to make your code look like the example code you’ve seen or the code from that open source project you forked. But when in doubt, google the language’s coding standards. When working on code at work or in any kind of group follow the preferred style guide. If there isn’t a style guide in place, you have some work to do. A languages standard library is your best resource if you can’t otherwise find or decide on a style.

So if you’re programming in JavaScript, Java, or Objective-C that means objects are in Pascal Case ( and methods are in Camel Case (


If you’re programming in Python, Ruby, or C++ you should use Pascal Case for objects and Snake Case ( for method names.


If you’re using Lisp or Scheme then you should use Kebab Case (


Secondly, defer to how English is written or to how Mathematics is written. That is if you’re deciding on where to place commas then defer to how you would place them in written English. Thus, the comma follows words as (one, two, three). Likewise if you’re deciding on how to space things in a mathematical expression pick up any math book and look at how it is done. Thus, most operators have space around them so (a = x + 10).

The third most important piece "In my opinion having, a standard is more important than having a particular standard" --AlexVanDenBergh

The Word According to Linus

Just as Linus Torvalds has suggested [kernel] print out a copy of the GNU coding standards and burn them! Don’t follow that nonsense unless you’re contributing to Emacs or something.

Maximum Line Length

Limit all lines to a maximum of 79 characters. No exceptions!

Rationale: You can now have 3 or more seperate windows open side by side. Trust me this will boost your productivity.

This makes diffing code easier.

Consider the code below:

def __init__(self, handler_spec, input_reader_spec, params, shard_count, output_writer_spec=None):

If one of the arguments change the then whole line is changed. It is difficult to spot the specific change too:

def __init__(self, handler_spec, input_reader_spec, param, shard_count, output_writer_spec=None):

Now consider the same code written my way:

def __init__(self,

The positives for this are so numerous that the conter argument about modern screen sizes is laughable. You should use your screen realestate for things like showing code side-by-side or having documentation open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.