style rather intensely. And it seems quite a lot of other people don't favour it either.The explanations I have seen for why this style is "better" seem to be rather unconvincing, butalong the lines that with the opening curly brace at the end of the line with the function name,you can tell that it really is the function definition and not just a declaration. Which is an unconvincing reason to me. But then, people who write computer code as an end in itselfrather than as a means to an end, often have an interest in writing obsure code.

If I really want to save space, I sometimes do this

Quote

int some_function(){ // start the calculation on this line so the line is not wasted // and this is the second line of the calculation}

This avoids one of the (almost) empty lines and the curly braces still line up.

That's what I use too but without the extra space between the definition and semicolon. I can live with the awkward way of putting opening and closing semicolons on different levels if that's what the IDE auto-formatting tool does. As long as the code looks consistent in this way, I'm ok with it.

As for wasted lines, that's not so important these days. The extra empty lines give the code some rhythm so to say, within reason of course, and makes the code easier to read to me. I add extra empty lines into the function just to improve readability so the so called wasted line from the placing of the opening semicolon is really not that relevant a question to me.

RefuctoringThe process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.

_____Rob

Yay, now I have a term to use for that. I've been seeing a lot of refuctoring at work lately maybe due to "small" spec changes along the way. Thanks a lot. I can use it in a sentence, "Let's not refuctor this again, mmkay?".

How do you pronounce "refuctoring"? The description pretty fits well when I try to "improve" my code.

On topic, Egyptian braces be damned.The first thin I do when starting a function is to put both opening and closing braces, each in their own respective lines, reserved just for them. Then I write whatever needs to be written inside.

A 'wasted line', as some people suppose, is not about wasting space on the hard disk in thesource code file for the program.

It is about wasting lines in the often limited space on the programmer's editor screen.

While C++ and particularly java is full of these useless little functions which just call otherfunctions and are usually three lines long, there are some problems which require quitea lot of code to solve and they are the ones which are difficult to understand if you cannotsee the whole function at once.

My opinion is that if a function takes up more than one screen, it is doing too much. Now, I'll be the first to admit that sometimes I'll jam a lot of code in a function, just to get it working. But, sooner or later, I'll get tired of all the scrolling and fix the code so every function fits on the screen, and prints on one page.

When I print a function, and it takes 15 pages, I know that there is too much happening. Code folding helps a lot in refactoring a mess like that. Whatever can be folded is often a candidate for a separate function.

I prefer the aligned curly braces, with proper indentation (not yours, Nick) of the code between the braces.

My opinion is that if a function takes up more than one screen, it is doing too much.

An excellent observation and an excellent rule of thumb.

Years ago I read an article in Communications of the ACM about the optimal function size. The researchers determined that the optimal size was approximately 25 lines with a dramatic decrease in quality after 25 lines. At the time, most displays supported 25 lines of text so they theorized that screen size was a good measure of optimal function size.

Sometime later another researcher followed-up on the idea. That time around the optimal size was determined to be approximately 43 lines. What changed? Better development tools? Smarter programmers? No. Display resolution had increased.

Obviously, that is not a hard-fast rule. There are situations where a long stretch of discrete steps works best as a single block of code.