Question regarding references.

Started by
11 comments, last by Zahlman 16 years, 2 months ago
Quote:Original post by SeymourClearly
Haha, you've got me there mate. Cheers for that and for pointing out the problem with my method. :)


There's really nothing wrong with your method of naming classes CRoomManager. Some people don't like it, but it's not a problem as long as you remain consistent (i.e. make sure to prefix every class with C). The idea of using a convention such as this is so people can look at your code and immediately know what they're looking at. Antheus may not like it, he/she may not personally prefer using the style, but if you're used to it and you find it helpful to remember what your classes are, then you should continue to do so.

What really matters is that you do what you employer asks. If they don't want you to prefix your classes with a C, then you better be able to do that without any problem. And vice versa, if they want you to add a C prefix, you better be able to do it.

So, all I'm trying to say is that there's no harm in doing what you're doing, just know that not everybody has the same programming habits and that one day you might have to change that habit.
Advertisement
Yeah true enough. It does me a favour right now anyways. I had CTS a while back and a little flare up of it recently so any typing I can save is a good thing, even if this is pretty minor.
Quote:Original post by jyk
Are you positive about that? I was under the impression that map::operator[]() inserts the element if it does not already exist.


It does, and it's deliberately designed for that purpose, because the behaviour is often quite convenient. The reason for doing things with .find() manually is to avoid altering the map when you are only doing a lookup (that messes with your const-correctness, and leaves garbage default-constructed values in your map; even if they don't interfere with your logic, they waste memory.)

Quote:Original post by Shakedown
There's really nothing wrong with your method of naming classes CRoomManager. Some people don't like it, but it's not a problem as long as you remain consistent (i.e. make sure to prefix every class with C).


Consistency certainly cannot be used by itself to justify naming decisions. Imagine if I went through the code and reversed all the identifier names? Hey, I did it to all of them, right?

Quote:The idea of using a convention such as this is so people can look at your code and immediately know what they're looking at. Antheus may not like it, he/she may not personally prefer using the style, but if you're used to it and you find it helpful to remember what your classes are, then you should continue to do so.


Let's say we encounter the following line of code:

Foo bar = baz;


Never mind the capitalization, or presence or absence of a C: I know 'Foo' must be a type, simply by context. It could be either a typedef, a class or a struct.

Now, here's the question: why do I care? To see how it is used, I just look at the surrounding code. To see how it can be used, I have to look up its definition anyway. In no case does the information "oh, by the way, this is a class, and not a struct or a typedef" help me.

Quote:What really matters is that you do what you employer asks. If they don't want you to prefix your classes with a C, then you better be able to do that without any problem. And vice versa, if they want you to add a C prefix, you better be able to do it.


I'm sorry; I can't agree. The reason that bad coding practices persist is that people who are in a position to promote them are allowed to get away with it.

This topic is closed to new replies.

Advertisement