For$
<!-- begin site header -->
<div id=

Author Topic: Coding Style  (Read 14789 times)

bakkdoor

  • Developer
  • Newbie
  • ****
  • Posts: 8
    • View Profile
Coding Style
« on: December 07, 2010, 01:12:26 am »
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

  • Administrator
  • Newbie
  • *****
  • Posts: 28
    • View Profile
Re: Coding Style
« Reply #1 on: December 07, 2010, 01:56:08 am »
I like it, no complaints here!

Manhim

  • Developer
  • Newbie
  • ****
  • Posts: 10
    • View Profile
Re: Coding Style
« Reply #2 on: December 07, 2010, 02:51:53 am »
For less confusion I suggest getFoo() for getters.

Andrew

  • Developer
  • Newbie
  • ****
  • Posts: 9
    • View Profile
Re: Coding Style
« Reply #3 on: December 07, 2010, 08:19:39 am »
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.
« Last Edit: December 07, 2010, 08:22:31 am by Andrew »

bakkdoor

  • Developer
  • Newbie
  • ****
  • Posts: 8
    • View Profile
Re: Coding Style
« Reply #4 on: December 07, 2010, 11:39:35 am »
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 :D

Quote
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

Quote
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.
« Last Edit: December 07, 2010, 11:42:07 am by bakkdoor »

Manhim

  • Developer
  • Newbie
  • ****
  • Posts: 10
    • View Profile
Re: Coding Style
« Reply #5 on: December 07, 2010, 10:36:06 pm »
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

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Coding Style
« Reply #6 on: March 31, 2011, 11:39:58 pm »
Regarding getters and setters, how about using a single function with a const overload to return both lvalues and rvalues?

MechWarrior001

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: Coding Style
« Reply #7 on: May 22, 2011, 06:39:45 am »
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.