Code Conventions

[Satoshi]

Hi, I wanna know your opinion about code convetions. What conventions are you using and why? eg. camelCase vs PascalCase vs under_case. Spaces between operators,
void test() {
}

vs
void test()
{
}

etc.
C# have defined PascalCase for everything except paramNames. But I think its faster to write camelCased name against PascalCased or under_cased but PascalCased looks better.
or sendButton against btnSend.

I wanna write a code convetions what will be easy to read/write, looks good and could be used for big projects with thousands line of code.
Thanks for your opinion.

[SpyderTL]

I usually try to "adopt" the most common standards for whatever language I'm using.

C#

Code: Select all

namespace CompanyName.ProductName.ApplicationName
{
   public class ClassName : BaseClass
   {
      private object privateObject;
      public object PublicObject;

      public object PublicMethod(object argumentOne, object[] argumentTwo)
      {
         return DoStuffHere();
      }
}

JavaScript

Code: Select all

var myFunction = function(argumentOne, argumentTwo) {
   return doStuff();
}

I tend to name methods with a VerbNoun() format. (i.e. OpenFile(), ExportSpreadsheet(), CloseConnection())

I don't use comments very often, unless the code is particularly unclear, or difficult to follow. I try to avoid comments by using descriptive variable names and method names.

I also try to choose the shortest coding route to get to a working state. I'll replace 5 lines of code if I can do the same thing in 2, unless performance is of particular importance.

I try to keep methods short and simple, but I will write the same code in 2 or 3 different methods if it makes the code easier to follow. I'll start "transplanting" code to a single location when I notice it being copied more than that.

I focus on finishing projects in iterations, rather than waiting until everything is complete. I'd rather have a buggy 1.0 release in 3 months, rather than a stable 1.0 release in 6.

Of course, Tabs > Spaces.

[eryjus]

What conventions are you using and why?

My goal when writing code is to have code the is easily understood later then I read it. My style in writing code is not designed for the ease of putting code down. I spend much more time reading code than I do writing it -- even my own code. Consider it this way, I write a block of code once and then every other time that code is on my screen, I am reading it. So, my coding style will likely be a bit different than SpyderTL's.

I write most of my code in C and occasionally C++. If I can write code in 2 lines or 5 lines, and the 5 line version has a more apparent meaning, I use the 5 line version (with higher level languages, I leave the optimization to the compiler).

I start variables and members with a lower case. I start methods and functions with an upper case letter. I prefer not to use underlines or all lower case:

A programmer was writing a driver for a plotter. He wanted to have a variable to track the state of the pen against the paper, and decided to assign it 2 possible values: penisup and penisdown.

Since my code is not only read by me, I try to avoid such ambiguities.

I do not mix unary operators with other operations; they will typically appear on a line by themselves.

Code: Select all

i ++;

I surround operators with spaces:

Code: Select all

i = x + y;

When defining a function (not an inline function) I put the brackets on a different line than the function declaration:

Code: Select all

void foo(int bar) 
{
     return GetSomeValue();
}

I keep parenthesis close to the functions (since that are part of the signature, esp in C++), but keyword and parenthesis are separated by a space:

Code: Select all

if (check == True) {
    DoSomething();
} else {
    DoSomethingElse();
}

Notice, I have the opening brace on the same line as the compound statement. I only skip the braces when the entire compound statement is on a single line:

Code: Select all

while(i < 100) i ++;

Yes, this is a valid exception to the above rule on unary operators.

I do not put spaces between class and member names when separated by the "::" operator (again since the whole name is part of the signature):

Code: Select all

class Foo {
public:
    static int bar;
};

int Foo::bar = 259085;

Recently, I also started having my editor save tabs as spaces. The reason is that GitHub and other such CVS servers that display code will mangle the tab characters and make the code difficult to follow.

I hope this helps. I am not writing a lot of C code these days, so I'm sure I have forgotten more than I have written.

[konacake]

Personally I put open brackets on the same line as the identifier, just because we live in a world where screens are wider, not longer, and I don't feel like scrolling past dozens of lines of empty space to see the code. I actually admired Go for enforcing it.

Plus, the GNU coding standard gives open brackets their own lines, and I think a lot of us want to do anything they don't

[SpyderTL]

I'm probably the only person on this site (and maybe the planet, for that matter) that uses non-monospace fonts for development. I find it easier to read, and *most* of the time, things still line up fairly well. I'm currently using Segoe UI, which is the default Windows 7 UI font. Takes a little getting used to, but I think it makes more verbose, descriptive method and variable names more readable.

I pretty much only use spaces after commas and semicolons, and around equals signs and binary operators. And curly braces always get their own line... just seems more "balanced" to me.

Code: Select all

for(int x = 0; x < 100; x++)
{
   DoSomething();
   DoSomethingElse();
}

I also don't put curly braces around single instructions.

Code: Select all

if(true != false)
   DoSomething();

[Antti]

I have not found my style yet. This is roughly the style I used previously:

Code: Select all

; UNIT - SOME MEANINGFUL DESCRIPTION FOR THE UNIT
; Copyright (C) 2014 ---- ----
; All rights reserved.

INCLUDE "SomeGeneralHeader.inc"
INCLUDE "SomeOtherHeader.inc"


;  __________________________________________________________________________
; |                                                                          |
; |  Description:   Main execution path                                      |
; |__________________________________________________________________________|
; *                                                                          *
NameSpace_Start:
        mov bx, 1234                        ; input description
        call NameSpace_SomeSubRoutine       ; call SomeSubRoutine

        shl ax, 1                           ; ax = ax * 2
        or ax, 1                            ; ax = ax | 1

        mov bx, ax                          ; input description
        call OtherNameSpace_DoSomething     ; do something with ax

        ret                                 ; exit unit
; *__________________________________________________________________________*


;  __________________________________________________________________________
; |                                                                          |
; |  Description:   Some meaningful description                              |
; |                                                                          |
; |  Input:         bx = description                                         |
; |                                                                          |
; |  Output:        ax = description                                         |
; |                                                                          |
; |  Note:          no side effects, all other registers preserved           |
; |__________________________________________________________________________|
; *                                                                          *
NameSpace_SomeSubRoutine:
        mov ax, bx                          ; move ax, bx
        nop                                 ; no-operation (padding)
        nop                                 ; no-operation (padding)
        nop                                 ; no-operation (padding)
        ret                                 ; return ax (description)
; *__________________________________________________________________________*