What's Your Coding Style?

[Creature]

Hello,

I am having trouble figuring out a coding style. The truth is, I try to stick to UpperCamelCase for pretty much everything, except parameters for functions are in lower camel case. I'm also not sure what case to use inside functions, I usually tend to use UpperCamelCase there too unless it's a one-character name like 'i'. Besides that, I've encountered lots of problems trying to define my constants; I used defines with capital letters at first (with always some sort of type identifier, such as PAGE_FLAG_PRESENT for paging), but now I keep using enumerations to define constants and namespaces to wrap them and classes. I've also had numerous times that I wasn't really satisfied with my current way of doing things, tried to rewrite it all, and it turned out that I wanted something like the original style anyway.

I was wondering if anyone here has a specific coding style they always stick to when they code something (unless of course, it's a project that has strict style guidelines). Have you had any problems with naming variables and such (conflicting names) that you've encountered using your own style?

[Owen]

I pretty much follow the style of Qt:

Code: Select all

#define MACROS_ALWAYS_UPPER_CASE(_parameters_underscore_prefixed) 
namespace CamelCased {

class CamelCased {
public:
   void methodJavaCased(int asAreParameters)
   int someVal(); // getters have no prefix
   void setSomeVal(); // setters have set prefix
private:
    int m_membersHaveAPrefix;
    static int ms_asDoStatics;

    // if this class is pImpl style, then the p is called m
    CamelCasedPrivate* m;
};

enum MoreCamelCasing {
    ConstantsAreCamelCasedToo = 0,
    // in general, the enumeration values should end with something related to what they're defining
};

const int ExampleOfAConstant = 0;
}

// All function names are javaCased
void function() {
    int variableName; // Variables in functions are javaCased
}

Names for hidden (i.e. implementation detail) objects should be created by a special macro:

Code: Select all

// These two for special corner cases
#define PRJ_CONCAT2(_a, _b) _a##_b
#define PRJ_CONCAT(_a, _b) PRJ_CONCAT2(_a, _b)
#define PRJ_GEN_NAME(_name) PRJ_CONCAT(PRJ_CONCAT(PRJ_CONCAT(_i_PrjName, __LINE__), __FILE__), _name)

They should also be translation unit private when created in the global scope (i.e. defined in an anonymous namespace or declared static) whenever possible

[fronty]

I try to follow FreeBSD's style(9).

[gravaera]

Code: Select all

#define MACRO_CATEGORY_SUBCAT_VERBOSE_PURPOSE(__param)   (__param)

//Post-fix classes with capital C. Structs with capital S.
class lowerCamelCaseC {
   friend class creepyClassC;
   public:
      lowerCamelCaseC();
      ~lowerCamelCaseC();

   public:
      type myMethod();

   private:
      int moreLowerCamelCase;
};

I always use lower camel case in C++. In C, I follow the underscore convention. For all types of block statements I do full bracing, even for one liners.

As an addendum, I comment feverishly, and use the following format for comments:

Code: Select all

/** EXPLANATION:
 * This is an explanation block which is placed before any code in the file, after the #includes.
 * ...
 **/

/* General multiline comment.
 * Which spans multiple lines.
 **/

//Single line comment in C and C++
/* Single line comment in ASM. (I use GNU AS) */

;;When using NASM, etc, I form my comments like this, with two semi-colons

The rest of my coding style is extremely explicit, in that I tend to do things like:

Code: Select all

for (simple-expression;
   ((fully-bracketed) || (complex-expression));
   expression
   )
{};

while (expression) {
   //Even for single line block statements, I still place the braces in.
};

[Love4Boobies]

I use the original KNF (Kernel Normal Form) coding style from 4.4BSD-Lite2, which is where FreeBSD's coding style descended from. The difference is that I don't use the obsolete K&R parameter list syntax and I also use single-line comments. (Oh, and I adapt it for C++ but that's obviously not very hard).

[Firestryke31]

It doesn't cover everything, and it's designed more for easy reading (though I don't know how well I did in that regard) but I've got my coding style in the developer section of my site (link). Some of the "example" code isn't as efficient as it probably could be, but it's meant to demonstrate style, not efficiency.

Also, under Operators, IDK if the pre/postfix inc/decrement operator statement is valid, but once again, it's just to demonstrate style.

[KotuxGuy]

My coding style:

Code: Select all

#define MACRO_UPPERCASE(paramsCamel)

class CamelClass
{
   methodJavaCase(paramsCamel);

   privateStuffJavaCase;
}

[earlz]

It depends on language... For C#, the usual CamelCase. For C/++ underscore_style for Ruby, it's the way recommended by the language.

[leledumbo]

This one is mine:
Pascal:

Code: Select all

unit MyUnit;

{$mode objfpc}{$H+}

interface

uses
  Unit1,Unit2;

type
  TSomeClass = class
  private
    FProp: LongInt;
  public
    property Prop: LongInt read FProp;
    constructor Create;
    destructor Destroy;
    procedure Proc;
    function Func: LongInt;
  end;

implementation

constructor TSomeClass.Create;
begin
end;

destructor TSomeClass.Destroy;
begin
end;

procedure TSomeClass.Proc;
var
  i: LongInt;
begin
  for i:=1 to 10 do begin
    ...;
  end;
  repeat
    ...
  until ...;
end;

function TSomeClass.Func: LongInt;
begin
  while ... do begin
    ...;
  end;
  case Result of
    0: ...;
    1: ...;
    otherwise ...;
  end; 
end;

end.

C:

Code: Select all

#define A_CONSTANT 255

typedef struct {
  int i;
  char c;
} TMyStruct;

int func() {
  for (int i=0;i<10;i++) {
    ...;
  }
  while (...) {
    ...;
  }
  return 0;
}

void proc() {
  do {
    ...;
  while (...);
  switch (...) {
    case 0:
      ...;
    break;
    case 1:
      ...;
    break;
    default:
      ...;
  }
}

[AJ]

Hi,

I tend to follow this document which is pretty comprehensive and tries to justify the reasons for everything. There are a couple of unusual cases in there (for example, memberVariable_), but I find it makes code very readable. Ultimately, that will always come down to opinion, though.

Cheers,
Adam

[Solar]

...memberVariable_...

Blindfold? Cigarette?

OK, guys. Aim...



The Pro-POS coding style guide (C++) isn't perfect, and today I'd probably do some things a bit differently, but all in all it's sound.

PDCLib shows my C coding style.

[Synon]

http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS

[NickJohnson]

This is my usual C style:

Code: Select all

// debugging comment (if C++ style supported)
/* regular comment */
/*** important comment ***/
/***** really important comment *****/
/***** SEPARATOR *****/

/*
 * Multiple line comment.
 */

#ifndef SENTRY
#define SENTRY

/* header stuff */

#endif/*SENTRY*/

#define CONSTANT 1
#define MULTI_WORD_CONSTANT 2
#define MACRO(n) ((n) + 42)
#define MULTI_LINE_MACRO(v) \
do { \
 ... \
} while (0);

struct stuff {
 int q;
 struct stuff *next_stuff;
} stuff_t;

int some_function(int a, char *b) {
 int foo;
 stuff_t bar;
 int *z = (void*) b;
 int i;

 switch (b[2]) {
 case 'a':
  ...
  break;
 case 'q':
  ...
  break;
 }

 if (a & (1 << 5)) {
  foo = 42;
 }
 else {
  foo = 66;
 }

 bar.q = 0;
 for (i = 0; i < foo; i++) {
  bar.q += (foo * 5) + i;
 }

 return (z) ? 123 : 321;
}

(all with 4-space tabs)

The best I can classify it would be slightly modified TBS with underscores.

[Solar]

http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS

Nice summary. Didn't know Wikipedia had such a page.

In short, K&R, 1TBS and ANSI are all three acceptable (and mostly a matter of personal taste, with pros and cons for each of them). I vote for ANSI, though - the most verbose of the three. The others are various degrees of crap, IMNSHO, with the GNU style being the winner in the crap department by a wide margin.

I advise against having tabs (0x09) in your sources, though, except for Makefiles (where you can't go without them). Too often you get inconsistencies introduced by different editing environments. Some retain the tabs, some expand them to spaces. Pretty soon, you've got source where an indent is either a tab, 4 spaces, or 8 spaces, and it wastes your time getting it consistent again that's better spent writing code.

My suggestion is to use 4 spaces for indent.

Actually, in all projects where I got a saying in these things, source is automatically checked (among others) to contain only characters in the 0x20-0x7e range, and commit is rejected if this (or some other) constraint is violated. Saves you all kind of headaches (like code page / UTF-8 concerns...).

[Firestryke31]

Actually, in all projects where I got a saying in these things, source is automatically checked (among others) to contain only characters in the 0x20-0x7e range, and commit is rejected if this (or some other) constraint is violated. Saves you all kind of headaches (like code page / UTF-8 concerns...).

So all of the source is on one line? (0x0A &| 0x0D)