Coding Style Guidelines and Git/GitHub Workflow

About the actual programming of the game.

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby Zardoz » Wed Aug 21, 2013 2:03 pm

I'm pro 2 spaces. Better use of screen space.
Yep, I have a blog : http://zardoz.es
Emulator DCPU-16 VM
User avatar
Zardoz
 
Posts: 359
Joined: Mon Aug 12, 2013 8:54 pm
Location: Spain

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby mrout » Wed Aug 21, 2013 3:50 pm

Pseudonym wrote:
mrout wrote:That's like hungarian notation all over again.

Yes, but it's the right kind. There are two kinds of Hungarian notation: What Simonyi did, and what everyone at Microsoft misunderstood.

There are several reasons why this is a good idea, but this is the simplest example:

Code: Select all
class Bar {
    foo_t mFoo;

    void set_foo(foo_t pFoo) {
        mFoo = pFoo;
    }
};


The parameter and the member should have the same name since they're logically the same thing, but they should also be distinguished because you need to refer to them separately.


No, that's terrible code. Firstly, the _t prefix is reserved by POSIX, so you shouldn't use it. Secondly, the this-> notation exists for a reason. It's much clearer.

[quote=sanchezman]Should traditional includeguards be used instead?[/quote]

Considering that #pragma once is non-standard, I think the answer should be clear. :)

[quote=lamogui]I sudgest to reduced the identation space 4 it's too big with 80 columns... 3 or 2 are better (this is my opinion and coding experience)[/quote]
[quote=Zardoz]I'm pro 2 spaces. Better use of screen space.[/quote]

Not up for discussion.
mrout
 
Posts: 731
Joined: Mon Aug 12, 2013 10:49 pm

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby Metaluim » Wed Aug 21, 2013 4:11 pm

Since we're discussing tab sizes, shall we use tabs or spaces? If we use tabs then anyone can configure the tab space to their own liking.
Metaluim
 
Posts: 11
Joined: Sun Aug 18, 2013 8:52 pm

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby mrout » Wed Aug 21, 2013 4:42 pm

Metaluim wrote:Since we're discussing tab sizes, shall we use tabs or spaces? If we use tabs then anyone can configure the tab space to their own liking.


Spaces. How long is a line that starts with a tab? What might seem like 80 characters to you could be 98 characters to me.
mrout
 
Posts: 731
Joined: Mon Aug 12, 2013 10:49 pm

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby thomas9459 » Wed Aug 21, 2013 4:49 pm

Metaluim wrote:Since we're discussing tab sizes, shall we use tabs or spaces? If we use tabs then anyone can configure the tab space to their own liking.

No one is discussing it. As per mrout:
mrout wrote:Not up for discussion.

This is one of those things where arguing can go on forever without any resolution. Since the impact of this decision is actually quite small, it is better for someone (in this case mrout) to put their foot down and define a style that everyone adheres to.
thomas9459
 
Posts: 101
Joined: Thu Aug 15, 2013 6:18 pm

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby sanchezman » Wed Aug 21, 2013 6:28 pm

Any good IDE should let you select the option to automatically convert tabs to spaces as you type. You wouldn't even need to change how you do things.
Why are they called urinal cakes if you're not supposed to eat them?
User avatar
sanchezman
 
Posts: 58
Joined: Sun Aug 18, 2013 7:26 pm

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby Pseudonym » Thu Aug 22, 2013 12:24 am

mrout wrote:No, that's terrible code. Firstly, the _t prefix is reserved by POSIX, so you shouldn't use it.

As long as you stay out of the top-level namespace, it's completely kosher.

mrout wrote:Secondly, the this-> notation exists for a reason.

That reason is orthogonality. Disallowing it would require introducing a special case in the language spec for no benefit.
Pseudonym
 
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby Andrew » Thu Aug 22, 2013 12:48 am

What file extensions will we use for C++ header and source files?

I also propose that definitions for inline and templated functions should be in separate source files.

I'm thinking either:

  • file.hh: C++ Header file, declarations only, unless a function is a no-op.
  • file.cc: C++ Source file, definitions.
  • file.icc: C++ Source file, only used for inline function definitions.
  • file.tcc: C++ Source file, only used for templated function definitions.

or

  • file.h
  • file.cpp
  • file.i.cpp
  • file.t.cpp
IRC: |Andy|
Andrew
 
Posts: 110
Joined: Wed Aug 21, 2013 7:16 am
Location: Melbourne, Australia

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby mrout » Thu Aug 22, 2013 12:58 am

@Andrew: Standard .cpp and .hpp. Putting inline and templated function definitions in separate files serves no purpose.
mrout
 
Posts: 731
Joined: Mon Aug 12, 2013 10:49 pm

Re: Coding Style Guidelines and Git/GitHub Workflow

Postby Andrew » Thu Aug 22, 2013 1:13 am

@mrout: I feel the header file should be strictly for declarations though..
IRC: |Andy|
Andrew
 
Posts: 110
Joined: Wed Aug 21, 2013 7:16 am
Location: Melbourne, Australia

PreviousNext

Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest

cron