Ogre Forums

Posted: **Tue Jan 14, 2014 7:50 pm**

Am I the only one using K&R style? Do other coders find it super annoying to work within that style?

Someone made fun of my style and hurt my feelings

hahaha not really, but I was wondering if I'm the only one and missed some sort of C++ memo about this. Not trying to start a religious war ... all opinions welcome

Posted: **Wed Jan 15, 2014 10:47 am**

Are you kidding?

K&R RULEZ!

Posted: **Wed Jan 15, 2014 10:59 am**

I typically use Allman style, or at least a close proximity to it.

Posted: **Wed Jan 15, 2014 1:34 pm**

I use a mix. I've tried several styles through years and ended up mixing styles depending on the kind of code.
But it's very specific.
Here is a typical example:

Code: Select all

void FocusPointView::Impl::input_update( const view::InputState& input_state )
	{
		using namespace view;
		
		const auto& keyboard = input_state.keyboard();

		if( keyboard.is_just_down( KEY_F4 ) ) show();
		if( keyboard.is_just_down( KEY_F5 ) ) hide();

		if( keyboard.is_pressed( KEY_J ) ) rotate_longitude_left();
		if( keyboard.is_pressed( KEY_L ) ) rotate_longitude_right();
		if( keyboard.is_pressed( KEY_I ) ) rotate_latitude_up();
		if( keyboard.is_pressed( KEY_K ) ) rotate_latitude_down();
		if( keyboard.is_pressed( KEY_Y ) ) move_away();
		if( keyboard.is_pressed( KEY_H ) ) move_closer();
		
		if( keyboard.is_any_shift_hold() )
		{
			if( keyboard.is_just_down( KEY_X ) )
			{
				m_workqueue.push( [&] {
					m_focus_point.relocate_in_world( SphereVector::UNIT_X );
				} );
			}

			if( keyboard.is_just_down( KEY_C ) )
			{
				m_workqueue.push( [&] {
					m_focus_point.relocate_in_world( SphereVector::UNIT_Y );
				} );
			}

			if( keyboard.is_just_down( KEY_V ) )
			{
				m_workqueue.push( [&] {
					m_focus_point.relocate_in_world( SphereVector::UNIT_Z );
				} );
			}
		}
		else 
		{
			if( keyboard.is_just_down( KEY_X ) )
			{
				m_workqueue.push( [&] {
					m_focus_point.relocate( SphereVector::UNIT_X );
				} );
			}

			if( keyboard.is_just_down( KEY_C ) )
			{
				m_workqueue.push( [&] {
					m_focus_point.relocate( SphereVector::UNIT_Y );
				} );
			}

			if( keyboard.is_just_down( KEY_V ) )
			{
				m_workqueue.push( [&] {
					m_focus_point.relocate( SphereVector::UNIT_Z );
				} );
			}
		}


	}

Notice that
- types use UpperCamelCase;
- other names are lower_case_with_underscore;
- indent style is ...err...I'm not sure what's the name of this style, Allman?
- except with lambdas where it's K&R.

Posted: **Wed Jan 15, 2014 3:18 pm**

Thanks for feedback!

Allman or a variation is what I see in almost every C++ project. I think I'm going to switch the style of my framework in anticipation of complaints about K&R. I've never had a problem dictating K&R in C projects, but this is my first commercial C++ project and since style isn't too important to me I think I'll move to what I see being commonly used. I doubt I'll end up being technical lead for a bunch of ex kernel programmers in this project

And the productivity of my colleagues is of greater concern to me than my own ... although I think the coders making claims about how bad a certain style is, or how slow it makes them is a load of bull. Still, one less thing for people to gang up on me about at the drinking fountain.

Don't worry mmixLinus ... I'll still secretly *think* in K&R

Posted: **Thu Jan 16, 2014 9:55 am**

I used to not care where { and } started but I had to work with a blind programmer at Microsoft for 3 weeks and he made us all put { and } on new line as it made coding faster for him. The reason is he can trust a { and } is on a new line so he can skip control blocked he doesn't need to listen to. So it { and } always on a new line to be blind coder friendly

Posted: **Thu Jan 16, 2014 11:36 am**

hehe yeah, it helps to be able to adapt to the coding style "at hand". For example, I work as Android platform (ie native/C++) programmer, and needless to say, the codebase is contributed to by a fair amount of people and organisations. When contributing patches, our policy is to stick with the formatting/style of the surrounding code.

HOWEVER, I really think K&R is (one of) the prettiest formats.

I will most likely put { at the EOL.
i will NEVER put spaces inside ( parentheses ), (sorry Klaim ),
and ALWAYS put a space between reserved word and left parenthesis (sorry again Klaim )

One thing I do at work but not at home (funny way of phrasing it?) is put spaces around operators. I WILL at home, but only to emphasize precedence.

At work

Code: Select all

{
    int iPixelPos = yPos * scrWidth + xPos * iMult;
}

At home

Code: Select all

{
    int iPixelPos = yPos*scrWidth + xPos*iMult;
}

Minute details, but I'm nonetheless aware of them

Posted: **Thu Jan 16, 2014 1:28 pm**

I should add perhaps that my choice is for aesthetic reasons. I don't really believe in minimizing bugs by choosing a particular formatting. It may happen of course (formatting-induced bugs) but they are so extremely rare, that re-learning a different wheel to minimize bugs has little merit (has NO merit!!). Those bugs are probably more common if you're a beginner, I suppose.

Each programmer for him&herself! Ftw!

Posted: **Thu Jan 16, 2014 2:28 pm**

Zonder wrote:I used to not care where { and } started but I had to work with a blind programmer at Microsoft for 3 weeks and he made us all put { and } on new line as it made coding faster for him. The reason is he can trust a { and } is on a new line so he can skip control blocked he doesn't need to listen to. So it { and } always on a new line to be blind coder friendly

Oh that's very interesting actually. That's a case where I'd actually believe a coder that the style really affects their productivity. We had a blind coder on the FreeSWITCH project but I guess he just struggled through K&R. Also I doubt we would have changed styles ... C projects like that can be pretty hardcore about the style, with some coders using emacs/vim in terminal windows and feeling religious about certain things. We followed the linux kernel style.

mmixLinus wrote:I should add perhaps that my choice is for aesthetic reasons. I don't really believe in minimizing bugs by choosing a particular formatting.

Yeah style is mainly about readability via consistency of the codebase. Although, I have actually seen coders add a statement to a conditional block with no {} lol

Posted: **Thu Jan 16, 2014 6:07 pm**

Yeah don't worry about these kind of choices. Depending on the company you'll meet different imposed styles and as long as everyone is using the company style it's ok. Same thing for personal projects and open source ones.
I'm still experimenting different styles each time I start a new small project, just to play with the ideas.

Posted: **Thu Jan 16, 2014 6:26 pm**

Klaim wrote:Yeah don't worry about these kind of choices. Depending on the company you'll meet different imposed styles and as long as everyone is using the company style it's ok. Same thing for personal projects and open source ones.
I'm still experimenting different styles each time I start a new small project, just to play with the ideas.

Shakespeare wrote:... there is nothing either good or bad, but thinking makes it so

I do agree with you that this choice isn't really that important (or at least that's how I feel ... some colleagues I have asked seem to feel differently). Just the company in question is my company, and if people think K&R is even the slightest bit restrictive then that is enough for me not to force it on them. Also not a single one of the libraries/projects I am using is K&R: Ogre/Ogitor, Bullet, Cricket, Recast/Detour. And I really want to contribute back to some of them one day without messing up their style too badly

It just seems quite uncommon for C++. If this was a C project I'd force everyone to use K&R and wouldn't hear of it if anyone had a problem hehe

Posted: **Thu Jan 16, 2014 6:27 pm**

My own tastes... I think K&R looks ugly. It doesn't sit in my head right. It feels all jumbled up. I like Allman.

Posted: **Thu Jan 16, 2014 6:29 pm**

mkultra333 wrote:My own tastes... I think K&R looks ugly. It doesn't sit in my head right. It feels all jumbled up. I like Allman.

Yeah that's exactly what I've heard from a few people. Which is why I'm definitely going to switch now and avoid any kind of friction, since I personally don't care what style is used. I used something close to Allman in C myself before doing some kernel work and joining a few large C projects in K&R.

Posted: **Thu Jan 16, 2014 7:33 pm**

mmixLinus wrote:One thing I do at work but not at home (funny way of phrasing it?) is put spaces around operators.

That formatting drives me nuts

! I think that it makes code really much harder to read and grasp quickly.

mkultra333 wrote:My own tastes... I think K&R looks ugly. It doesn't sit in my head right. It feels all jumbled up. I like Allman.

+1: Again I find K&R much harder to read / grasp. With Allman I can easily spot where a block starts and ends just by the { and }. With K&R you still have the indentation level, but that just seems to not be enough for my brain

. But I guess that is mainly due to not being used to it.

Posted: **Thu Jan 16, 2014 7:41 pm**

Oooh another + for Allman haha. I can see a clear trend. Thanks again for feedback this really helped me in making my own decision.

spacegaier wrote:With Allman I can easily spot where a block starts and ends just by the { and }. With K&R you still have the indentation level, but that just seems to not be enough for my brain

Just wanted to note, the linux kernel overcomes this by forcing 8 width tabs which make blocks very clear. Of course, then there are all new complaints about the tabs being too wide

Posted: **Thu Jan 16, 2014 10:24 pm**

Tabs at 8? That's crazy.

Posted: **Thu Jan 16, 2014 10:55 pm**

Funny, I far prefer to have spaces after ({[ and before )}] and between operators because I can read lines easily that way. (It also makes me feel like someone very old *__* )
But sometime I do prefer to not to this, in some very specific context, some functions call or long calculus.

So I keep my rule of thumb until I find it unreadable then I allow myself to break the rule.

That being said, once I start using something like Clang Format, I think it will be very hard to do so (or maybe they have some special mode to allow that).

Also, I tried both tabs=4spaces and tabs = tabs chars and for a long time I kept tabs = tabs chars.
These days I feel like it's not good enough because I tend to work with a lot of different text editors on different projects and they all
don't display tabs the right way.
So I'm progressively switching to tabs = 4 spaces for all the projects I master.
The good thing is that so far nobody worked with me on my project, so I can change this kind of rule as I wish for now. That's also the bad thing, as I don't have other people checking my code (even with OSS

).

Posted: **Thu Jan 16, 2014 11:02 pm**

Kojack wrote:Tabs at 8? That's crazy.

KernelStyleGuide wrote: Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

Hahaha

PS - I don't actually agree, but it certainly works for kernel code

Posted: **Fri Jan 17, 2014 12:07 am**

Well, it does force you to avoid deep scopes, as there is also the limit of characters per line they impose if I remember correctly.

I think that this_style_also_force_people_to_avoid LongNamesOfVariablesHardToRead.

Posted: **Fri Jan 17, 2014 12:32 am**

LOL Klaim ... and yes because many ppl work in emacs or vim terminals the width limit is 80, though it's not a hard rule. It is broken in places for various sensible reasons. And yes the style guide literally says if you scope too deep you are doing it wrong haha. Plenty of people have complained about the tab width and been told that. They are crazy dictators, but they are funny about it sometimes.

Posted: **Fri Jan 17, 2014 12:57 am**

Personally I don't mind, it's still all about uniformity of the code. A bit like Python helping killing any formatting discussion simply by removing any possibility of doing something else than the compiler's formatting.
I guess it would help a lot of productivity issues if there was no religious war about formatting.

Posted: **Fri Jan 17, 2014 9:08 am**

I'm a big K&R fan.

Have tried experimenting with other styles, but old habits die hard.

I don't necessarily think my style is better than anyone else's. It's just the most comfortable to me so I use it.

Posted: **Tue Jan 21, 2014 8:34 am**

They say you are what you program... and I'm 100% Allman!

Posted: **Wed Jan 22, 2014 9:23 am**

Another Allman Acolyte here.

I've always been impressed by how much content the Ogre Coding Standards doc has crammed into such a small document http://ogrehg.googlecode.com/hg/Docs/Co ... dards.html. Google have a good one too http://google-styleguide.googlecode.com ... pguide.xml

From the Ogre Standards

3.Always insert spaces in between operators and operands (x + y, not x+y)
4.Use parenthesis to make the operator precedence unambiguous, even when it is not required ((x * y) + 1, not x * y + 1)

That makes for nice real readable code but they're the most likely for me to ignore due to habit and laziness.

Another thing I really like doing is fully bracing even simple conditionals

Code: Select all

if (x)
{
   stuff();
}

as opposed to

Code: Select all

if (x)
   stuff();

I've been burnt by this sort of thing when I go back to some code and "just make a quick change" by adding in another command and then wonder why it's being run all the time.

Posted: **Thu Jan 23, 2014 1:36 am**

I always hear about the styles... While it is important to at least follow the style if you are in a company or working with a team (say modifying ogre source and submitting patches), in general, I find myself with a modified Allman style. I'm not even sure why? I just use that... Sometimes I forget...

http://en.wikipedia.org/wiki/Indent_style

For sure, I don't like curly bracket next to the if and I don't like a separate word to be lowercase.

Code: Select all

if (x == 0) { 
      dosomething();
}

I prefer if I use brackets

Code: Select all

if (x == 0)
{
    doSomething(); 
}

Of course, sometimes, I violate my own style... and I go with DoSomething ...

also, if is only one statement, I just go with

Code: Select all

if (x == 0)
   doSomething();

As far as variable and functions naming, I try not use underscore... unless I have to... it looks better to use doSomething than do_something()

also, while I have done it, because maybe the code already had it, I don't like the variable notation defining the type like

mSomeVar

or
bCheckVar (b boolean)

in other words, Hungarian notation

http://en.wikipedia.org/wiki/Hungarian_notation

Anyways, like anything... I don't think there is sure right or wrong...

Ogre Forums

C++ Coding Style

C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style

Re: C++ Coding Style