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 1 of 2  [1] 2  Next page →

#3684 — compiler switch to indicate "end of function"?

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

[toc] | [next] | [standalone]

#3685

On May 10, 12: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

This problem can be mitigated a bit by factoring your code so you
don't put many functions in a single file [or compilation unit].  I
usually hit the analogue of this problem when missing a ';' from a
header file, the compiler [gcc] goes off on a rant about invalid asm
declarations or whatever.  Though with experience I know exactly what
went wrong.

Also, compile early and often.  It helps weed out these annoying
configuration/layout/etc errors.

Tom

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

#3687

David Mathog <dmathog@gmail.com> writes:

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

If you have an auto-indenting editor, just tell it to re-indent
the whole file and look for the spot where the left margin shifts
rightward a tab stop.  It's usually obvious.

If you are using a version-control system (and if not, why not?),
look at the diff against the last checked-in version.  If it's
indeed a file with thousands of lines, probably the actual
changes are much smaller and you may be able to easily pick out
where you deleted a closing brace.

Try using another compiler or C parser.  GCC is excessively
forgiving because it allows nested function definitions; other
compilers will give an error at the first nested function
definition, since they don't have that extension.
-- 
Ben Pfaff 
http://benpfaff.org

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

#3699

On May 10, 10:30 am, Ben Pfaff <b...@cs.stanford.edu> wrote:
> David Mathog <dmat...@gmail.com> writes:
> > 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.
>
> If you have an auto-indenting editor, just tell it to re-indent
> the whole file and look for the spot where the left margin shifts
> rightward a tab stop.  It's usually obvious.
>
> If you are using a version-control system (and if not, why not?),
> look at the diff against the last checked-in version.  If it's
> indeed a file with thousands of lines, probably the actual
> changes are much smaller and you may be able to easily pick out
> where you deleted a closing brace.
>
> Try using another compiler or C parser.  GCC is excessively
> forgiving because it allows nested function definitions; other
> compilers will give an error at the first nested function
> definition, since they don't have that extension.
> --
> Ben Pfaffhttp://benpfaff.org

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

#3700

On May 10, 10:30 am, Ben Pfaff <b...@cs.stanford.edu> wrote:

> Try using another compiler or C parser.  GCC is excessively
> forgiving because it allows nested function definitions;

Ah, so that's why it goes on so long.  So I can get a similar result
with:

-fno-nested-functions

Might as well add that, as I don't think I have ever intentionally
used a nested function.

Thanks,

David Mathog

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

#3707

David Mathog <dmathog@gmail.com> writes:
> On May 10, 10:30 am, Ben Pfaff <b...@cs.stanford.edu> wrote:
>> Try using another compiler or C parser.  GCC is excessively
>> forgiving because it allows nested function definitions;
>
> Ah, so that's why it goes on so long.  So I can get a similar result
> with:
>
> -fno-nested-functions
>
> Might as well add that, as I don't think I have ever intentionally
> used a nested function.

As far as I can tell, gcc has no "-fno-nested-functions" option.

You can disable nested functions using, for example, "-ansi
-pedantic" or "-std=c99 -pedantic", but that's probably not going to
change how the source code is parsed, and therefore won't help with
the cascade of errors resulting from a syntax error.  More generally,
compilers that have extensions that extend the language grammar are
likely, when the extensions are disabled, to use the same grammar
but explicitly diagnose any uses of the extensions.

As I wrote elsethread, your best bet is probably just to ignore
everything after the first syntax error message, then fix the syntax
error and compile again.

-- 
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]

#3713

Keith Thompson <kst-u@mib.org> writes:

> As I wrote elsethread, your best bet is probably just to ignore
> everything after the first syntax error message, then fix the syntax
> error and compile again.

That doesn't help with the OP's problem.  Try compiling the
following with GCC, without any compiler options:

    int a(void)
    {
       return 1;

    int b(void)
    {
       return 2;
    }

    int c(void)
    {
       return 3;
    }

The only diagnostic is this:

    tmp.c: In function ‘a’:
    tmp.c:13: error: expected declaration or statement at end of input

As the OP said, the location of the error is far removed from the
actual problem, a missing } at the end of a().
-- 
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

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

#3703

On Tue, 10 May 2011 10:30:18 -0700, Ben Pfaff <blp@cs.stanford.edu>
wrote:

>David Mathog <dmathog@gmail.com> writes:
>
>> 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.
>
>If you have an auto-indenting editor, just tell it to re-indent
>the whole file and look for the spot where the left margin shifts
>rightward a tab stop.  It's usually obvious.
>
>If you are using a version-control system (and if not, why not?),
>look at the diff against the last checked-in version.  If it's
>indeed a file with thousands of lines, probably the actual
>changes are much smaller and you may be able to easily pick out
>where you deleted a closing brace.

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.

>Try using another compiler or C parser.  GCC is excessively
>forgiving because it allows nested function definitions; other
>compilers will give an error at the first nested function
>definition, since they don't have that extension.

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

DFC

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

#3725

In article <96ijs6tcll3oq7tdpn1hj1jf3o3tmsai1j@4ax.com>,
 Datesfat Chicks <datesfat.chicks@gmail.com> wrote:

> On Tue, 10 May 2011 10:30:18 -0700, Ben Pfaff <blp@cs.stanford.edu>
> wrote:
> 
> >David Mathog <dmathog@gmail.com> writes:
> >
> >> 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.
> >
> >If you have an auto-indenting editor, just tell it to re-indent
> >the whole file and look for the spot where the left margin shifts
> >rightward a tab stop.  It's usually obvious.
> >
> >If you are using a version-control system (and if not, why not?),
> >look at the diff against the last checked-in version.  If it's
> >indeed a file with thousands of lines, probably the actual
> >changes are much smaller and you may be able to easily pick out
> >where you deleted a closing brace.
> 
> 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.
> 
> >Try using another compiler or C parser.  GCC is excessively
> >forgiving because it allows nested function definitions; other
> >compilers will give an error at the first nested function
> >definition, since they don't have that extension.
> 
> 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.

-- 
Michael Press

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

#3763

On Tue, 10 May 2011 23:32:43 -0700, Michael Press <rubrum@pacbell.net>
wrote:
>> 
>> 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.

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.

But I think Turbo C followed shortly then Microsoft C.

DFC

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

#3776

In article <7tbls61upk8vs27robk6dc0i7q93vfgsae@4ax.com>,
 Datesfat Chicks <datesfat.chicks@gmail.com> wrote:

> On Tue, 10 May 2011 23:32:43 -0700, Michael Press <rubrum@pacbell.net>
> wrote:
> >> 
> >> 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.
> 
> 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.

-- 
Michael Press

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

#3688

David Mathog <dmathog@gmail.com> writes:
> 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.

There's nothing like that in the standard, and I've never heard of
any compiler providing it as an extension.

When you get a syntax error, it's often best to ignore everything
but the first error message.  Anything after that tends to be the
result of the compiler's attempt to recover and continue parsing,
and C's grammar is such that the attempt often fails.

If I suspect I've left out a closing brace, I'll go to the line in
the source file corresponding to the first error message, then go
from there to the opening '{' of the enclosing function and try
to find the matching '}'.  (In vi/vim, '%' jumps to the matching
brace; other editors should have something similar).  If there is no
matching '}', or if there is but it's not at the right indentation,
I start looking at enclosed brace pairs.

Running the source file through a formatter ("indent -kr", for
example, or a "reformat source" command if you use a GUI IDE)
might also be helpful in narrowing down the problem.

-- 
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]

#3693

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

you write

void somefunc(void)
{
#if 0
  {
    bunch of stuff,
    {
      /* Some comment */
      including one too few "{" and "}"
    }
    /* some more comment */
  }
#endif
}

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.
And don't try to tell me that whitespace costs money, since that's
only valid on paper.

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

#3696

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.

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

-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]

#3701

On May 10, 11: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.

True. It's also very handy to be able to easily spot where you went
wrong, especially with important language elements such as braces. If
you think otherwise, feel free to do it otherwise.

Many program-editors offer nice colorful indicators to match '{' with
'}' and '(' with ')'. I suggest you turn that on, too.

> There is no way to pick a standard except by appeal to authority.

I'm merely offering a colleage some advice that worked quite good for
me. All the places i worked that actually HAD a formalized coding
style (the best half of my employers, and you don't wanna know about
the worst ones), demanded separate lines for braces. But that's just
me and those silly employers of mine.

> Therefore, use the brace style from K&R.  That's the closest we'll ever
> have to a proper authority.

Arguments from authoroty are never quite satisfying, and a debate is
quite useless (and endless), so i'm not getting into that. In my
current firm, where I am the sole and undisputed authority on these
matters, K&R can go screw themselves in this respect, however much i
admire them for their work.

What you do in your code, is your business.

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

After years of contemplating the matter, i arrived at the conclusion
that it is unwise to want as much information as possible on your
screen. What you want is the _right_ information, and to be able to
spot it quickly.

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

#3711

On 2011-05-10, Kleuskes & Moos <kleuske@xs4all.nl> wrote:
> True. It's also very handy to be able to easily spot where you went
> wrong, especially with important language elements such as braces. If
> you think otherwise, feel free to do it otherwise.

Oh, I totally agree that it is very handy.  I just find that I don't
have any more trouble with it in 1TBS than I do in others, and indeed,
I tend to have less because it's more likely that both braces are on
screen.  :)

> After years of contemplating the matter, i arrived at the conclusion
> that it is unwise to want as much information as possible on your
> screen. What you want is the _right_ information, and to be able to
> spot it quickly.

Agreed.

I just find that braces are not enough information to be on lines; consistent
1TBS works and does not appear to induce any mismatched-brace issues.  I'd
rather see what I'm interested in than a lot of braces I'm not.

-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]

#3705

On 05/11/11 09:22 AM, Seebs wrote:
> On 2011-05-10, Kleuskes&  Moos<kleuske@xs4all.nl>  wrote:
>
>> 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.

I can see 112 lines with the large font I use, but I doubt I can parse 
them all at once.  I add whitespace and braces to break the code up into 
visually distinct blocks.  When I could only see a fraction the number 
of lines (despite better eyesight!), I wrote denser code.

Displays have improved beyond recognition in the last 20 years and 
coding styles should adapt to suit.

-- 
Ian Collins

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

#3708

Ian Collins <ian-news@hotmail.com> writes:
> On 05/11/11 09:22 AM, Seebs wrote:
>> On 2011-05-10, Kleuskes&  Moos<kleuske@xs4all.nl>  wrote:
>>
>>> 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.
>
> I can see 112 lines with the large font I use, but I doubt I can parse 
> them all at once.  I add whitespace and braces to break the code up into 
> visually distinct blocks.  When I could only see a fraction the number 
> of lines (despite better eyesight!), I wrote denser code.
>
> Displays have improved beyond recognition in the last 20 years and 
> coding styles should adapt to suit.

Personally, I don't use the K&R brace style because it's denser
than the alternatives.  I use it because I find it easy to read,
and because I *like* it -- which is probably largely because it's
what I first learned.  If K&R had put opening and closing braces
on their own lines, I'd probably argue in favor of that.

On the other hand, any code I write for $JOB follows the current
coding conventions.  In some cases I dislike them (they vary over
time and with different languages), but the only thing worse than
a style I dislike would be a style I dislike mixed with K&R style.

(One of the styles I've had to use is:
    if ( condition )
        {
        statement;
        statement;
        }
)

-- 
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]

#3714

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.
-- 
"Large amounts of money tend to quench any scruples I might be having."
  -- Stephan Wilms

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

#3715

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.

-- 
Ian Collins

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web