Few Qs about Cconventions (variable naming and variable/argument ordering etc)

1. Should I name an unchanging variable received as input from the user when starting a program with all CAPS like a constant?

2. When declaring variables at the start of a function, is there any ordering convention I can follow? For example, types of greater size like size_t, pointers etc should be entered before char types, or arrays of any type should be first or... I never know where I should put a new variable, and the top of my main function or example looks messy. Maybe I need to group some into structures or something.

3. Following from question 2, how about ordering of arguments?

4. How do I determine whether to use an int or a size_t? I have a couple variables specifying maximum sizes which will probably be fine in int, but they are specifying sizes so should I use a size_t anyway. Sould I just use size_t's for all numbers?

Cheers

Quote:

---

Originally Posted by codingnewbie

1. Should I name an unchanging variable received as input from the user when starting a program with all CAPS like a constant?

---

Personally, I prefer to reserve fully capitalised names for macro names since macros do not obey the rules of scope. Thus, my answer to this is no. But if you already have a convention of fully capitalising names of non-macro constants of special significance, then by all means go ahead, though it is more important that the variable actually is declared const.

Quote:

---

Originally Posted by codingnewbie

2. When declaring variables at the start of a function, is there any ordering convention I can follow? For example, types of greater size like size_t, pointers etc should be entered before char types, or arrays of any type should be first or... I never know where I should put a new variable, and the top of my main function or example looks messy. Maybe I need to group some into structures or something.

---

Declare variables near first use, i.e., do not declare all your variables at the start of a function, unless the function is so small that doing so is declaring them near first use. As far as possible, initialise your variables sensibly as you declare them.

Quote:

---

Originally Posted by codingnewbie

3. Following from question 2, how about ordering of arguments?

---

Follow existing conventions, e.g., if you are writing a generic algorithm along the lines of those in <algorithm> and <numeric>, follow the precedent established by those standard generic algorithms.

Quote:

---

Originally Posted by codingnewbie

4. How do I determine whether to use an int or a size_t? I have a couple variables specifying maximum sizes which will probably be fine in int, but they are specifying sizes so should I use a size_t anyway. Sould I just use size_t's for all numbers?

---

If the variable stores some kind of size, or is some kind of index bounded by a size, then it makes sense to use size_t or an appropriate typedef thereof (e.g., std::vector<int>::size_type), since a negative size is unlikely to make sense. You can still use -1 to denote an invalid index of some sort, e.g., std::string::npos.

There are no hard and fast rules for formatting C++.

Quote:

---

1. Should I name an unchanging variable received as input from the user when starting a program with all CAPS like a constant?

---

Not usually. I usually make compile time const's all caps.

Quote:

---

2. When declaring variables at the start of a function, is there any ordering convention I can follow? For example, types of greater size like size_t, pointers etc should be entered before char types, or arrays of any type should be first or... I never know where I should put a new variable, and the top of my main function or example looks messy. Maybe I need to group some into structures or something.

---

The best practice is to declare variables at the point they are to be used.

Quote:

---

3. Following from question 2, how about ordering of arguments?

---

Whatever seems logical. I order in terms of input/output or source/destination; x & y coordinates in that order; The main rule is consistency.

Quote:

---

4. How do I determine whether to use an int or a size_t? I have a couple variables specifying maximum sizes which will probably be fine in int, but they are specifying sizes so should I use a size_t anyway. Sould I just use size_t's for all numbers?

---

Here we use the rule that integers will be 'int' unless there is a valid reason why they shouldn't.

Quote:

---

Originally Posted by JohnW@Wessex

Here we use the rule that integers will be 'int' unless there is a valid reason why they shouldn't.

---

Do you think that the fact that negative values don't make is sense a valid reason? E.g. if you were to build a container like std::vector.

Quote:

---

Originally Posted by D_Drmmr

Do you think that the fact that negative values don't make is sense a valid reason?

---

Not necessarily. If the signed int maximum is plenty big enough for the proposed container (2 Gig elements!) then negative indexes can always be trapped as an 'out of range' exception.
Valid reasons for us are such things as serial port char buffers, 8 bit/16 bit images etc. where an int is inefficient for space or performance.

Quote:

---

Originally Posted by JohnW@Wessex

Not necessarily. If the signed int maximum is plenty big enough for the proposed container (2 Gig elements!) then negative indexes can always be trapped as an 'out of range' exception.

---

True, but there is a convention prevalent in the standard library (size_type is always a typedef for an unsigned integer type), and even in the fact that size_t is the type of the result of sizeof.

Quote:

---

Originally Posted by laserlight

size_type is always a typedef for an unsigned integer type

---

Is that guaranteed ? Aren't you only allowed to assume that it will be 'size_type'?

Quote:

---

Originally Posted by JohnW@Wessex

Is that guaranteed ? Aren't you only allowed to assume that it will be 'size_type'?

---

"unsigned integer type" is pretty vague, nobody said it is exactly "unsigned int". unsigned integer type sounds perfectly fine to me.

At worst, I think you can assume that it is at least implicitly convertible to and from unsigned integer type.

Quote:

---

Originally Posted by JohnW@Wessex

Is that guaranteed ?

---

Yes, at least for the standard containers. If you use the default allocator, it actually boils down to size_t.

Thanks for the info

Quote:

---

Originally Posted by laserlight

Yes, at least for the standard containers. If you use the default allocator, it actually boils down to size_t.

---

That begs the question of why anyone should even bother writing something like std::vector<std::string>::size_type instead of size_t.

Quote:

---

Originally Posted by JohnW@Wessex

That begs the question of why anyone should even bother writing something like std::vector<std::string>::size_type instead of size_t.

---

They are leftovers from what allocators were supposed to be, but never quite ended up being.

For example, you also have std::vector<T>::pointer which used to be a typedef for allocator<T>::pointer, but is now just T*.

When allocators were first designed, allocator::pointer, allocator::size_type etc. were not necessarily supposed to be T* and size_t respectively (this was for windows long pointers or something, I don't know). BAck then, since allocator::size_type != size_t, this meant vector::size_type != size_t. This never ended up happening, but the typedef remained.

In today C++, container<T>::size_type is by standard defintion a typedef for size_t. But like everything in C/C++, once inserted in the standard, it can't be removed, you'd break code.

So to answer your question: Today, there is no reason to, but it was originally planned to make a difference.

Have a look at std::vector<bool>::reference in the bool specialisation of std::vector: http://www.cplusplus.com/reference/stl/vector/

I think these typedefs also have to do with using custom containers with algorithms which were written with standard containers in mind. If the templated algorithm uses C::size_type then my container need not use size_t but tells the algorithm which size type to use.

Quote:

---

Originally Posted by codingnewbie

1. Should I name an unchanging variable received as input from the user when starting a program with all CAPS like a constant?

---

I only ever use all CAPS for macros and always prepend some kind of company ID like a mini namespace.

#define RCL_TEXT_AUX(A_,B_) A_##B_
#define RCL_TEXT(C_) RCL_TEXT_AUX(L,C_)

Quote:

---

Originally Posted by codingnewbie

2. When declaring variables at the start of a function, is there any ordering convention I can follow?

---

In functions these should not be declared until needed, but in structures/classes I tend to go from large size to small size in order to make padding less likely.

Quote:

---

Originally Posted by codingnewbie

3. Following from question 2, how about ordering of arguments?

---

Personally I put in-arguments ahead of out-arguments (pointers to multiple results).

Quote:

---

Originally Posted by codingnewbie

4. How do I determine whether to use an int or a size_t?

---

The size_t typedef should be used for indexes into arrays, sizes of objects, and other memory range related things. The sizeof operator returns a size_t for example. Importantly size_t is always able to index the whole range of a pointer even in 64bit environments where an int is only 32bit.