compiler switch to indicate "end of function"?

[Dr Nick]

It's hard on me, though, because I prefer small laptops. My
previous 12" laptop with a 4:3 screen more easily accommodated
lots of code than my current 13.3" laptop with a 16:9 screen.

At this rate, my next laptop will have a 2:1 screen.

And if you use the newer Microsoft products they put a "ribbon" across
the top 2/3 of the page, leaving your writing your documents through a
letterbox.

 

[Michael Press]

To the OP: I use "cvs" with "ViewVC". There is a lot of truth to
Ben's assertion that a version control system helps. You might also
try "svn".

Shamefully, I once had to go a step further (but not with gcc).
Unknown to me, I had typed a control sequence and my favorite text
editor put a non-printing invisible character in my source file.

I got so frustrated that I did a "diff" (as Ben suggested), which
didn't seem to show a problem.

So I deleted my "sandbox" copy, checked out the last revision again,
then manually reapplied the changes shown by the diff one at a time.


Whoa! I learned something new.

I have not seen nested functions since Pascal. I did not know that
any C compiler implemented those. Interesting.

In case you're young enough not to remember Pascal:

http://en.wikipedia.org/wiki/Pascal_(programming_language)

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

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

Those links bring back memories ...

I totally ignored Pascal. It is one of those plague
viruses that escaped from the laboratory. Happily,
and not by chance, I am immune to such blandishments.

 

[Ian Collins]

And if you use the newer Microsoft products they put a "ribbon" across
the top 2/3 of the page, leaving your writing your documents through a
letterbox.

There's a very simple solution to that. Choice.

 

[luser- -droog]

This is not 1TBS.  Therefore it's wrong.

Here's the thing:  Brace styles are all viable.  Any of them will work.
But it's VERY useful to have everyone use the same style.

There is no way to pick a standard except by appeal to authority.  Therefore,
use the brace style from K&R.  That's the closest we'll ever have to a
proper authority.


It's not money, it's visual real estate.  I can only see so many lines
at a time.  Seeing a few more lines of code at a time is a pretty noticeable
payoff.

Strongly agree. I do most of my work on 9-inch notebook screen.
To get more than 25 or so lines, I'd have to make the font smaller
and harder to read.

 

[Keith Thompson]

On 5/10/11 2:22 PM, Seebs wrote: [...]

There is no way to pick a standard except by appeal to authority.
Therefore, use the brace style from K&R. That's the closest
we'll ever have to a proper authority.

1TBS as found in K&R 1st and 2nd Edn has the opening brace of a function
on a line on its own, left justified. Inside a function, yes, the
braces are at the end of a line after the condition or loop or whatever.
But the function braces are both flush left.

I think that's because old-style function definitions had (ok, still
have) the parameter declarations between the function name and the
opening '{':

int main()
int argc;
char **argv;
{
/* ... */
}

With prototypes, there's less reason for this exception. I sometimes
put the opening brace for a function definition at the end of the
line, depending on my mood (and, of course, on whatever coding
standards I'm working under):

int main(int argc, char **argv) {
/* ... */
}

 

[Dr Nick]

There's a very simple solution to that. Choice.

Home is a MS free zone. But I don't really want to change my job.

 

[Michael Press]

I didn't fully have that option. It was required for a programming
class I was taking at the university.

There was a time when Turbo Pascal was dominant.

Then the universities wised up. It is a theory based
system; and that should have given everyone a clue.
Another great idea gone to ruin.

 

[David Mathog]

My only quibble is that I'd put a space in front of the opening '{'.

Why do you favor that form over the "spaceless" variant?

The (long story) background for the first post is that once upon a
time I used to use:

if(condition)do_something();

but when "do_something" was too long wrote it as

if(condition)
do_something();

which, in nested code when the condition and do_something lines were
long enough that the right side wasn't normally visible, sometimes led
me to think this was:

if(condition){
do_something();}


so that another line could be added within the conditional
if(condition){
do_something_first();
do_something();}

when it was actually

if(condition)
do_something_first();
do_something();

which is not at all the same thing. Other times the confusion was:

if(long_condition)actual_do_something_off_right_side();
looks_like_conditional_but_not_do_something();

I'm not saying this happened even once a week, but it happened often
enough that I changed my style to avoid both of those, instead always
putting braces on the expression following an if:

if(condition){ do_something(); }

But it turns out that while this eliminates the preceding issue, it is
relatively easy for an errant key stroke to nip off the closing brace
since it is the last character on the line, leading to the issue that
started this thread. Particularly hard to see in long lines where the
closing brace is often off the right of the screen. As others have
noted, one can reduce the frequency of this issue by using the form:

if(condition)
{
do_something();
}

which is fine in low density code, but is on the losing end of the
readability tradeoff (in my opinion) in code that more closely
resembles a table, like this:

if(condition1){ a=1; b=2; c=3; /*more terms*/ }
else if(condition2){ a=1; b=0; c=3; /*more terms*/ }
else if(condition3){ a=1; b=2; c=0; /*more terms*/ }
/*etc.*/

Regards,

David Mathog

 

[Keith Thompson]

Why do you favor that form over the "spaceless" variant?

To be clear we're talking about

if(condition){
...
}

vs.

if (condition) {
...
}

(I also added a space between "if" and "("). I just find the latter
form significantly easier to read. Too many consecutive puncuation
characters tend to blend together visually. The space preceding the
"{" makes it easier to see. It doesn't (IMHO) need to be on a line
by itself, but it does need to stand out.

And I like a space after the "if" partly because the spaceless
version looks too much like a function call. It may also be partly
because, before learning C, I used a language (ok, it was Pascal)
that didn't use parentheses for if statements, and not having some
white space after "if" is a bit jarring.

And it's how K&R do it.

I don't suggest that my opinion is right and yours is wrong; it's
largely a matter of personal taste, K&R precedent, and my own
failing visual acuity.

The (long story) background for the first post is that once upon a
time I used to use:

if(condition)do_something();

but when "do_something" was too long wrote it as

if(condition)
do_something();

which, in nested code when the condition and do_something lines were
long enough that the right side wasn't normally visible, sometimes led
me to think this was:

if(condition){
do_something();}


so that another line could be added within the conditional
if(condition){
do_something_first();
do_something();}

when it was actually

if(condition)
do_something_first();
do_something();

which is not at all the same thing.

In my own style, and in every common style I've seen, a closing brace is
always on a line by itself. The only exception to this is the use, in
some styles (not mine), of "} else {".

Other times the confusion was:

if(long_condition)actual_do_something_off_right_side();
looks_like_conditional_but_not_do_something();

I'm not saying this happened even once a week, but it happened often
enough that I changed my style to avoid both of those, instead always
putting braces on the expression following an if:

if(condition){ do_something(); }

Personally, I almost always use braces for if, for, while, et al (a
habit I picked up from Perl, which requires them, but I think it's a
good idea regardless). I'll only omit the braces if the whole thing
fits on a single line *and* is clearer that way, so I'd write:

if (condition) do_something();

I'll violate my usual rules and write things on one line if there
are several consecutive similar statements, and aligning the code
vertically makes it easier to read:

if (condition1) do_something(1);
if (condition2) do_something(2);
if (condition3) do_something(3);

But it turns out that while this eliminates the preceding issue, it is
relatively easy for an errant key stroke to nip off the closing brace
since it is the last character on the line, leading to the issue that
started this thread. Particularly hard to see in long lines where the
closing brace is often off the right of the screen. As others have
noted, one can reduce the frequency of this issue by using the form:

if(condition)
{
do_something();
}

which is fine in low density code, but is on the losing end of the
readability tradeoff (in my opinion) in code that more closely
resembles a table, like this:

if(condition1){ a=1; b=2; c=3; /*more terms*/ }
else if(condition2){ a=1; b=0; c=3; /*more terms*/ }
else if(condition3){ a=1; b=2; c=0; /*more terms*/ }
/*etc.*/

There I would have aligned the "{"s, and possibly the conditions:

if (condition1) { a=1; b=2; c=3; /*more terms*/ }
else if (condition2) { a=1; b=0; c=3; /*more terms*/ }
else if (condition3) { a=1; b=2; c=0; /*more terms*/ }

 

[Michael Press]

On 5/12/2011 11:44 AM, David Mathog wrote:
[...]

which is not at all the same thing. Other times the confusion was:

if(long_condition)actual_do_something_off_right_side();
looks_like_conditional_but_not_do_something();

[...]

Or worse, and harder to spot;

for(foo;bar;baz);
not_part_of_the_for_loop();

Hence for(tom; dick; harry) { }

 

[Chad]

On 5/12/2011 11:44 AM, David Mathog wrote:
[...]

which is not at all the same thing.  Other times the confusion was:
if(long_condition)actual_do_something_off_right_side();
    looks_like_conditional_but_not_do_something(); [...]

Or worse, and harder to spot;

     for(foo;bar;baz);
         not_part_of_the_for_loop();

Hence for(tom; dick; harry) { }

<off topic>
Or if you want to piss off a college professor, do something like the
following...

while(the_pope_is_gay);

</off topic>

 

[David Mathog]

and my own failing visual acuity.

Hear you on that one. Post cataract surgery at a font size small
enough to show enough code to be usable I can barely tell these pairs
apart:

colon,semicolon
period,comma
parenthesis, brace

The editor I use (Nedit) can help with the last case (it has "find
matching") but
nothing short of a temporary "magnify at cursor" would help with the
first two cases, as they are all essentially just dots, and even
coloring them doesn't make it much easier to tell them apart since it
is hard to see the color on a dot. I tried editing with Windows
"Magnifier" running in the background, but it was too annoying having
all that motion in a window which I only rarely needed to consult.

Regards,

David Mathog

 

[robertwessel2]

Hear you on that one.  Post cataract surgery at a font size small
enough to show enough code to be usable I can barely tell these pairs
apart:

  colon,semicolon
  period,comma
  parenthesis, brace

The editor I use (Nedit) can help with the last case (it has "find
matching") but
nothing short of a temporary "magnify at cursor" would help with the
first two cases, as they are all essentially just dots, and even
coloring them doesn't make it much easier to tell them apart since it
is hard to see the color on a dot.  I tried editing with Windows
"Magnifier" running in the background, but it was too annoying having
all that motion in a window which I only rarely needed to consult.

Have you tried some of the fonts designed to help people with visual
impairments? Most of those do focus on the ordinary letters, but
some, Tiresias and APHont font, for example, do add considerable
emphasis on the distinguishability of some of the punctuation marks
giving you trouble. Those happen to be proportional font, so they're
not ideal for program text, but surely we could come up with fixed
pitch fonts that would help (they might not be all that attractive,
but that's clearly a secondary consideration).