How would you do your If and else statements

Pages: 1234
ah ok. thanks for clearing that up.
NT3 wrote:
As a general rule, C is assumed to have a coding style like this
C language authors would object to this :)
Yea, there are many types of styles, and I have learned that don`t use ones that others use but use one that you find the most neatest looking.
So I`m going to stick to K&R style.

Maybe K&R looks neater to me, because before C++, I did do a month or so of Java
I think people put way to much thought into picking a style for their code, when in the end it doesn't really matter much unless you only plan on working on projects by yourself.

The reason I say this is because if you work on basically any project that requires you to work with a team you will have little choice on what style you get to use unless you are one of the founding lead programmers. If you aren't you need to adapt to whatever style was chosen for that project, you can't just say well I have always been using this style so I am going to do completely different then everything else in the codebase. That usually won't fly unless you are on a project that has little organization.

So in my opinion sure go find a style that looks best to you for your own projects, but if you plan on doing anything serious be more then willing to change and adapt.

The biggest thing I have learned when programming is that always be willing to change and adapt to the particular problem or circumstance that is at hand. Whether it be what language to use, what style to use, or whatever you need to be able to change.
Last edited on
Yea that is a great point but I cannot decide which to use for my own projects.

{
}
..{
}
Every book, including Bjarne's books, stress picking a style that suits you and be consistent which is why I think people do spend so much time picking a style. It is fine to learn other styles so you are able to work in projects, as pointed out, but most of the code you write is usually for your own projects.
Sometimes, a good style can prevent bugs. Some users know I recently ran into an array problem that was causing huge issues.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const char *token2string_table[] = {
	/* Nothing */ "",
	"CRLF",
	"COLON",
	"NICKNAME",
	"SPACE",
	"SERVERNAME"
	"EXCLAMATION",
	"USER",
	"AT",
	"HOST",
	"CMD_PING",
	"CMD_PONG",
	"CMD_QUIT"
};


There's a problem here... it's missing a comma. Spent nearly a half hour on this. So, I started writing the table like this instead:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const char *token2string_table[] = {
	""/* Nothing */
	,"CRLF"
	,"COLON"
	,"NICKNAME"
	,"SPACE"
	,"SERVERNAME"
	,"EXCLAMATION"
	,"USER"
	,"AT"
	,"HOST"
	,"CMD_PING"
	,"CMD_PONG"
	,"CMD_QUIT"
};


Not sure if I like this or not but when you have various tables like this, it's easier to know there's a missing comma as it would be miss aligned.
Yea BHX you do have a point there

@NoXzema

That is pretty clever :)
Every book, including Bjarne's books, stress picking a style that suits you and be consistent which is why I think people do spend so much time picking a style.


I agree that is quite important to pick a style that you like and to definitely be consistent with it.

Never meant to imply that picking a good style for you person projects is a bad thing, more just pointing out that after you get past the hobby/learning stage you don't have much choice usually on a style to use.

It is fine to learn other styles so you are able to work in projects, as pointed out, but most of the code you write is usually for your own projects.


Personally I disagree with that statement. I am sure when you are just learning the language you will mainly stick to your own projects, but I find that after a certain stage that a majority of programmers will mostly be coding on larger projects in a team (Whether it be for a job or just a hobbyist on a open source project).

That has been my experiences at least. Actually had a conversation recently with some people about this and most said that they like working on team projects because of the challenges they provide that aren't available in smaller projects.

Personally I spend most of my time in team projects because there is usually always someone that is more experienced then be in a certain aspect and I can learn from them and they can learn from me.

But I guess this really all depends on the individual and we can't say that most people spend most of their time on personal projects or group projects.
I usually do:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const char *token2string_table[] = {
	/*Nothing*/ "",
	"CRLF"        ,
	"COLON"       ,
	"NICKNAME"    ,
	"SPACE"       ,
	"SERVERNAME"  ,
	"EXCLAMATION" ,
	"USER"        ,
	"AT"          ,
	"HOST"        ,
	"CMD_PING"    ,
	"CMD_PONG"    ,
	"CMD_QUIT"    ,
};
Last edited on
I let the IDE do its work
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const char *token2string_table[] = {
	/* Nothing */ "",
	"CRLF",
	"COLON",
	"NICKNAME",
	"SPACE",
	"SERVERNAME"
		"EXCLAMATION",
	"USER",
	"AT",
	"HOST",
	"CMD_PING",
	"CMD_PONG",
	"CMD_QUIT"
};
using indent
1
2
3
4
5
6
7
8
9
10
11
12
13
14
const char *token2string_table[] = {
  /* Nothing */ "",
  "CRLF",
  "COLON",
  "NICKNAME",
  "SPACE",
  "SERVERNAME" "EXCLAMATION",
  "USER",
  "AT",
  "HOST",
  "CMD_PING",
  "CMD_PONG",
  "CMD_QUIT"
};
What you guys are doing seems like a waste of lines. I would usually put the initializations of array on one line, and only go to the next line if I have to use the side scroll bar.
Drrockso wrote:
What you guys are doing seems like a waste of lines. I would usually put the initializations of array on one line, and only go to the next line if I have to use the side scroll bar.


While it might indeed be a waste of lines compared to your way the increased readability is 10x more beneficial then saving a few lines in my opinion. It might just be me but I never understood the argument of saving lines in code, I always feel that readability is much more important then having to scroll a bit more.

Code is much harder to read then write. You can write code and easily understand the flow of your program and everything about it, but if someone else comes into the project it is much harder for them to read the code and understand it. Or if you leave the project for a few months and come back it will be much harder for your to read.

This is why I generally don't like when code is much more complicated then it needs to be. For example when people use a truly elegant solution over the more simple one while both preform the same. The elegant one and the simple one will preform exactly the same but one is much harder to read and understand on first glance.

The most important aspect of any style I believe is how readable your code is, always try to strive towards the most readable solutions to your problem (Don't read this wrong as to sacrifice a better solution that preforms badly just to get it more readable).
I think it looks neater on separate lines.

@ne555

What IDE do you use, I still do not understand using indent
For me it is like reading a book, when you look for the next line you might look at the wrong place and then lose your place. But if you are involved in a project then yes, go with the flow.
I like the comma to the left:
1
2
3
4
5
6
7
8
9
10
MyClass::MyClass()
: member1(blah)
, member2(blah)
, member3(blah)
{
    int x
    ,   y
    ,   z;
    //...
}
Mainly because it's easier to line up the commas than with the comma after.
^^ Plus when you add a line you don't need to remember to tack a comma to the end of the previous one.
I do not do what LB did for declaring his int, I think that declaring them like this is more readable

int x, y, x;
^That's frowned upon in several large (opensource) projects.
What, the redefining x bit? :)
Pages: 1234