-
October 26th, 2010, 02:14 AM
#1
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
-
October 26th, 2010, 02:36 AM
#2
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
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.
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.
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.
-
October 26th, 2010, 03:03 AM
#3
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
There are no hard and fast rules for formatting C++.
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.
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.
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.
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.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
October 26th, 2010, 06:56 AM
#4
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
October 26th, 2010, 07:29 AM
#5
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
October 26th, 2010, 09:53 AM
#6
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
-
October 27th, 2010, 02:25 AM
#7
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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'?
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
October 27th, 2010, 02:48 AM
#8
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
October 27th, 2010, 11:26 AM
#9
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
-
October 28th, 2010, 01:53 AM
#10
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
-
October 28th, 2010, 03:09 AM
#11
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
October 28th, 2010, 03:36 AM
#12
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
Last edited by monarch_dodra; October 28th, 2010 at 03:40 AM.
Reason: Removed those dang smilleys
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
October 28th, 2010, 11:28 AM
#13
Re: Few Qs about Cconventions (variable naming and variable/argument ordering etc)
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.
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_)
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.
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).
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.
Last edited by Zaccheus; October 28th, 2010 at 11:50 AM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|