next topic »

[Reply #15 on:]

Well stuff K&R , I'll stick with

 {

 }

 

Me too, I got your six mate. 

Lefty

[Reply #16 on:]

Code:

void function_name(parameters)
{
   function definition ;
}

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


It makes it neater, easier to read... most other languages work in the same way

Code:

Procedure Function_Name(Params...);
Begin

End;

It seems the most easiest and most logical way to code and always will... if i ever had a boss "ride me" until i stopped, i'd probably end up seriously
hurting him one day....

[Reply #17 on:]

cjdelphi,

I don't know if you meant to or not, but I like to place a space between the code and the closing semi-colon.

Like this:

Code:

   function definition ;

rather than this:

Code:

   function definition;

I don't mean to be trolling...

[Reply #18 on:]

If I saw that , I would get rid of it as a typo .

[Reply #19 on:]

I personally dislike the

Code:

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.

[Reply #20 on:]

wasted lines, ah yes.

[Reply #21 on:]

wasted lines, ah yes.

Are people still writing assembler code ?

You couldn't waste lines then.

[Reply #22 on:]

Code:

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.

[Reply #23 on:]

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

[Reply #24 on:]

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?".

[Reply #25 on:]

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.

[Reply #26 on:]

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.

[Reply #27 on:]

How do you pronounce "refuctoring"?

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

______
Rob

[Reply #28 on:]

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.

[Reply #29 on:]

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.