Programming With Style

A lot of people refer to the combination of whitespace style, brace style, and capitalization style as "coding style", but I personally hate making a verb out of the word "code", so that's the first and last instance of that word you'll see on this blog.

There are a lot of different styles, and for the most part, to each their own.  Mine should more or less already be clear from the number of programming-related posts I've posted here, but just to be specific, I'll go through the languages I use on any kind of a regular basis and explain myself.  Here's a hint: I don't subscribe to any of the styles listed on this page, but I do use elements of many of them.

General things that apply to all languages:

• I prefer underscores instead of camelCase (regardless of lowerCamelCase or UpperCamelCase).
• I also tend to put a space before and after comment syntax.
• I tend to use single-quoted strings most of the time, and only use double-quoted strings when absolutely necessary (for instance, in PHP, using a C-style escape sequence requires a double-quoted string).  This is for performance reasons in scripting languages that apply extra processing to double-quoted strings.
• I don't subscribe to any variable naming conventions.  I personally like writing code that's very close to readable English, and embedding the type name in the variable name gets in the way of that.
• I tend to avoid one-liners when possible, but I will chain object references and array indexing all over the place in JavaScript and PowerShell.
• I overuse parentheses and force my desired order of operations at all times.
• I hate languages that have no elseif keyword.  I will do else if, but it always looks wrong to me.

Language-specific things, perhaps even with examples when I can't quite put what I'm trying to say into words any other way:

HTML/XHTML

NO INDENTING LOL

Seriously, I never indent HTML.  I did, initially, when I first learned it, when I was 11.  As I did more and more stuff with HTML I realized that there are too many corner cases where spacing at the beginning of a line actually matters.  I also only ever write XHTML anymore, but use HTML to refer to it.  I tend to use the HTML5 DOCTYPE declaration for simplicity, though I have HTML5 and XHTML 1.0 Strict doctype declarations set as macros in Notepad++.

I do have a style, but it exists to differentiate between inline elements (no preceding newline) and block elements (with preceding newline).  Even then, I ignore it in some cases (tables).  When integrating with JavaScript, I prefer to bind events from the JavaScript side rather than using the old-school event attributes.  This has the plus side of making my scripts only work on standards-compliant browsers.  I hate using browser detection, and it's easily spoofed by user configuration anyway.  My browser detection is "if the page doesn't work, STOP USING INTERNET EXPLORER."

Also, WYSIWYG editors are for n00bs.

CSS

At first, I was like

selector { name:value; name:value; name:value; name:value; }

but then I got tired of holding the spacebar, so then I was like

selector { name: value; name: value; name: value; }

The "two spaces as an indent" thing actually came over from mIRC scripting, believe it or not.

JavaScript/PHP/pretty much any C-based language

• Originally I used as little whitespace as I could get away with (basically just indents and separating keywords), but then I had trouble reading my code.
• Single spaces used for each indent level, with code on the same line as the opening curly brace.
• Hardly ever a comment on the same line as an opening curly brace, because that just looks weird.
• Code blocks only ever surrounded by curly braces if they contain more than one line or if they're a function body.
• (JavaScript) I disagree with Douglas Crockford.

function function_name( parameter1, parameter2 ) {line of code; line of code; if( condition ) one line; else {two; or; more; lines; } }

I'll put a single line after (on the same line as) an if (and only after an if) if and only if it's return, break, or continue, and it has no else.  I used the word 'if' a lot in that sentence.

SQL

That's pronounced "ess-kyu-ell", not "sequel" or "squirrel".

I stole most of this from a friend of mine, who has really good ideas every now and then.  This is mostly for MSSQL, as that's what we were using.

• SELECT, FROM, and WHERE on their own line
• For long lists of stuff in the SELECT clause, indent each column, and put commas before column names instead of after.  This makes it easy to add, remove, and comment/uncomment column names.
• Indent JOINs/CROSS APPLYs in the FROM clause.
• Using JOINs looks a lot cleaner than relating all your tables together in the WHERE clause (both produce similar results, but JOINs make controlling what you get easier)
• Indent conditions in the WHERE clause, with your AND/OR before each condition, again to make it easy to add, remove, and comment/uncomment stuff.
• Probably more, I haven't used SQL on a daily basis since my contract ran out at Silverchair.

Powershell

For whatever reason I've been putting opening curly braces at the end of the line in Powershell.  Curly braces are mandatory on all code blocks in Powershell, and there's actually a "script block" data type that you can use as a function argument.  I also use tabs instead of spaces here, but generally set the tab size to one character in my editor (Notepad++).  I will use a combination of tabs and spaces to make things line up regardless of tab size if I split lines for readability.  On a side note, Notepad++ really hates it when I try to use a combination of tabs and spaces when indenting a line.  It converts everything to tabs, forcing me to go back and change things back to spaces when they should be spaces.

mIRC

This one is a no-brainer, mIRC's script editor forces its own style on you.  Curly braces on the ends of lines, two spaces per indent level, with lines broken apart for readability being indented further.  It's not configurable and it enforces the style with a button press in the editor or when you save.  Also, those unquoted strings.  Khaled Mardam-Bey, you silly.

Perl

-f>@+?*<.-&'_:$#/!

lol, I don't use Perl.  Because Perl encourages writing unreadable code.  For what it's worth, I have programmed in Perl before (an IRC bot, designed to run via XChat), but everything I did felt incredibly hack-ish, and no other language has ever given me that vibe.

I've used other languages here and there (bash, Java, Lisp, Python), but not nearly often enough to really matter.