Style questions

[Catfish]

Hello. I'm in a silly mood.
Pick which you consider to be better, and explain why (or propose your own):

1)

Constructor(int m1, double m2)
{
    this->m1 = m1;
    this->m2 = m2;
}

// versus

Constructor(int to_m1, double to_m2)
{
    m1 = to_m1;
    m2 = to_m2;
}

2)

int aVariableName = 0;
int bVariableName = 1;
int cVariableName = 2;

// versus

int
    aVariableName = 0,
    bVariableName = 1,
    cVariableName = 2;

3)

#ifndef HEADER
#define HEADER

#include <...>

#endif

// versus

#include <...>

#ifndef HEADER
#define HEADER

#endif 

4)
Entire class definition in header files, in class body (except static members).
versus
Separating implementation in header and code files.

5)

class C // no private or protected members
{
public:
};

// versus

struct S // no private or protected members
{
};

6)

std::ifstream ifile("file.bin", std::ios::binary | std::ios::app);

// versus

std::ifstream ifile("file.bin", std::ifstream::binary | std::ifstream::app);

Thanks.

[S6k9GNh0]

1. Neither, use construction initialization lists. If you mean in the case you cannot, I generally name my member variables in such a way that the "this->" isn't required.

2. Probably the second, more organized. Although, I don't get a chance to use such a layout usually.

3. First, decreases compile time.

4. This depends. Generally though, I separate implementation and interface. Probably not through the same means as you do though.

5. If all I'm holding is variables and variables that need to be initialized, I'll use a struct. If I need members as well, I'll use a class.

6. The second although that's just me being picky. ifstream goes to ifstream. :D

[Peter87]

1. I would also use construction initialization lists but if I have to pick one I pick the first one.

2. first one. It's how I always do it and I find it easier/more readable. It's also easier if I later want to change the type of one of the variables.

3. First. same reason as computerquip.

4. separate files, except for templates

5. Always struct if there is no functions. If I have public data members and functions I might use struct but this is very rare case so I'm not sure.

6. First. ios is shorter to write and it's the way I got used to.

[moorecm]

1. Neither. The following is more efficient and you don't have to mess with the names:
Constructor(int m1, double m2) : m1( m1 ), m2( m2 ) {}

2. First one. Consider the implications of this:

int*
    aVariableName = 0,
    bVariableName = 1,
    cVariableName = 2;

3. First one.

4. Ultimately depends on the complexity of the class but I prefer header-only when possible, as it's easier to just include and use.

5. I do the second one every time. structs and classes are virtually the same thing and I don't suffer from the C mindset of a struct having no methods.

6. I'd try to stick with the type that is defaulted in the implementation, if possible. Isn't that ios_base::in?

[Pravesh Koirala]

3. The second one is useless (In a large project), always try to use the first one. But I prefer a more compact way

#pragma once
//...everything else

[ne555]

int a, b, c; Initialization if necessary

I like having a linker. Also, separate file for implementation in case of templates.

¿app for ifstream?