Sign in to follow this  

Question about style

This topic is 4864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been going through the forums and I've noticed a lot of htings related to specific coding styles in the industry. I am planning on getting into the industry (not specifically game programming) and I did not want to develop any bad styles that might stop me from getting far. (I use C++). I've been reading things like you shouldn't be doing
using namespace std; 
I can change that style of mine, but I don't want to be writing
std::cout << "hi" << std::endl;
std::cin >> i; 
. I don't want to be writing that out constantly. Is there anyway to get around all that and still keep good coding style. Also I read that when declaring classes that most of the industry does:
class CSomething
. Where you put a capital C infront of the class name and capitalize the first letter in the name. Is this a good habit to develop? Any other coding styles/habits you guys think I should use would be appreciated. Thanks. -MJ

Share this post


Link to post
Share on other sites
Not sure about the namespaces, but as for the classes sticking a "C" in front of your classes is generally a good idea. For instance,

class CMyfunc {
}
void Myfunc() {
}

You'll be able to tell what's a class and what's not. Most C++ programmers do this, not just game C++ programmers.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
why is "using" using namespace a bad thing?

all bad coding styles are bad for a reason,
try to find why sonething should or should not be
done before adopting a style,
not only will you knowledge increase but you will not be following a style or practice that is merely the preference, or bad idea at times, of someone else.

Share this post


Link to post
Share on other sites
The thing with "using namespace std" is that in the industry, you won't really be using "cout" or "cin" because you won't be writing console apps. It's really a matter of choice anyways. I hate prefixing everything with "std::". The class thing is totally a matter of choice to. Any company you get a job at will just want to see that you can write cleanly. Use your own judgement there. Companies enforce their own coding style, so when you get a job they'll tell you exactly what style to use.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
for things like naming conventions,
use what make the most sense to you,
but try to get into the habit of being consistent,
because most companies have there own internal
conventions, and they will expect you to be consistent
those.

Share this post


Link to post
Share on other sites
Quote:
Original post by aaroncox1234
The thing with "using namespace std" is that in the industry, you won't really be using "cout" or "cin" because you won't be writing console apps. It's really a matter of choice anyways. I hate prefixing everything with "std::". The class thing is totally a matter of choice to. Any company you get a job at will just want to see that you can write cleanly. Use your own judgement there. Companies enforce their own coding style, so when you get a job they'll tell you exactly what style to use.


I beg to differ. There will be times when one will need to write console apps in the industry. For instance, writing servers. It would take a bit less memory if no GUI were present with the server app.

Share this post


Link to post
Share on other sites
Personally I hate it when people prefix things by what they are. Any half-decent IDE can tell you that when you hover your mouse over your variable. I have started prefixing member variables with m_ to make them stand out more in large functions, but C in front of classes...ugh.

Share this post


Link to post
Share on other sites
thanks guys. I think I'll develop my own style as long as theres nothing wrong with it. And for now I'll still "use" using namespace std. And I'll also start working on the way to declare classes.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bbalstrzmj90
Hungarian notation is pretty much for windows right?


Not really, I guess. Just because it's not windows, doesn't mean it doesn't have pointers (prefix: p), classes (prefix: C), or other things that hungarian notation uses prefixes for.

Share this post


Link to post
Share on other sites
Quote:
Not sure about the namespaces, but as for the classes sticking a "C" in front of your classes is generally a good idea. For instance,

class CMyfunc {
}
void Myfunc() {
}

You'll be able to tell what's a class and what's not. Most C++ programmers do this, not just game C++ programmers.


I don't use "C" in front of the class' name, because it makes the names ugly. And the recognition value is not as high as you may think. After all, you're supposed to know that you are using a class while you do.

My personal style goes as follows:
-
-use as few comments as possible, name as well as possible.
-bool dont_fear_long_variable_names = true;
-variables are in lowercase if they are local
-they are lowercase, words separated with an underscore _
-private class variables have underscore _before them
-static variables have 'static_' in before their names
-global variables SHOULD BE FEW and clearly be flagged (this is one of the rare occasions where I put a capital letter somewhere... in this case 'G' or 'Global' in front of the global variable.)
-all DATA should be WELL DOCUMENTED as well as CLEARLY named (can't stress this enough)
if a class is like a struct/a value type, it may be a struct if it is really only a dataholder
-if it has behaviour, and is to be used as a value type, it must implement the complete value object behaviour (approbiate operators, casts and constructors have to be provided)
-value-like types are named all_lowerscore.
-'complex' types which have special construction/destruction semantics, are NamedLikeSo, and eventually provide private/protected constructors & destructors and a static factory method
-functions begin lowercase and the first letters of following words are uppercase
-global and static constants are ALL_UPPERCASE
-use const as much as possible (your code will be probably less buggy, not that I want to say you write buggy code ;))
-intend carefully, and use braces {} for all loops and if-conditions
-think before you derive
-if you don't have virtual functions, don't derive
-if you do, be sure to have a virtual destructor
-think about the copy semantics of an object: will it be copied, for example by STL algorithms? Then provide copy and default constructors, assignment operator and double-check the destructor.

Anything I forgot?
Well, maybe alot :)
Also, inform me if I have induced any foul thoughts.

Thermo

Share this post


Link to post
Share on other sites
Quote:
Original post by aaroncox1234
The thing with "using namespace std" is that in the industry, you won't really be using "cout" or "cin" because you won't be writing console apps. It's really a matter of choice anyways. I hate prefixing everything with "std::".


I'd argue that if you put "using namespace std;" into the code that uses std namespaces will potentially polute the namespace and cause conflicting symbols. For example, imagine in your game you have a list, map, vector, etc class: how will you, the compiler or anyone else know that: vector vector3; and vector<int> intarray; are separate. The problem would get worse if you want to bring a few libraries together and they all declared their own "Node" type within their namespace. Generally, if you're using code from another namespace within a namespace, it makes good sense and clean code to preserve the original namespacing and not be lazy and use the 'using namespace' directive.

As for Hungarian Notation, Microsoft used to use it in all their projects - it can be helpful, but when you have variables and types like 'spUnkIter' it can become confusing. I use a hybrid of Hungarian and "whatever gets the point across" notation. It really doesn't matter, as long as it's consistent throught your code and understandable to you and whoever else is maintaining it.

Share this post


Link to post
Share on other sites
In my courses for programming at University they tell you every line should have a comment. That really is for the coders who can't code properly and who code messy. If you are able to label ever piece of your code properly then even a layman should be able to understand what you are doing (in general). I personally never use comments unless they are absolutely necessary and even though my professor has repeatedly told the class to use comments I never got docked marks.

Share this post


Link to post
Share on other sites
Quote:
Original post by TerlenthIn my courses for programming at University they tell you every line should have a comment...

That is excessive of course, but the purpose is get newb programmers like Terlenth in the good habit of writing plenty of comments.
Quote:
Original post by Terlenth... That really is for the coders who can't code properly and who code messy. If you are able to label ever piece of your code properly then even a layman should be able to understand what you are doing (in general)...
That is not true. Although it may be possible to eventually understand what some code is doing by examining each and every nut and bolt, it would be so much easier if there was a short bit of text explaining it. And how would the code explain things like its purpose, its assumptions, and its limitations?

Quote:
Original post by Terlenth
... I personally never use comments unless they are absolutely necessary...
That is because you have never had to work on a large project with other people. If you aren't writing code that needs lots of comments, then you are just working on trivial stuff.

Share this post


Link to post
Share on other sites
John, I would like to make a couple replies to the statements you are making about me.

1. I am not a newb coder. I have been coding for approximately 5 years now mainly dealing with console programs but still doing fairly large works.

2. I have done a major project where myself and a friend of mine created a Java chat server. Similar to an MSN server. Didn't use comments.

3. The way that I use variable, function, etc labels is almost similar to writing comments.

ie. int num_of_lines; int change_num_lines (int num_of_passes)

I do not appreciate you making assumptions about my programming skills or about the level at which I program. I happen to be taking Computer Science at University in which if I were not able to program well and cleanly I would not have passed the assignments or the courses.

Edit: I would also like to mention that I am only in University so maybe I have done massive projects that deal with megabytes of code. But my girlfriend (who happens to be in french and knows little about coding) is able to read the code I have written and understand what it is supposed to do. She can't debug it but that is because she doesn't know programming. That should say something.

Share this post


Link to post
Share on other sites
Quote:

Quote:
Original post by Terlenth... That really is for the coders who can't code properly and who code messy. If you are able to label ever piece of your code properly then even a layman should be able to understand what you are doing (in general)...

I agree. However, writing such precious code is something most of us hardly find time to.

Quote:

That is not true. Although it may be possible to eventually understand what some code is doing by examining each and every nut and bolt, it would be so much easier if there was a short bit of text explaining it. And how would the code explain things like its purpose, its assumptions, and its limitations?

I agree too. With normal code, commenting surely counts.
Concerning your last question: It is, as Terlenth said, possible to write code that every intelligent person can understand by merly browsing through. This is the virtue of good programmers.
Although I would not consider myself beeing good in that sense, I would rather rename veriables and reorder functions and expressions in the time you would probably spend writing comments.

Thermo

Share this post


Link to post
Share on other sites
Use whatever coding style you prefer. The company you end up working for will probably use it's own coding style, so as long as you're comfortable switching you should be fine.
Quote:

In my courses for programming at University they tell you every line should have a comment.

That is extremely excessive, seeing as how commenting what a piece of code does is Code Smell.
Quote:

I agree. However, writing such precious code is something most of us hardly find time to.

Writing good code should be no harder than writing comments that explain what the code does. It's not very hard, honostly.

Share this post


Link to post
Share on other sites
Quote:
Writing good code should be no harder than writing comments that explain what the code does. It's not very hard, honostly.


May I quote myself in response?
Quote:
I would rather rename veriables and reorder functions and expressions in the time you would probably spend writing comments


Still it is a time-consuming job, and it is too easy to fall into hacking-mindstate and messing up one's design. At least, for myself, I find myself coding in 2 kinds of style:
1. slowly, carefully, adhering to object design and analysis, refactoring often, crawling, producing "da code"
2. live fast, die young, have a messy looking sourcecode

Thermo

Share this post


Link to post
Share on other sites
Quote:

May I quote myself in response?

Quote:
I would rather rename veriables and reorder functions and expressions in the time you would probably spend writing comments

I did notice that you said that before I posted, but I dismissed as a really big type or something :/
Quote:

Still it is a time-consuming job, and it is too easy to fall into hacking-mindstate and messing up one's design. At least, for myself, I find myself coding in 2 kinds of style:
1. slowly, carefully, adhering to object design and analysis, refactoring often, crawling, producing "da code"
2. live fast, die young, have a messy looking sourcecode

I don't find it very time consuming. If you already commented what it does, you should therefore know what it does, and how to make it more explicit. I remember once I coded a game without stopping once to compile it. Let's just say I didn't have fun the following 2 weeks when I had to debug it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Terlenth
1. I am not a newb coder. I have been coding for approximately 5 years now mainly dealing with console programs but still doing fairly large works.
Ok, so maybe not quite a newb, but you haven't even finished college yet. I'm not trying to put you down, but you still have a lot to learn.
Quote:
Original post by Terlenth
2. I have done a major project where myself and a friend of mine created a Java chat server. Similar to an MSN server. Didn't use comments.
You and one other person writing a chat server is not a major project.

Quote:
Original post by Terlenth
3. The way that I use variable, function, etc labels is almost similar to writing comments.
That is respectable, but using well-named symbols is not sufficient except in trivial code. Again, how can code with well-named symbols possibly describe its purpose, its architecture, its limitations, and its assumptions?

Share this post


Link to post
Share on other sites
I agree that I don't have all the experience in the world. I also understand that you probably don't hold College/University students in the highest regards when it comes to programming skills (normally because most of them feel that its the easy way through university cause they remember it as being the easy way out).

And, I also understand that you don't view the chat server as a major project, but to someone who is only 19 that is a pretty big accomplishment (especially since it was cross platform and would work with 2 clients 1 VB based and the other Java based).

As for my coding style, what I try to do is make my code as clear as possible. If I can't do that with my code labels then I will comment it. That's when it becomes necessary. I also realize that I will probably have to comment more when it comes to larger projects but again that is when my code become more complex and it requires the comments.

Edit: By the way John, by your definition then of a newb it probably makes the majority of the members of this site newbs if you mean that in order to graduate from newb status you have to be either graduated College or in College

Share this post


Link to post
Share on other sites
You should comment complex code. Try to read a huge project NOT programmed by yourself with no comments and see where you get. Your company will thank you. Do you honestly think that computer languages have been putting the feature of commenting in for no reason whatsoever? Commenting is NOT for NEWBIES, it's for complex code. PERIOD
What happens in the industry when some poor person has to edit/update/fix/patch your code? Don't you want to make their job easier by commenting? You can't pretent your code can be perfect always. What might seem obvious to you, may not be to others, and that's not because they are less intellegent. Please bear that in mind. Your lecturer might have a point. Commenting is good practice, if you expect others to be able to read your code efficiently and easily. No one wants to read every line of code to know what a function does.

P.S. Obviously don't over comment, not every line needs comments.

Share this post


Link to post
Share on other sites

This topic is 4864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this