Coding Style

[bakkdoor]

Talked to Psoden today in irc and agreed that we need a coding style, immediately

Here's a proposal: http://mineserver.be/wiki/Coding_Style
Comments welcome.

[deoxxa]

I like it, no complaints here!

[Manhim]

For less confusion I suggest getFoo() for getters.

[Andrew]

I personally don't see the point behind using outdated hungarian notation by putting m on all the member variables.

Both Microsoft and Bjarme Stroustup recommend against it and that's enough for me. We're not coding in C and need to keep check of if our variables are "members" of our "class"

this->m_foo.. you already know it's a member of the object you're calling.

I also suggest putting brackets on all if statements as it's very easy to create a bug by proxy of someone else editing your code. The only reason no one really does is simply laziness (myself included).

I think the most important thing however is the way people write code and the names they use for methods. I think it's more important then general syntax and how many spaces an indent is.

A bad example with difficult to read code..

Code: [Select]

if (obj)
{
  // insert many lines of code
  if (foo)
  {
     // insert many lines of code
     if (bar)
     {
       // insert many lines of code
     }
  }
}
return;
A better way of doing the same thing

Code: [Select]

if (!obj) { return; }
if (!foo) { return; }
if (!bar) { return; }
A bad example with method naming simply because everyone uses a different name for getting similar data across classes.

Code: [Select]

Foo foo;
Bar bar;
foo->getName();
bar->getTitle();
My personal experience is that when working in teams the previous two examples are much more important then making sure everyone's syntax is similar.

[bakkdoor]

I personally don't see the point behind using outdated hungarian notation by putting m on all the member variables.

Both Microsoft and Bjarme Stroustup recommend against it and that's enough for me. We're not coding in C and need to keep check of if our variables are "members" of our "class"

this->m_foo.. you already know it's a member of the object you're calling.

I'd prefer no prefixes as well, makes it harder to read imho. But I'm fine with using them if the majority demands it

I also suggest putting brackets on all if statements as it's very easy to create a bug by proxy of someone else editing your code. The only reason no one really does is simply laziness (myself included).

I think the most important thing however is the way people write code and the names they use for methods. I think it's more important then general syntax and how many spaces an indent is.

+1

A bad example with difficult to read code..

Code: [Select]

if (obj)
{
  // insert many lines of code
  if (foo)
  {
     // insert many lines of code
     if (bar)
     {
       // insert many lines of code
     }
  }
}
return;
A better way of doing the same thing

Code: [Select]

if (!obj) { return; }
if (!foo) { return; }
if (!bar) { return; }
A bad example with method naming simply because everyone uses a different name for getting similar data across classes.

Code: [Select]

Foo foo;
Bar bar;
foo->getName();
bar->getTitle();
My personal experience is that when working in teams the previous two examples are much more important then making sure everyone's syntax is similar.

[Manhim]

I'd use a prefix only for private members like _privateMember;

For public ones it would be PublicMember or publicMember, whichever is the best.

[louisdx]

Regarding getters and setters, how about using a single function with a const overload to return both lvalues and rvalues?

[MechWarrior001]

In MS VC++ 2010 Express I'm getting a bunch of warnings concerning using sprintf_s instead of sprintf, fopen_s instead of fopen, and localtime_s instead of localtime. While probably not necessary, it might be a good idea to switch to the *_s commands, if for nothing else than good coding practice.