Programming Style

I personally dislike the

int some_function() {
    // calculate something
}

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, but
along 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 itself
rather 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

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.

wasted lines, ah yes.

wasted lines, ah yes.

Are people still writing assembler code ?

You couldn't waste lines then.

cjdelphi:

void function_name(parameters)

{
   function definition ;
}




To me, this is the way I code, and i'd refuse to do it any other way.

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.

This is my favourite

Refuctoring
The 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

Graynomad:
This is my favourite

Refuctoring
The 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 the
source 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 other
functions and are usually three lines long, there are some problems which require quite
a lot of code to solve and they are the ones which are difficult to understand if you cannot
see the whole function at once.

Not everbody gets to work with multiple giant screens all the time.

How do you pronounce "refuctoring"?

I'll give you a hint, it's missing a "k" :slight_smile:


Rob

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.

PaulS:
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.

I also aim to get a function on a page, often don't achieve that but it's a good guideline.

And yes I think it's totally based on the screen size and in the past paper size which had more lines of course (does anyone actually print out a program these days? I haven't for about 15 years).

I saw on another forum the other day that the special editor they use for their board limits the line length to 80 chars...now that's bit 80s I think but OTOH lines shouldn't be too long either.


Rob

No. Display resolution had increased.

So, what you can see without scrolling defines the optimum function size. Interesting.

I'd guess that when the body is idle (not scrolling up and down), the brain is more active, spotting what doesn't look right, and that the adage out of sight, out of mind applies with coding, too.

80 characters comes from punched cards.

I've been told once that if my function has more than 50 lines that I'm doing something wrong and only inviting trouble.

As for pronounciation, I was thinking along the same line, but mommy thought not to swear. :slight_smile:

What REALLY bugs me is code like this:

    if (flag)
        { setbit(1); }
    else
        { setbit(0); }

I much prefer:

    if (flag) {
        setbit(1);
    } else {
        setbit(0);
    }

I've been told once that if my function has more than 50 lines that I'm doing something wrong and only inviting trouble.

I think my limit is a lot lower than that - anything over 20 would have me wondering how to refactor it. Complexity plays into that too - any more than three control flow statements and I'll want to break out some of it into a separate function. Basically, I want to be able to look at any function in my code and see immediately what it does.

Krupski:

[quote author=Coding Badly link=topic=151874.msg1140341#msg1140341 date=1362268831]
That's the one I use.

What REALLY bugs me is code like this:

    if (flag)
        { setbit(1); }
    else
        { setbit(0); }

I much prefer:

    if (flag) {
        setbit(1);
    } else {
        setbit(0);
    }

[/quote]

Funny of the two I prefer the first example. :wink: Humans, can't live without them, can't live with them.

Lefty

Basically, I want to be able to look at any function in my code and see immediately what it does.

I agree. Good function names help a lot too, as does having functions that do the thing that is indicated by their name rather than several things.