Being an Objective-C coder, I'm so used to descriptive method names such as
[car insertFuelWithAmount:fuelAmount
type:fuelType
causesCarToSelfDestruct:NO];
How would most programmers name a corresponding method in C++? I have two questions in particular:
My copy of "C++ Primer", 4th edition, mentions (p. 46) that gosh_this_is_an_impossibly_long_name_to_type is a "really bad identifier name". This differs from the mentality in Objective-C, which encourages very descriptive names, even if they are long. Why are long ones not appreciated by C++ coders?
Maybe it's not a matter of just migrating blindly, but rather changing one's mindset completely? If so, what changes need to be made?
Feel free to allow some further general thoughts on your own to float along, if you don't mind. (I know this is not a forum for general and vague questions. Hence, I tried to make things a bit more specific above.)
As Fernandes points out you need to find a balance of sorts. But remember that it is all about taste, though most C++ programmers go for the shorter but somewhat descriptive method names.
Using extremely long names, for anything, is never desirable because the code will become practically unreadable. And personally I find it very disturbing to my programmer's eye.
The languages are different, of course, but the focus of your transition phase would be removing the extraneous names. Like with your method above. I've noticed Obj-C programmers use the "WithSomething" extensions here and there. One thing to change here is to get rid of those by using overloading, for instance.
The method you described I would probably write like this:
car.insertFuel<int>(amount, false);
If assuming some amount of fuel in integer form.
As a Objective-C coder I personally create long method names in other programming languages.
When I need to change game from someone else I really have a hard time to understand some code because its encrypted with unreadable method- and variable names.
Nowadays we don't have to watch out for big source-files, se let us be all clear for yourself and for others that may need to change your code.
so for your example I personally would write:
car.insertFuelTypeAndSelfDestruct(fuelAmount, fuelType, NO);
or if you can see the method description I can consider just car.insert
That level of descriptiveness for function parameters is best done by defining types for them, and leaving the function name itself short and readable, for example:
enum class fuel_type { petrol, diesel, coal, coffee };
enum class self_destruct { no, yes };
car.insert(amount, fuel_type::petrol, self_destruct::no);
Since functions can be overloaded for different argument types, this allows other things to be inserted by different overloads:
car.insert(amount, oil_type::crude, self_destruct::yes);
You might want to take this further, and introduce types for numeric parameters as well; especially if you don't have a "type" parameter to overload on:
struct fuel_amount {double litres;};
struct oil_amount {double litres;};
car.insert(fuel_amount{100});
car.insert(oil_amount{3});
Note that these techniques rely on new C++11 features (scoped enumerations and uniform initialisation). Similar techniques are possible, but messier, in older versions of the language.
Personally I (and all places that I worked so far) encourage descriptive method and variable names all over the C++ code. However, most programmers tend to dislike too long names. In such cases, usually a compromise has to be made - sacrificing some of the descriptiveness or thinking of some other words that are shorter or more descriptive in general, in order to cut down the length.
In your case I would do it like this:
car.insertFuelWithAmount(fuelAmount, fuelType, safeDestruct);
Leaving the name of the method as id and skipping the 'causesCarTo' prefix of the last parameter.
If you want to stick with a simple method call, I would do something like:
car.insertFuel(amount, type, false);
Alternatively, you could create a Fuel class with a simple constructor:
class Fuel {
public:
Fuel(int amount, int type, bool selfDestruct)
: amount(amount), type(type), selfDestruct(selfDestruct) {}
int amount;
int type;
bool selfDestruct;
};
car.insert(Fuel(amount, type, false));
You could also create a Fuel class which implements the named parameter idiom:
class Fuel {
public:
Fuel() : amount(0), type(0), selfDestruct(false) {}
Fuel& Amount(int amount) {
this->amount = amount;
return *this;
}
Fuel& Type(int type) {
this->type = type;
return *this;
}
Fuel& SelfDestruct(bool selfDestruct) {
this->selfDestruct = selfDestruct;
return *this;
}
int amount;
int type;
bool selfDestruct;
};
car.insert(Fuel().Amount(amount).Type(type).SelfDestruct(false));
Related
Okay, just about everywhere I read, I read that getters/setters are "evil".
Now, as a programmer who uses getters/setters often in PHP / C#, I do not see how they are alive. I have read that they break encapsulation, etc etc, however, here is a simple example.
class Armor{
int armorValue;
public:
Armor();
Armor(int); //int here represents armor value
int GetArmorValue();
void SetArmorValue(int);
};
Now, lets say getters and setters are "evil".
How are you supposed to change a member variable after initialization.
Example:
Armor arm=Armor(128); //armor with 128 armor value
//for some reason I would like to change this armor value
arm.SetArmorValue(55); //if i do not use getters / setters how is this possible?
Lets say the above is not okay, for whatever reason.
What if my game restricts armor values from 1 to 500. (No armor can have a piece that has more than 500 armor or less than 1 armor).
Now my implementation becomes
void Armor::SetArmor(int tArmValue){
if (tArmValue>=1 && tArmValue<=500)
armorValue=tArmValue;
else
armorValue=1;
}
So, how else would I impose this restriction without using getters/setters?
How else would I modify a property without using getters/setters?
Should armorValue just be a public member variable in case 1, and the getters/setters used in case 2?
Curious. THanks guys
You have misunderstood something. Not using getters/setters breaks encapsulation and exposes implementation details, and can be considered "evil" for some definition of evil.
I guess they can be considered evil in the sense, that without proper IDE/editor support, they are somewhat tediois to write in C++...
One pitfall of C++ is to create non-const reference getter, which allows also modification. That's same as returning a pointer to internal data, and will lock that part of internal implementation, and is really no better than making field public.
Edit: based on comments and other answers, what you heard probably refers to always creating non-private getter and setter for every field. But I would not call that evil either, just stupid ;-)
Being slightly contrarian: yes, getters and setters (aka accessors and mutators) are mostly evil.
The evil here is not, IMO, so much from "breaking encapsulation", as from simply defining a variable to be of one type (e.g., int) when it's really not that type at all. Looking at your example, you're calling Armor an int, but it's really not. While it's undoubtedly an integer, it's certainly not an int, which (among other things) defines a range. While your type is an integer, it's never intended to support the same range as an int at all. If you want Armor to be of a type integer from 1 to 500, define a type to represent that directly, and define Armor as an instance of that type. In this case, since the invariant you want to enforce is defined as part of the type itself, you don't need to tack a setter onto it to try to enforce it.
template <class T, class less=std::less<T> >
class bounded {
const T lower_, upper_;
T val_;
bool check(T const &value) {
return less()(value, lower_) || less()(upper_, value);
}
void assign(T const &value) {
if (check(value))
throw std::domain_error("Out of Range");
val_ = value;
}
public:
bounded(T const &lower, T const &upper)
: lower_(lower), upper_(upper) {}
bounded(bounded const &init)
: lower_(init.lower), upper_(init.upper), val_(init.val_)
{ }
bounded &operator=(T const &v) { assign(v); return *this; }
operator T() const { return val_; }
friend std::istream &operator>>(std::istream &is, bounded &b) {
T temp;
is >> temp;
if (b.check(temp))
is.setstate(std::ios::failbit);
else
b.val_ = temp;
return is;
}
};
With this in place, defining some armor with a range of 1..500 becomes utterly trivial:
bounded<int> armor(1, 500);
Depending on the situation, you might prefer to define (for example) a saturating type where attempting to assign an out of range value is fine, but the value that actually is assigned will simply be the nearest value that is within range.
saturating<int> armor(1, 500);
armor = 1000;
std::cout << armor; // prints "500"
Of course, what I've given above is also a bit bare-bones. For your armor type, it would probably be convenient to support -= (and possibly +=) so an attack would end up something like x.armor -= 10;.
Bottom line: the (or at least "one") major problem with getters and setters is that they usually point to your having defined a variable as being of one type when you really want some other type that happened to be sort of similar in a few ways.
Now, it's true that some languages (e.g., Java) fail to provide the programmer with the tools necessary to write code like that. Here I'm trusting your use of the C++ tag to indicate that you really do want to write C++ though. C++ does provide you with the necessary tools, and (at least IMO) your code will be better off for your making good use of the tools it provides so your type enforces the required semantic constraints while still using clean, natural, readable syntax.
In short: they aren't evil.
It's nothing wrong with them as long as they don't leak out the internal representation. I see no problems here.
A common criticism of get/set functions is that they can be abused by client code to perform operations that logically should be encapsulated in the class. For example, say a client wants to "polish" their armour, and decides the effect is to increase "value" by 20, so they do their little get and set thing and are happy. Then someone other client code elsewhere decides rusty armour should drop the value by 30, and they do their bit. Meanwhile, a dozen other places in client code are also allowing polishing and rusting effects on armour - as well as say "reinforcing" and "cracking", and implementing them directly. There's no central control of this... the maintainer of the armour class has no ability to do things like:
have the rust, polish, reinforce and crack effects apply at most once per piece of armour
tune the number added to or subtract from value for specific logical effects
decide that the new "leather" armour type can't rust, and ignore client attempts to make it do so
On the other hand, if the first client that wanted to make armour rusty couldn't do so through the interface, they'd go to the maintainer of the armour class and say "hey, give me a function to do this", then other people could start using the logical-level "rust" operation, and if it became useful later to do the kinds of things I describe above they could be implemented easily and centrally in the armour class (e.g. by having a separate boolean to say if the armour was rusty, or a separate variable recording the rust effect).
So, the thing with get/set functions is they frustrate the natural evolution of an API of logical functionality, instead distributing logic throughout client code, leading in extremis to an unmaintainable mess.
Your getter/setter looks ok.
The alternative to getter/setters is to make member variables public. To be more precise, group variables into structure without member functions. And operate on this structure within your class
Giving access to members reduces encapsulation, but sometimes it's necessary. And the best way to do it is by means of getters and setters. Some people implement them when no such access is necessary, just because they can and it's a habit.
Getters are evil whenever:
They access directly data members of the class
When you have to add new getter every time you add data to the class
The data behaviour is different in each getter
Good getters would thus do the following:
They forward the request to some other object or collect the data from several places
You can fetch large amounts of data using just one getter
All the data you fetch is handled the same way
Setters on the other hand are evil always.
how else would I impose this restriction without using getters/setters? How else would I modify a property without using getters/setters?
You can check what you read from the variable and if its value is out of range use a predefined value instead (if possible).
You can also resort to dirty hacks such as protecting the memory underneath the variable from writing, catching write attempts and disallowing/ignoring the ones with invalid values. This is going to be cumbersome to implement and expensive to execute. It may be useful for debugging, though.
My current project code base has every unit and its friend refined.
Extract :-
...
typedef int m; // meter
typedef int htz;
typedef int s; // second
...
Good or Bad?
I hate it! Its a pain, there is no benefit, and "m" globally defined, omg!
But I want to state the reason why I hate it, in a bit more of technical/articulate manor... hello readers!
Can people list For/Against arguments for this pattern? Many thanks.
Better to make them custom types, as then you can control conversions and overload operators. Right now, I can do meaningless things like multiply a metre by a hertz. Ideally, m / s would yield a velocity- but it won't. It's meaningless to just typedef them like that.
Presumably they are trying to document intent, but without type safety there is no enforcing it. It is just clutter that increases the barrier of entry for reasoning about the code.
Even if they did try and create type safety, trying to abstract data at low levels just adds complexity. It doesn't make solving problems easier. The variable name describes the contents well enough anyway.
I have recently read Mike McShaffry's Game Coding Complete and noticed the code style I haven't seen elsewhere yet. The more important things I noticed were the names of base classes defining interfaces starting with an I like IActor, protected member variables' names starting with m_ like m_Type and names of virtual methods like VSetId(). To show a bigger, more readable example:
class BaseActor : public IActor
{
friend class BaseGameLogic;
protected: ActorId m_id;
Mat4×4 m_Mat;
int m_Type;
shared_ptr <ActorParams> m_Params;
virtual void VSetID(ActorId id) { m_id = id; }
virtual void VSetMat(const Mat4×4 &newMat) { m_Mat = newMat; }
public:
BaseActor(Mat4×4 mat, int type, shared_ptr<ActorParams> params)
{ m_Mat=mat; m_Type=type; m_Params=params; }
/* more code here */
};
I pretty much like this style: it seems justified and looks like it helps increase the overall readability of the code. The question is: Is it a more-or-less established standard? Is there any more to it than the things I mentioned?
That's called Hungarian Notation. It's encoding information about the variable into the variable name.
For example, m_params means "a member variable called params". IActor means "A class called Actor intended to be used as an ifterface". It is something that is a very hot topic. Most people agree Hungarian Notation is a poor choice, but many will defend what they do as not Hungarian.
That looks very similar to Hungarian Notation. It depends on who you ask, but its a rather lets say "aged" style.
All of that seems fairly common. I dont recognize anyone else using the V prep for virtual methods. But its more about making the code human followable then anything else. Sounds like a good use to me.
Most of the coding I do is in C# and they use the same conventions for the most part. tho it is uncommon to see m_ for the member variables. Thats more common to C/C++ tho I have seen the same convention used in C# or the variables would start with _ alone. which is also a common convention in Objective-C. Something to separate the Property from the Variable that the property uses as a container.
I've seen that, and I'm no game programmer. The 'I' probably indicates that the class is intended to be an interface - all virtual methods and no data members. Using m_ is quite common, but so are other conventions. I think I first saw m_ naming convention in some Microsoft Windows examples in the late 1980s but that's probably not its origin. There are multiple coding standards around that follow these conventions (but differ in other ways) - I can't name any specific ones at the moment, but look around.
The initial I to denote interfaces (and A for abstract classes) isn't such a bad practice, however the m_ prefix to denote member variables is horrid. I believe the reasoning behind it is that it allows the parameters to be named nicer by preventing shadowing of member variables. However you will mainly work with member variables in your class, and the m_ prefix really clutters code, hindering readability. It is much better to just rename the parameter, for example id -> pId, id_, identifier, id_p, p_id, etc.
The V to denote virtual methods might be useful if you somehow declared methods virtual in the parent class but not in the child class, and you desperately need to know whether it is virtual or not, however this is easily fixed by declaring them virtual in the child class as well. Otherwise I do not see any advantage.
class C {
private:
int member_; // here is the underscore I refer to.
}
This underscore is recommended by Google Style Guide and Geosoft's C++ Style Guide.
I understand that there are different opinions and tastes.
I want to ask people who used it or were forced to use it whether they found it beneficial, neutral or harmful for them. And why?
Here is my answer:
I understand ask motivation behind it, but it does not convince me.
I tried it and all I got was a little bit of clutter all over the class, but simpler initialization of members in constructor. I haven't encountered situation where underscore helped to differ between private member variable and other variable (except in mentioned initialization).
In that light I consider this style harmful.
Well since no one mentioned it: adding an underscore to member variable allows you to name your getter and setter with the 'conceptual' name of the variable.
ex:
class MyClass
{
int someMember_;
public:
int someMember() const { return someMember_; }
void someMember( int newValue ) { someMember_ = newValue; }
};
not that I use this style though.
I use "m_" as prefix for normal member variables and "s_" for static member variables.
So the scope is directly visible.
If you need this underscore in order to tell class members from other variables, you probably have too large member functions to instantly see what's a variable/parameter.
I still like it because it often simplifies member function parameter naming:
class person
{
public:
person(const std::string& first_name, const std::string& last_name)
: first_name_(first_name), last_name_(last_name) {}
// .......
private:
std::string first_name_;
std::string last_name_;
};
To me the benefit of this style of decorating member variables is it works well with auto complete functionality of text editors. Having a prefix decoration requires you to type more characters before a solid guess on what you mean can be made.
This is basically a religious argument so you're never going to reach a consensus on this style. FWIW, I use this style for my member variables for reasons already stated by others, e.g.:
class Foo
{
public:
Foo(std::string name, int age) :
name_(name),
age_(age)
{
}
std::string name() const { return name_; }
void name(const std::string& name) { name_ = name; }
int age() const { return age_; }
void age(int age) { age_ = age; }
private:
std::string name_;
int age_;
};
Just adopt something you're happy with and stick with it.
I think it's important to distinguish between class variables and local ones (and global ones if really needed). How you do it, is not important - just be consistent.
class Foo
{
int mMember;
int member_;
int _member;
int m_Member;
};
All styles give you the information you need. As long as you stay with the same style all of the time, no problem. Sometimes other people need to work with your code (e.g. when you create a library, or you work with a community). Then it might be a good idea to stick with the most used style in the C++ community.
Sorry - I can't answer what style that is.
I came up with this style independently early in my C++ coding days (late 80s, early 90s) because I encountered several confusing situations in which I had to keep going back to the class header to figure out which variable was really a member variable.
Once I started seeing other people's C++ code that did the same thing I was rather gratified that I had noticed a problem that other people had and that the solution I adopted for myself was something other people also thought of.
It's not frequently useful, but it's fairly innocuous and when it is useful, it's very useful.
This is also why I really hate the m_ style. It's not innocuous, and I think the added ugliness is not worth the benefit.
I do use an S_ prefix for file scope static variables and class static variables that aren't constants. They are sort of like global variables, and I think their use should be signaled loudly.
This came up in discussion we had where I work but with Java programming. But I think this applies to C++ as well. My answer is that IDE's have a handy function of coloring class member variables. In Eclipse they turn blue. The underscore is superfluous. As another poster put it, "EW, hungarian warts!!". 1980 called and wants it's hungarian notation back.
We follow possibility.com's C++ coding standard, which says to prefix member variables with an 'm', but I've also done some work under Google's style guide.
Like you say, it's not strictly necessary, especially if you have an IDE that assigns different syntax highlighting to member variables. However, I think that some kind of consistent naming scheme, to let you tell at a glance whether or not a variable is a member variable, is very worthwhile:
Simplified parameter naming, as in sbi's answer, is one benefit.
A consistent coding style is important, regardless of which style you pick. Ideally, everyone on the team would use the same coding style, so that you can't tell at a glance who wrote a given section of code. This helps helps when bringing new developers onto the team and with agile practices such as no code ownership and is even more important with open source projects that may attract a variety of contributions.
Most importantly, readability can greatly benefit from having all of the code follow a fairly strict style that makes clear the types of identifiers like this. The difference between being able to tell at a glance that a variable is a member and being able to tell from looking at local variables' declarations may be small, but following a good coding standard will make numerous small differences like this throughout a body of code, and it can make a huge difference in how easy the code is to follow and how easy it is to get started in an unfamiliar section of code.
(You mentioned that you gave this style a try, but if it was only for a part of code and only for code that you were already familiar with, then it's harder to see the readability benefit that following a coding style like this for the entire codebase can bring.)
All of this is in my experience, your mileage may vary, etc.
there is one more "style" which suggests declaring class members as below:
class Foo{
int m_value;
public:
//...
};
i found it usable. but it is just my point of view.
I agree with Tobias that there's a benefit to some convention -- whatever it may be -- to highlighting class variables. On the other hand, I invariably find that such conventions make the code "flow" less well. It's just easier to read "totalPrice = productPrice + salesTax" then "m_totalPrice = l_productPrice + l_salesTax" or whatever.
In the end, I prefer to just leave all the field names undecorated, and have few enough class variables that keeping track of them is not a problem. In constructors and setters, I put a prefix or suffix on the parameter, or in Java I typically distinguish the class variable with "this.", like:
public Foo(int bar)
{
this.bar=bar;
}
(Can you do that in C++? It's been so long I don't remember.)
I agree with you that the underscore variable suffix is not the ideal coding style, and that adding a little complexity into the constructor is better than adding more complexity throughout the entire class.
The other day, I took a look at one of my old Java projects where I had applied the underscore suffix to variable names, and I found that it did make reading the code more difficult. It wasn't too hard to get used to, but I found it to be slightly distracting without adding any real benefit.
I always want to distinguish the class members from the variables. I use the _ as prefix for members and personally speaking this keeps the code clean and readable. Prefixes work fine with the editor's intellisense. Prefixing with m_ or s_ is useful but It looks ugly to me.
I come from a .NET world and I'm new to writting C++. I'm just wondering what are the preferred naming conventions when it comes to naming local variables and struct members.
For example, the legacy code that I've inheritted has alot of these:
struct MyStruct
{
TCHAR szMyChar[STRING_SIZE];
bool bMyBool;
unsigned long ulMyLong;
void* pMyPointer;
MyObject** ppMyObjects;
}
Coming from a C# background I was shocked to see the variables with hungarian notation (I couldn't stop laughing at the pp prefix the first time I saw it).
I would much rather name my variables this way instead (although I'm not sure if capitalizing the first letter is a good convention. I've seen other ways (see links below)):
struct MyStruct
{
TCHAR MyChar[STRING_SIZE];
bool MyBool;
unsigned long MyLong;
void* MyPointer;
MyObject** MyObjects;
}
My question: Is this (the former way) still a preferred way to name variables in C++?
References:
http://geosoft.no/development/cppstyle.html
http://www.syntext.com/books/syntext-cpp-conventions.htm
http://ootips.org/hungarian-notation.html
Thanks!
That kind of Hungarian Notation is fairly useless, and possibly worse than useless if you have to change the type of something. (The proper kind of Hungarian Notation is a different story.)
I suggest you use whatever your group does. If you're the only person working on the program, name them whatever way makes the most sense to you.
The most important thing is to be consistent. If you're working with a legacy code base, name your variables and functions consistently with the naming convention of the legacy code. If you're writing new code that is only interfacing with old code, use your naming convention in the new code, but be consistent with yourself too.
No.
The "wrong hungarian notation" - especially the pp for double indirection - made some sense for early C compilers where you could write
int * i = 17;
int j = ***i;
without even a warning from the compiler (and that might even be valid code on the right hardware...).
The "true hungarian notation" (as linked by head Geek) is IMO still a valid option, but not necessarily preferred. A modern C++ application usually has dozens or hundreds of types, for which you won't find suitable prefixes.
I still use it locally in a few cases where I have to mix e.g. integer and float variables that have very similar or even identical names in the problem domain, e.g.
float fXmin, fXmax, fXpeak; // x values of range and where y=max
int iXmin, iXMax, iXpeak; // respective indices in x axis vector
However, when maintaining legacy code that does follow some conventions consistently (even if loosely), you should stick to the conventions used there - at least in the existing modules / compilation units to be maintained.
My reasoning: The purpose of coding standards is to comply with the principle of least surprise. Using one style consistently is more important than which style you use.
What's to dislike or mock about "ppMyObjects" in this example apart from it being somewhat ugly? I don't have strong opinions either way, but it does communicate useful information at a glance that "MyObjects" does not.
I agree with the other answers here. Either continue using the style that you are given from the handed down for consistency's sake, or come up with a new convention that works for your team. It's important that the team is in agreement, as it's almost guaranteed that you will be changing the same files. Having said that, some things that I found very intuitive in the past:
Class / struct member variables should stand out - I usually prefix them all with m_
Global variables should stand out - usuall prefix with g_
Variables in general should start with lower case
Function names in general should start with upper case
Macros and possibly enums should be all upper case
All names should describe what the function/variable does, and should never describe its type or value.
I'm a hungarian notation person myself, because I find that it lends readability to the code, and I much prefer self-documenting code to comments and lookups.
That said, I think you can make a case for sacrificing your preferred style and some additional maintainability for team unity. I don't buy the argument of consistency for the sake of uniform code readability, especially if your reducing readability for consistency... it just doesn't make sense. Getting along with the people you work with, though, might be worth a bit more confusion on types looking at variables.
Hungarian notation was common among users of the Win32 and MFC APIs. If your predecessors were using that, you can probably best continue using it (even though it sucks). The rest of the C++ world never had this brain-dead convention, so don't use it if you're using something other than those APIs.
I think that you will still find that most shops that program in Visual C++ stick with hungarian notation or at least a watered down version of it. In our shop, half of our app is legacy C++ with a shiny new C# layer on top (with a managed C++ layer in the middle.) Our C++ code continues to use hungarian notation but our C# code uses notation like you presented. I think it is ugly, but it is consistent.
I say, use whatever your team wants for your project. But if you are working on legacy code or joining a team, stick with the style that is present for consistency.
Its all down to personal preference. I've worked for 2 companies both with similar schemes, where member vars are named as m_varName. I've never seen Hungarian notation in use at work, and really don't like it, but again down to preference. My general feel is that IDE's should take care of telling u what type it is, so as long as the name is descriptive enough of what it does ( m_color, m_shouldBeRenamed ), then thats ok. The other thing i do like is a difference between member variable, local var and constant naming, so its easy to see what is happening in a function and where the vars come from.
Member: m_varName
Const: c_varName
local: varName
I also prefer CamelCase, indeed mostly I've seen people using CamelCase in C++. Personaly I don't use any prefixes expect for private/protected members and interfaces:
class MyClass : public IMyInterface {
public:
unsigned int PublicMember;
MyClass() : PublicMember(1), _PrivateMember(0), _ProtectedMember(2) {}
unsigned int PrivateMember() {
return _PrivateMember * 1234; // some senseless calculation here
}
protected:
unsigned int _ProtectedMember;
private:
unsigned int _PrivateMember;
};
// ...
MyClass My;
My.PublicMember = 12345678;
Why I decided to omit prefixes for public members:
Because public members could be accessed directly like in structs and not clash with private names. Instead using underscores I've also seen people using first lower case letter for members.
struct IMyInterface {
virtual void MyVirtualMethod() = 0;
};
Interfaces contains per definition only pure virtual methods that needs to be implemented later. However in most situation I prefer abstract classes, but this is another story.
struct IMyInterfaceAsAbstract abstract {
virtual void MyVirtualMethod() = 0;
virtual void MyImplementedMethod() {}
unsigned int EvenAnPublicMember;
};
See High Integrity C++ Coding Standard Manual for some more inspiration.
My team follows this Google C++ code convention:
This is a sample of variable name:
string table_name; // OK - uses underscore.
string tablename; // OK - all lowercase.
string tableName; // Bad - mixed case.
If you use CamelCase the convention is to Capitalize the first letter
for classes structs and non primitive type names, and lower case the first letter for data members.
Capitalization of methods tends to be a mixed bag, my methods tend to be verbs and are already distingished by parens so I don't capitalize methods.
Personally I don't like to read CamelCase code and prefer underscores lower case for
data and method identifiers, capitalizing types and reserving uppercase for acronyms
and the rare case where I use a macro (warning this is a MACRO).