Emerald Editor Discussion
March 26, 2017, 12:34:20 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: Coding Standards  (Read 10679 times)
0 Members and 1 Guest are viewing this topic.
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« on: May 14, 2006, 01:25:15 am »

As code is now in the repository, I think coding standards should be established so that the entire code base remains consistent and good-looking.

This is what I use personally and is just an example of what could be done:

All braces go on their own line:
Code:
void AClass::aMethod()
{
     if (instance->invoke())
     {
         //do something here
     }
}
There's a space between keywords (if, while, for, etc.) and parentheses:
Code:
if (aVar == TRUE)
{
     for (int i = 0; i < 10; i++)
     {
     }
}
All operators are surrounded by spaces, except increment/decrement (for which the default is a postfix (i++) operator instead a prefix (++i)):
Code:
int c = 1 + 2;
stdout << "This is a test";
c += 4;
if (c > 2 || c == -2)
{

}
Also, the tab character ('\t') should be used instead of the standard 4 spaces.
Logged
SnakE
Miner
**
Posts: 13


« Reply #1 on: May 15, 2006, 02:34:03 pm »

On postfix increment:
In general case, postfix increment requires that a temporary copy of the incremented object is created before incrementing.  This is perfectly optimized by a compiler as long as you work with primitive types.  But if this object is of an iterator type with a non-trivial constructor, a copy will be created and a constructor will be called for absolutely no reason.

Therefore, a rule of thumb is: use ++i unless you really need the post-increment semantics.
Logged
dsvick
Beta Testers
Senior Miner
***
Posts: 52



WWW
« Reply #2 on: May 15, 2006, 03:52:18 pm »

I agree with daemon that we should establish at least some basic style standards. The one's he proposes, while not the ones I use, sound fine since it looks like the code for wxwidgets and stEdit is already in that style. The only one I'm not sure about is the tab vs 4 spaces. I've always used 4 spaces but I don't know if it really makes a difference one way or the other.
Logged

Dave
Dalai-Lama
Miner
**
Posts: 11



« Reply #3 on: May 15, 2006, 07:37:00 pm »

The difference between tab and "x spaces" is just :
- If you use x spaces, everyone will see x spaces, event if the think y spaces are better.
- If you use tab, anyone can configure is editor to show x or y spaces for one tab.
Logged
dsvick
Beta Testers
Senior Miner
***
Posts: 52



WWW
« Reply #4 on: May 15, 2006, 08:54:56 pm »

ahh, good point, hadn't thought of it that way. Most places I've worked have said 4 spaces instead of a tab, so I never had to look at it the other way.

thanks
Logged

Dave
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #5 on: May 15, 2006, 10:48:13 pm »

*blushes* In my own stuff (web site source included), I tend to use 1 space indents, and sometimes run stuff together where it made sense at the time... for example, on HTML table rows (TR tags) which have headers only in (TH tags), I tend to run them altogether on one line like so:

Code:

 
Heading 1Heading 2
I'm happy to go with the majority on things like this - it seems to be the consensus to go with what has been said here already.

For variable names and function names, I'd prefer the aVariable and someFunction style, rather than a_variable and some_function, but again that's something for the consensus to decide and our existing codebase to comply with.
Logged

"Cleverly disguised as a responsible adult!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #6 on: May 16, 2006, 03:01:12 am »

Yes, camel case (aB) is the preferred method for naming variables in C++/Java (over a_b)--so I'd agree with you there.

And thanks for pointing that out SnakE... I didn't realize that was so.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #7 on: May 16, 2006, 12:17:52 pm »

I didn't realise that either, SnakE, I always assumed both were optimised the same way.
Logged

"Cleverly disguised as a responsible adult!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #8 on: May 17, 2006, 05:30:30 am »

I've checked in a draft for the coding standards into SVN. You can check them out here. Feel free to comment, but I just wanted to get something hammered out for everybody to comment on.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #9 on: May 17, 2006, 05:42:44 pm »

Looks quite good to me. I notice that you're using the same general style as on your website Smiley (I did wonder if we'd see green-themed guidelines)

As an infamous pirate said, "Well, the Code is more what you'd call... guidelines..." Cheesy
Logged

"Cleverly disguised as a responsible adult!"
alpha
Developers
Senior Miner
***
Posts: 78


« Reply #10 on: May 19, 2006, 02:54:13 am »

daemon,

I like your coding standards... however it would be nice if we could add something like this:

global variables are always prefixed with g_
member variables are always prefixed with m_
static variables are always prefixed with s_

You should declare local variables as close to their first use as scope allows, and always initialise variables to a known initial value.

alpha
Logged
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #11 on: May 19, 2006, 04:38:22 am »

I definitely agree that local variables should be defined at the top of the scope as possible (in true C form)--though I don't think it needs to be a hard-and-fast rule, especially in a for() loop where you create your standard int i.

However, I'm not so sure about prefixing variables in a Hungarian notation. While I can see the merits, I think it would make refactoring a huge chore if the state of the variable changed. I think that the information should be commented on in a Doxygen comment and simply by the scope.

Also, I we should probably formulate a standard file header to be used at the top of all source files.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #12 on: May 19, 2006, 12:29:39 pm »

I agree here - variables should be defined with an initial value and as close to their first use, scope permitted.

But, like daemon, I'm not sure about the Hungarian notation - I've written many programs, both with and without the syntax and I'm not convinced it makes a great deal of difference when you're working with the code a lot.

However, I do think there may be some merit here in doing so, except for local scope disposable variables (e.g. a loop counter, i, that will not be used again). It does promote readability for others and is semi-standard.

In any case the documentation should make it clear what is going on and explain what everything does.

Since we're using wxStEdit for the moment as our core, it may be worth having a look at what that does.
Logged

"Cleverly disguised as a responsible adult!"
alpha
Developers
Senior Miner
***
Posts: 78


« Reply #13 on: May 21, 2006, 03:54:39 pm »

I think to use only the "best part" of Hungarian notation is ok, like this:
Code:
int g_test;
  class Example
   {
       private:
         int m_test;
   
       public:
         void GetTest(int test)
        {
            m_test=test;
        }
};
But without it would work like this too:
Code:
int test;
  class Example
   {
       private:
         int testNumber;
   
       public:
         void GetTest(int testValue)
        {
            testNumber=testValue;
        }
};
I'm not sure what is better?
Markus Schulz
Logged
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #14 on: May 21, 2006, 11:59:30 pm »

Even that, still, would mean refactoring could become problematic because if m_test changed from a member to a global or local, then there'd be a lot more work to be done. Whereas, if it was marked simply by a Doxygen comment, it would be far easier. And most IDEs will support the Doxygen comments, which are also useful.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.126 seconds with 18 queries.