Here are some of my personal computer conventions.

File/Directory Names

Coding

Coding Naming Conventions

Note that most of these apply especially to Visual Basic and/or VBScript, but other languages may have more language-specific conventions.

Follow the above for JavaScript, Java, C, C#, etc. except for the following:

Case or Notation

Here are the various case or notation conventions. The terms are ordered to build on concepts (i.e. they're not ordered alphabetically).

Sentence case
Just like proper English sentences. First letter capitalized. All other letters are lower case except words that are unconditionally capitalized, such as proper nouns and "I". There may be a space or punctuation or both between words. EG:
This is an example, George.
Title Case
Just like proper English titles. Main words are capitalized, including the first word, the last word, the first word after a colon indicating a subtitle, and the word after a hyphen in a compound word. Do not capitalize the first letter of words that are articles (a an the), prepositions (of between under through, etc.), or conjunctions (and or, etc.). EG:
Notes on the Production of Essays in the Arts and Sciences.
First Letters Case
The first letter of each word is capitalized without exception. First Letters Case is easier than Title Case to imlement programmatically. EG:
Notes On The Production Of Essays In The Arts And Sciences.
runtogether case
Words are run together. EG:
lowercaseexample
UPPERCASEEXAMPLE
InterCapsExample
intraCAPSexample
lower case
All letters lower case. EGs:
this example uses spaces
thisexampledoesnot
this-example-uses-hyphens
this_example_uses_underscores
main_left-big (hypens and underscores)
UPPER CASE
All letters UPPER case.EGs:
THIS EXAMPLE USES SPACES
THISEXAMPLEDOESNOT
THIS-EXAMPLE-USES-HYPHENS
THIS_EXAMPLE_USES_UNDERSCORES
MAIN_LEFT-BIG (hypens and underscores)
InterCaps case
Aka BiCapitalization, Mixed case, Bumpy case, NerdCaps. Words capitalized and run together. First letter may or may not be capitalized. EGs:
firtLetterNotCapitalized (aka camel case, camelBack case, lowerCamel case, humpBack case)
FirstLetterCapitalized (aka UpperCamel case, Proper case, Pascal case)
ILoveMyIBM (Acronyms all UPPER case)
ILoveMyIbm (Acronyms capitalized like proper noun)
intraCAPS case
Word run together but one word is all UPPER case and the next word is all lower case. EG:
thisISanEXAMPLE
tallMAN case
For similar words that differ in one part, put that part in all UPPER CASE. This is common in the health care industry. EG:
pulmiCORT
pulmiZYME
Studly case
Aka L337. Any letter may be UPPER or lower case. The more random the "better". Letters may be encoded with numbers or characters that have some vague resemblance to the actual character. In my opinion, Studly case is more for atmosphere than function because it does not abbreviate and it doesn't make your message any clearer. EGs:
iS tHIs rEaLly sO cOol? (Is this really so cool?)
L|-|!z 5|_|(|<s (this sucks)
Hungarian Notation
A variation of lowerCamel case, but where combined word is prefixed with a short (usu. three letters) lower case name denoting the data types or class. EG:
strMyName (A string variable)
tlp
Three Letter Prefix. The short lower case prefix used in Hungarian Notation. The tlp is usually but not necessarily three letters long.

Indentation

Indentation conventions are used for writing blocks of code for human readability. This comes mainly from Indent style [W].

Tabs v Spaces

In word processors, use tabs instead of spaces. This is because proportional fonts won't line up with spaces.

In code, the issue of tabs v spaces is much more complicated and opinionated! The only thing certain is that most programmers will code using monospaced fonts. See links like these:

It is suggested that "tabs" equate to a length between 2-8 spaces --pick a size an stick with it. A lot of Microsoft and Macintosh code has 4-space sized tabs(    ), while a lot of Unix code has 8-space sized tabs (        ). Some people have more complicated rules about how many spaces they use in depending on context. In some cases you can adjust the IDE to interpret hard tabs in different soft tab sizes.

"Tab" can be hard tabs (\t, Chr(9), etc.) or soft tabs (faked with spaces). Left side indentation with hard tabs saves on the amount of white space characters used. If you need to count "tabs" in order to see how deeply nested a block is, then it is much easier to count hard tabs than soft tabs. However, as the example show, if your code is viewed in an IDE (Integrated Development Environment) where tabs are sized differently, then the code can look bad.

EGts4. This example uses hard tabs (represented with   ->) and spaces (represented with .). Looks good... so far!

  ->if(x==3)  ->  ->// hard tab comment 
  ->{...............// soft tab comment
  ->  ->func();
  ->  ->// hard tab comment
........// soft tab comment
  ->}

But what if it's moved to an IDE where the tabs are 8-spaces instead of 4? It looks screwy!

      ->if(x==3)      ->      ->// hard tab comment 
      ->{...............// soft tab comment
      ->      ->func();
      ->      ->// hard tab comment
........// soft tab comment
      ->}

EGt4. This example is the same as EGts4 but with just hard tabs. Looks good... so far!

  ->if(x==3)  ->  ->// hard tab comment 
  ->{ ->  ->  ->  ->// soft tab comment
  ->  ->func();
  ->  ->// hard tab comment
  ->  ->// soft tab comment
  ->}

But what if it's moved to an IDE where the tabs are 8-spaces instead of 4? It looks screwy!

      ->if(x==3)      ->      ->// hard tab comment 
      ->{     ->      ->      ->      ->// soft tab comment
      ->      ->func();
      ->      ->// hard tab comment
      ->      ->// soft tab comment
      ->}

EGs4. This example is the same as EGts4 but with just spaces. Looks good... so far!

....if(x==3)........// hard tab comment 
....{...............// soft tab comment
........func();
........// hard tab comment
........// soft tab comment
....}

But what if it's moved to an IDE where the tabs are 8-spaces instead of 4? It still looks great!

....if(x==3)........// hard tab comment 
....{...............// soft tab comment
........func();
........// hard tab comment
........// soft tab comment
....}

EGts: One practice is "Indent good, align bad". Indent from column 0 and avoid using "precision" alignment because the tab size might be different in different enivronments. Using this practice, different users can freely set their IDE to the tab size they want.

Instead of this:
my_function (  ->parameter1,
  ->  ->  ->parameter2,
  ->  ->  ->parameter3) {
  ->x = 8;
  ->....// Comment under the 8
}
  
Try this:
my_function (
  ->  ->  ->parameter1,
  ->  ->  ->parameter2,
  ->  ->  ->parameter3
) {
  ->x = 9;
  ->// Don't try to get precisely under the 9
}

Whether 4-space (above) or 8-space (below), it still looks good:
my_function (
      ->      ->      ->parameter1,
      ->      ->      ->parameter2,
      ->      ->      ->parameter3
) {
      ->x = 9;
      ->// Don't try to get precisely under the 9
}

If the coder had used soft tabs instead of hard tabs above, the problem would not have arisen but other viewers would have to put up with the original coder's preferred size for soft tabs. While it may seem that the solution is to use hard tabs for indentation, and to avoid precision alignment, there are common cases for preferring spaces/soft tabs:

In general, whenever you get someone else's code, check their tabs and spaces before you use it. Problems arise when you are working on code written by multiple developers and the developers have used a different number of spaces for their tabs. As long as there is no confusion in the depth of nesting, do not try to adjust the code. It is usually not worth the time to fix and the fix process is prone to error. On the other hand, some people will diddle with the tabs and spaces anyway.

Page Modified: (Hand noted: 2007-10-04 21:40:01Z) (Auto noted: 2011-10-27 18:26:37Z)