Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3684 > unrolled thread

compiler switch to indicate "end of function"?

Back to article view | Back to comp.lang.c

Contents

  compiler switch to indicate "end of function"? David Mathog <dmathog@gmail.com> - 2011-05-10 09:00 -0700
    Re: compiler switch to indicate "end of function"? Tom St Denis <tom@iahu.ca> - 2011-05-10 10:08 -0700
    Re: compiler switch to indicate "end of function"? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-10 10:30 -0700
      Re: compiler switch to indicate "end of function"? David Mathog <dmathog@gmail.com> - 2011-05-10 15:54 -0700
      Re: compiler switch to indicate "end of function"? David Mathog <dmathog@gmail.com> - 2011-05-10 15:56 -0700
        Re: compiler switch to indicate "end of function"? Keith Thompson <kst-u@mib.org> - 2011-05-10 17:41 -0700
          Re: compiler switch to indicate "end of function"? blp@cs.stanford.edu (Ben Pfaff) - 2011-05-10 21:07 -0700
      Re: compiler switch to indicate "end of function"? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-10 19:32 -0400
        Re: compiler switch to indicate "end of function"? Michael Press <rubrum@pacbell.net> - 2011-05-10 23:32 -0700
          Re: compiler switch to indicate "end of function"? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-11 11:49 -0400
            Re: compiler switch to indicate "end of function"? Michael Press <rubrum@pacbell.net> - 2011-05-11 14:19 -0700
    Re: compiler switch to indicate "end of function"? Keith Thompson <kst-u@mib.org> - 2011-05-10 10:37 -0700
    Re: compiler switch to indicate "end of function"? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 13:34 -0700
      Re: compiler switch to indicate "end of function"? Seebs <usenet-nospam@seebs.net> - 2011-05-10 21:22 +0000
        Re: compiler switch to indicate "end of function"? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 16:00 -0700
          Re: compiler switch to indicate "end of function"? Seebs <usenet-nospam@seebs.net> - 2011-05-11 03:16 +0000
        Re: compiler switch to indicate "end of function"? Ian Collins <ian-news@hotmail.com> - 2011-05-11 12:32 +1200
          Re: compiler switch to indicate "end of function"? Keith Thompson <kst-u@mib.org> - 2011-05-10 17:56 -0700
          Re: compiler switch to indicate "end of function"? blp@cs.stanford.edu (Ben Pfaff) - 2011-05-10 21:09 -0700
            Re: compiler switch to indicate "end of function"? Ian Collins <ian-news@hotmail.com> - 2011-05-11 16:14 +1200
              Re: compiler switch to indicate "end of function"? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-10 21:19 -0700
                Re: compiler switch to indicate "end of function"? Ian Collins <ian-news@hotmail.com> - 2011-05-11 16:26 +1200
                Re: compiler switch to indicate "end of function"? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 07:10 +0100
                  Re: compiler switch to indicate "end of function"? Ian Collins <ian-news@hotmail.com> - 2011-05-11 20:50 +1200
                    Re: compiler switch to indicate "end of function"? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 18:53 +0100
                Re: compiler switch to indicate "end of function"? Sherm Pendley <sherm.pendley@gmail.com> - 2011-05-11 11:23 -0400
              Re: compiler switch to indicate "end of function"? Seebs <usenet-nospam@seebs.net> - 2011-05-11 05:30 +0000
        Re: compiler switch to indicate "end of function"? Jonathan Leffler <jleffler@earthlink.net> - 2011-05-10 21:26 -0700
          Re: compiler switch to indicate "end of function"? Keith Thompson <kst-u@mib.org> - 2011-05-11 08:07 -0700
        Re: compiler switch to indicate "end of function"? luser- -droog <mijoryx@yahoo.com> - 2011-05-11 06:04 -0700
          Re: compiler switch to indicate "end of function"? pete <pfiland@mindspring.com> - 2011-05-11 09:42 -0400
      Re: compiler switch to indicate "end of function"? Keith Thompson <kst-u@mib.org> - 2011-05-10 17:34 -0700
        Re: compiler switch to indicate "end of function"? David Mathog <dmathog@gmail.com> - 2011-05-12 08:44 -0700
          Re: compiler switch to indicate "end of function"? Kenneth Brody <kenbrody@spamcop.net> - 2011-05-12 13:41 -0400
            Re: compiler switch to indicate "end of function"? Michael Press <rubrum@pacbell.net> - 2011-05-12 12:08 -0700
              Re: compiler switch to indicate "end of function"? Chad <cdalten@gmail.com> - 2011-05-12 15:28 -0700
          Re: compiler switch to indicate "end of function"? Keith Thompson <kst-u@mib.org> - 2011-05-12 11:49 -0700
            Re: compiler switch to indicate "end of function"? David Mathog <dmathog@gmail.com> - 2011-05-13 08:56 -0700
              Re: compiler switch to indicate "end of function"? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-14 00:03 -0700

Page 2 of 2 — ← Prev page 1 [2]

#3716

Ian Collins <ian-news@hotmail.com> writes:

> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>> Ian Collins<ian-news@hotmail.com>  writes:
>>
>>> Displays have improved beyond recognition in the last 20 years and
>>> coding styles should adapt to suit.
>>
>> Displays have started shrinking vertically, though.  Most new
>> screens are 16:9 instead of the former standard 4:3.  That's
>> fewer lines of code displayed vertically for a given amount of
>> screen area.
>
> Below 24" yes (with a few exceptions).  But decent sized (24" 16:10
> and above) still have plenty of vertical pixels.

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.
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#3718

On 05/11/11 04:19 PM, Ben Pfaff wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>>> Ian Collins<ian-news@hotmail.com>   writes:
>>>
>>>> Displays have improved beyond recognition in the last 20 years and
>>>> coding styles should adapt to suit.
>>>
>>> Displays have started shrinking vertically, though.  Most new
>>> screens are 16:9 instead of the former standard 4:3.  That's
>>> fewer lines of code displayed vertically for a given amount of
>>> screen area.
>>
>> Below 24" yes (with a few exceptions).  But decent sized (24" 16:10
>> and above) still have plenty of vertical pixels.
>
> 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.

:)

It is a pain, but laptop designers tend to target DVD/BD players rather 
than programmers these days.  My old Dell had a 15" 1600x1200 display, a 
real coder's laptop.  Sadly it fell victim to our latest earthquake, 
along with the fish tank that landed on it!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#3723

Ben Pfaff <blp@cs.stanford.edu> writes:

> Ian Collins <ian-news@hotmail.com> writes:
>
>> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>>> Ian Collins<ian-news@hotmail.com>  writes:
>>>
>>>> Displays have improved beyond recognition in the last 20 years and
>>>> coding styles should adapt to suit.
>>>
>>> Displays have started shrinking vertically, though.  Most new
>>> screens are 16:9 instead of the former standard 4:3.  That's
>>> fewer lines of code displayed vertically for a given amount of
>>> screen area.
>>
>> Below 24" yes (with a few exceptions).  But decent sized (24" 16:10
>> and above) still have plenty of vertical pixels.
>
> 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.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#3729

On 05/11/11 06:10 PM, Dr Nick wrote:
> Ben Pfaff<blp@cs.stanford.edu>  writes:
>
>> Ian Collins<ian-news@hotmail.com>  writes:
>>
>>> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>>>> Ian Collins<ian-news@hotmail.com>   writes:
>>>>
>>>>> Displays have improved beyond recognition in the last 20 years and
>>>>> coding styles should adapt to suit.
>>>>
>>>> Displays have started shrinking vertically, though.  Most new
>>>> screens are 16:9 instead of the former standard 4:3.  That's
>>>> fewer lines of code displayed vertically for a given amount of
>>>> screen area.
>>>
>>> Below 24" yes (with a few exceptions).  But decent sized (24" 16:10
>>> and above) still have plenty of vertical pixels.
>>
>> 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.

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

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#3770

Ian Collins <ian-news@hotmail.com> writes:

> On 05/11/11 06:10 PM, Dr Nick wrote:
>> Ben Pfaff<blp@cs.stanford.edu>  writes:
>>
>>> Ian Collins<ian-news@hotmail.com>  writes:
>>>
>>>> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>>>>> Ian Collins<ian-news@hotmail.com>   writes:
>>>>>
>>>>>> Displays have improved beyond recognition in the last 20 years and
>>>>>> coding styles should adapt to suit.
>>>>>
>>>>> Displays have started shrinking vertically, though.  Most new
>>>>> screens are 16:9 instead of the former standard 4:3.  That's
>>>>> fewer lines of code displayed vertically for a given amount of
>>>>> screen area.
>>>>
>>>> Below 24" yes (with a few exceptions).  But decent sized (24" 16:10
>>>> and above) still have plenty of vertical pixels.
>>>
>>> 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.
>
> 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.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#3759

Ben Pfaff <blp@cs.stanford.edu> writes:

> Ian Collins <ian-news@hotmail.com> writes:
>
>> Below 24" yes (with a few exceptions).  But decent sized (24" 16:10
>> and above) still have plenty of vertical pixels.
>
> It's hard on me, though, because I prefer small laptops.

How much actual coding do you do away from your desk though? I
like laptops too, but plug them into a full-size monitor when
I'm at my desk and writing code. When I'm *not* at my desk I'm
usually just doing "light" work, checking email and such.

sherm--

[toc] | [prev] | [next] | [standalone]

#3721

On 2011-05-11, Ian Collins <ian-news@hotmail.com> wrote:
> Below 24" yes (with a few exceptions).  But decent sized (24" 16:10 and 
> above) still have plenty of vertical pixels.

Even with vertical pixels, I don't do windows with lots more lines, I do
windows with up to about 30 lines and then pick larger fonts so I can
see better.  :)

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#3717

On 5/10/11 2:22 PM, Seebs wrote:
> On 2011-05-10, Kleuskes&  Moos<kleuske@xs4all.nl>  wrote:
>>      {
>>        /* Some comment */
>>        including one too few "{" and "}"
>>      }
>
>> I'm sure you'll make a lot less errors. Braces are so important in
>> determining the structure of a C program, they deserve their own line.
>
> 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.


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.


-=JL=-

[toc] | [prev] | [next] | [standalone]

#3757

Jonathan Leffler <jleffler@earthlink.net> writes:
> 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) {
    /* ... */
}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#3749

On May 10, 4:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-05-10, Kleuskes & Moos <kleu...@xs4all.nl> wrote:
>
> >     {
> >       /* Some comment */
> >       including one too few "{" and "}"
> >     }
> > I'm sure you'll make a lot less errors. Braces are so important in
> > determining the structure of a C program, they deserve their own line.
>
> 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.
>
> > And don't try to tell me that whitespace costs money, since that's
> > only valid on paper.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#3751

luser- -droog wrote:
> 
> On May 10, 4:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > On 2011-05-10, Kleuskes & Moos <kleu...@xs4all.nl> wrote:
> >
> > >     {
> > >       /* Some comment */
> > >       including one too few "{" and "}"
> > >     }
> > > I'm sure you'll make a lot less errors. Braces are so important in
> > > determining the structure of a C program, they deserve their own line.
> >
> > 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.
> >
> > > And don't try to tell me that whitespace costs money, since that's
> > > only valid on paper.
> >
> > 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.

I'm on the other side of that.
I don't write programs that fit on a screen anymore,
so my preference is for what does show up on screen
to be as legible as possible.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#3706

"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> On May 10, 6:00 pm, David Mathog <dmat...@gmail.com> wrote:
>> Sometimes when editing a source file a close brace is accidentally
>> deleted, and when that happens, at least with gcc, the error messages
>> are not very helpful in locating the error.  Error messages are
>> generated from code below it, although not necessarily very near to
>> it, going on sometimes to the end of the file, thousands of lines
>> later.  These errors can propagate through dozens of functions.  Which
>> makes me wonder if there is something in the standard like:
>>
>> #endfunction
>>
>> to tell the compiler that if there is anything dangling in a function
>> at that point to throw an error there, and to start over cleanly below
>> the compiler directive.  So that when
>>
>> void somefunc(void){
>> /* bunch of stuff, including one too few "}" */}
>>
>> #endfunction
>>
>> it will be clear from the messages that the problem is in somefunc().
>> In some instances I have had to emulate this by cutting off large
>> chunks of a file with
>>
>> #ifdef NOTDEFINED
>>
>> until the code is small enough to find the error.
>>
>> Thanks,
>>
>> David Mathog
>
> Ok. I;m sure i'll get the same flak as last time for supplying some
> good advice, but your coding style is the main culprit, i think.
> Instead of acknowledging the braces as the important structural
> elements they are, your treat them like bums and try to hide them, as
> if hey don't really matter.
>
> if instead of
>
>
> void somefunc(void){
> /* bunch of stuff, including one too few "}" */}

But that's not what he wrote.  You put the closing brace at the end of a
line; he didn't.

What he actually wrote was:

BEGIN QUOTE
void somefunc(void){
/* bunch of stuff, including one too few "}" */
}
#endfunction
END QUOTE

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

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#3810

On May 10, 5:34 pm, Keith Thompson <ks...@mib.org> wrote:
>
> 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

[toc] | [prev] | [next] | [standalone]

#3818

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();

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#3826

In article <l76dnevxxsZJhlHQnZ2dnUVZ_sSdnZ2d@bestweb.net>,
 Kenneth Brody <kenbrody@spamcop.net> wrote:

> 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) { }

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#3848

On May 12, 12:08 pm, Michael Press <rub...@pacbell.net> wrote:
> In article <l76dnevxxsZJhlHQnZ2dnUVZ_sSdn...@bestweb.net>,
>  Kenneth Brody <kenbr...@spamcop.net> wrote:
>
> > 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>

[toc] | [prev] | [next] | [standalone]

#3825

David Mathog <dmathog@gmail.com> writes:
> On May 10, 5:34 pm, Keith Thompson <ks...@mib.org> wrote:
>>
>> 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?

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*/ }

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#3905

On May 12, 11:49 am, Keith Thompson <ks...@mib.org> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#3932

On May 13, 10:56 am, David Mathog <dmat...@gmail.com> wrote:
> On May 12, 11:49 am, Keith Thompson <ks...@mib.org> wrote:
>
> > 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.


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).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web