The curley bracket!

The second way of course. Never understood why anyone changed it. It's the only way (with indenting of course) that you can keep track of the opening and closing of brackets in nested statements. This was clearly a case of someone trying to change a standard that didn't need to be changed.

Mary

The first way saves a line of whitespace. And the closing bracket lines up with the command.

see?

I prefer to do it the second way myself. (just playing the devils advocate).

If it were that easy there wouldn't be so many questions posted on this site that are solved by fixing the use of brackets.

Why is it so important to save a line of whitespace?

Because it saves on lines of code, makes it easier to print, and saves pain and agony on page-up and page-down buttons.

Because it saves on lines of code, makes it easier to print, and saves pain and agony on page-up and page-down buttons.

This goes back to the IDE argument. Back in my day ... creak, creak ...
we coded on unix or dos and printed out on dot matrix printers. We didn't have these concerns.

In school we called the indenting a great way of showing variable scope. If prefer to indent keeps things readable!

Aric

Here is another debate what do you like:

intIndex++

Or

intIndex += 1

I prefer the +=

Aric

Doesn't this debate (or perhaps I should now say these debates) belong in a language-specific forum? My guess would be Java. As a (part-time, unofficial) VB developer, I don't have any great preference in the use of curly brackets.

Doesn't this debate (or perhaps I should now say these debates) belong in a language-specific forum? My guess would be Java. As a (part-time, unofficial) VB developer, I don't have any great preference in the use of curly brackets.

These questions are cross language although they are C based as many of the languages are C based. It's not really a technical question in my opinion as it is actually a question of standardisation rather than syntax. The issue of standardisation is a developers discussion rather than a language specific one. I think this issue can extend to naming conventions, as in whether they are useful or not. Personally I find them very useful.

Mary

Where do you put it?

Like this

Expand|Select|Wrap|Line Numbers

1. if (...){
2. //blah blah
3. }
4.  

or like this

Expand|Select|Wrap|Line Numbers

1. if(...)
2. {
3. //blah blah blah
4. }
5.  

Let the debate begin!!!

I prefer the second layout but have worked with both. What you use however is not so important as making sure the coding standard for the project in question specifies a layout and everyone on the project sticking to it.

Here is another debate what do you like:

intIndex++

Or

intIndex += 1

I prefer the +=

Aric

I don't think I care, but I use the ++ because it is 3 less characters to type.

Here is another debate what do you like:

intIndex++

Or

intIndex += 1

I prefer the +=

Aric

intIndex++ wherever I can use it. CFScript (Coldfusion scripting language) doesn't allow these so I'm forced to use intIndex = intIndex + 1 (so much typing!)

Where do you put it?

Like this

Expand|Select|Wrap|Line Numbers

1. if (...){
2. //blah blah
3. }
4.  

or like this

Expand|Select|Wrap|Line Numbers

1. if(...)
2. {
3. //blah blah blah
4. }
5.  

Let the debate begin!!!

I actually use the first method. I've never had bracket problems because I use indenting too and all brackets line up with the command.

I don't know how I started using this method as opposed to the second method, but it's stuck and I actually find the second method unsightly. If I'm copying code from somewhere or altering code, I'll change it to the first style (if it's not a lot of code). To save even more space, I'll also get rid of brackets altogether if it's a single line of code in if, for, while, etc.

Just personal habits.

My style:

I like saving the lines. Also, when scanning code, I can identify where each block of code begins/ends by the indenting involved. Finally,

looks uglier and 'breaks up' the code more than

++ is just great.

My style:

Expand|Select|Wrap|Line Numbers

1. if (<condition>) singleStatement;
2. if (<condition>) {
3.    state1;
4.    state2;
5.    state3;
6. } else if (<condition>) {
7.    state1;
8.    state2;
9. } else singleStatement;
10.  
11. intIndex++;

That's exactly how I code. Agree on the 'uglier' point too.

intIndex++ wherever I can use it. CFScript (Coldfusion scripting language) doesn't allow these so I'm forced to use intIndex = intIndex + 1 (so much typing!)

Wow! That has to heinous! Maybe that is why Cold Fusion isn't widely used anymore. Although, I don't know much about it :)

I prefer

I like to see the closing brace close a construct rather than another brace. It is also easier to memorise which statement is on which line number if the braces are placed this way. This is also the prefered Java convention in the Java formatting conventions.

Personally I think this is particularly bad and confusing, and breaks you rule of indenting show code level.

Most of the coding standard I have worked with specifically stipulate that you MUST ALWAYS use braces round a code block. This actually reduces maintenance work in the long run because of the slight tendancy towards people forgeting to add the braces if they add an extra statement to the code block.

As an aside I have worked with specification languages (TTCN specifically) where the indent level actually did give the code level, no braces or other syntax to indicate when a code block ended just code back out at the previous indentation level. Obviously putting in an extra TAB or leaving one out is quite easy but would cause horendous errors in the generated code.

As an aside I have worked with specification languages (TTCN specifically) where the indent level actually did give the code level, no braces or other syntax to indicate when a code block ended just code back out at the previous indentation level. Obviously putting in an extra TAB or leaving one out is quite easy but would cause horrendous errors in the generated code.

I don't know about you, but that seems like a terrible idea. Although it would force any programmers to learn proper indenting techniques, it would be a killer learning curve.

I don't know about you, but that seems like a terrible idea. Although it would force any programmers to learn proper indenting techniques, it would be a killer learning curve.

It was a complete nightmare, the code was shipped to us written by a 3rd party and then we used another 3rd party compiler to compile the TTCN into compilable C.

The TTCN source was full of bugs and the 3rd party compiler was full of bugs. getting a working system was a lot of hardwork everytime they produce a new version of either.

My style:

Expand|Select|Wrap|Line Numbers

1. if (<condition>) singleStatement;
2. if (<condition>)
3. {
4.    state1;
5.    state2;
6.    state3;
7. }
8. else if (<condition>)
9. {
10.    state1;
11.    state2;
12. }
13. else
14.    singleStatement;
15.  
16. intIndex++;

I use the second method, and here's why:
As part of my last job, I would assist one of my professors in teaching his students PHP. A very common error among students was leaving brackets open. The easiest way for my to have them search for it was through the "counting method." You simply work your way down the page, at a certain scope (determined by the intent), counting up for every { you hit and counting down for every } you hit. If you ever go negative, or enter a higher scope when you aren't at 0, you have an error.
Teaching this got me in the habit of coding this way (however, I am starting to get lazy :P)

I use the second method, and here's why:
As part of my last job, I would assist one of my professors in teaching his students PHP. A very common error among students was leaving brackets open. The easiest way for my to have them search for it was through the "counting method." You simply work your way down the page, at a certain scope (determined by the intent), counting up for every { you hit and counting down for every } you hit. If you ever go negative, or enter a higher scope when you aren't at 0, you have an error.
Teaching this got me in the habit of coding this way (however, I am starting to get lazy :P)

I used the first method until I got stuck in a grad-level Java coding course last semester of my senior year (I'm still mad at my advisor for that), and the teacher there used the second. I tend to be pretty OCD when it comes to how my code looks, and I had to conform to his standard because of all the libraries he gave us that we had to modify and add to. After doing nothing but coding like that for 3 months, I was unable to break the habit.

(I also put all my single statement conditionals in curly braces, just in case I have to go back later and change them)

(I also put all my single statement conditionals in curly braces, just in case I have to go back later and change them)

I usually keep single statements on the same line as their conditions, unlike the else statement in my previous post.

The other reason I like the first is because putting a { on it's own line makes things look empty. When there is space just sitting there after a condition, there is no reason not to fill it with a cursory description of the condition you are in:

The other reason I like the first is because putting a { on it's own line makes things look empty. When there is space just sitting there after a condition, there is no reason not to fill it with a cursory description of the condition you are in:

Expand|Select|Wrap|Line Numbers

1. if(something == happened())
2. { // Must comment on condition, otherwise I will look empty!
3.   docrap();
4.   twiddle.fingers();
5.   crash();
6. }
7.  

Ah, my comments on condition usually come immediately above, and then I comment at the end what the result is:

Comments? Documentation! Pfft! Preposterous.

>.>

Ah, my comments on condition usually come immediately above, and then I comment at the end what the result is:

Expand|Select|Wrap|Line Numbers

1. // here I check to see if something happened
2. if (something == happened) {
3.     twiddle.fingers();         // I steal code too, by the way ;)
4. } // and comment here where twiddle.fingers() might be necessary/have to be checked
5.  

This seems like it could get confusing with multiple conditions with else ifs:
Working from my laptop, I often curse when people put comments at the end of lines of code...Verbosity is desired; however, scrolling and word-wrapping are not! Comments MUST all have similar indentation!!

This seems like it could get confusing with multiple conditions with else ifs:

Expand|Select|Wrap|Line Numbers

1. // here I check to see if something happened
2. if (something == happened) {
3.     twiddle.fingers();          // Verbose comment that probably runs off the screen or causes a word-wrap.
4. } // Is this a comment about twiddle.fingers() or then next condition?
5. else if (something.else == happened) {
6.     dance.wildly();                  // Comment which is not properly aligned with the above comment, causing me to cry like a sissy.
7. } // I just love to dance.
8.  

Working from my laptop, I often curse when people put comments at the end of lines of code...Verbosity is desired; however, scrolling and word-wrapping are not! Comments MUST all have similar indentation!!

Expand|Select|Wrap|Line Numbers

1. if (something == happened)
2. { // Oh Em Ef Gee, something happened.
3.     twiddle.fingers();
4. } // Really dodged a bullet there!
5. else if (something.else == happened)
6. { // I have no idea what is going on
7.     dance.wildly();
8. } // Beats the crap out of walking in random patterns
9.  

I'm very liberal with my comments, and feel no remorse about putting a comment line in between spaces

Yeah, yours definitely looks cleaner.

/me ponders going off on discussion about code obfuscation and how it relates to job security....

I just have to chime in my support of the second method. Aesthetics aside, that makes it much easier to logically segment my code with a quick glance. The first way, though cleaner, I find takes a bit more time to decipher.

Also, I have to support the ++ way.

Yeah, yours definitely looks cleaner.

/me ponders going off on discussion about code obfuscation and how it relates to job security....

Someone beat you to it.

Someone beat you to it.

That's going in my bookmarks, right next to The Daily WTF.

ok i use the right method of currly braces and comments

the reason i do that is because of the coolest teacher at my high school was sick or figuring out what everyone's code does so she made us comment and indent that way also if we coppied other peoples code she knew we at least understood it cause we had to comment them.

now if you have looked at my code in the posts you can see i have gotten lazy but this is the methodology i belive in.

eirc

Someone beat you to it.

That's a great link

That's going in my bookmarks, right next to The Daily WTF.

Great link! A good way to lose your job or get stuck supporting some POS

Using only i++ can get you in trouble. Due to compiler differences, the i might be incremented at a different time than you intend.

post and pre...in C++ it's normally thought that you apply the incremention in relation to the index in the order that you see it.

For instance:
Some compilers will assign the value of temp at index 1 to test index 0. Upon completion, the variable index would still be 0.

Other compilers, especially olders ones, will assign the value of temp at index 1 to test index 0, BUT, on completion, the value of the variable index would be 1 (due to the index++). In these cases, you would have to re-write the code as follows:

There's an article about this on the Web somewhere, sorry i don't have the link at the moment.


Using index+=1 is easy, but it's not as clear. From a readability standpoint, using index = index+1 is best.


Note: I personally use index+=1

So effectively, the language should be referred to as C+=1
:-)

So effectively, the language should be referred to as C+=1
:-)

Depends on the implementation of operator++ and the typeof(C);

So effectively, the language should be referred to as C+=1
:-)

Actually as C = C + 1;

I prefer the way of

if(...)
{
//blah blah blah
}


I'd rather sacrifice a few lines of white space for neatly packaged methods & if statements & the ability to find them easily.


speaking of i++ & index++... anyone heard of ii instead of i++?

I would imagine that could majorly confuse things (especially given some old naming conventions)

Here is another debate what do you like:

intIndex++

Or

intIndex += 1

I prefer the +=

Aric

You should use the prefix-version, ++intIndex. It is faster.

You should use the prefix-version, ++intIndex. It is faster.

Perhaps I should explain why:

Postfix ++ (i++) needs to copy the object first, then increment the original, then return the copy. You get the overhead of a copy of the object.

Prefix ++ (++i) just needs to increment the object and then return a reference to it. No copy is needed.

I prefer:

I like:
- The style of indentation
- camelHumpStyle names rather than with_under_scores
- ++
- Functions in the style verbAdjectiveNoun() in plain English

What does everyone else think ? ( "what a pedant !" ? )

You should use the prefix-version, ++intIndex. It is faster.

With the speeds of PC processing these days I wouldn't think this is a big factor. Do you any have proof?

With the speeds of PC processing these days I wouldn't think this is a big factor. Do you any have proof?

I suspect that it isn't faster at all once the optimiser has got it's hands on it.

With the speeds of PC processing these days I wouldn't think this is a big factor.

Argh! Evil !!

This sort of "who cares, PCs are fast these day" reasoning is responsible for a lot of stupid coding and user frustration.

You don't happen to work for MS, by any chance?

I prefer:

Expand|Select|Wrap|Line Numbers

1. if (databaseGotUpdated)
2. {   updateCount++;
3.     clearDisplay();
4.     renderNewTable();
5. }
6.  

I like:
- The style of indentation
- camelHumpStyle names rather than with_under_scores
- ++
- Functions in the style verbAdjectiveNoun() in plain English

What does everyone else think ? ( "what a pedant !" ? )

Not sure I like including code on the same line as the opening bracket, but otherwise we agree.

Argh! Evil !!

This sort of "who cares, PCs are fast these day" reasoning is responsible for a lot of stupid coding and user frustration.

You don't happen to work for MS, by any chance?

No I don't work for MS but tell me how ++ is that much faster than +=?

This sort of "who cares, PCs are fast these day" reasoning is responsible for a lot of stupid coding and user frustration.

Actually this is a very good point, I once had to spend 2 weeks going through the code of an embedded project with 16Mbyte RAM searching for ways to save memory because people with this sloppy style had used it all up and the project need space for development.