"Jon A. Cruz" <jon### [at] geocitiescom> writes:

> 
> Could I bug you to try to always use braces, even for single line
> bodies?
> 
> {
>   if(Ch=='\n') {
>           ungetc ('\r', (FILE *) File->Data);
>   }
>   ungetc (Ch, (FILE *) File->Data);
> }
> 
> As opposed to some things that are just a matter of style ( e.g. where
> you decide to place them), always using braces even for single line
> bodies is a good idea that helps prevent problems. Sometimes it's
> possible to write logic incorrectly and miss it due to misleading
> indention, but braces would catch that. 

That's why I let EMACS do the indentation do for me. This results in
a correct indentation in the sense that it reflects the assignment of
lines to loops and if statements.

If you are used to this code styling (which is the case for me), you
won't forget the braces when you add a second line. If I'm urged
to make the braces, I would have added them like this:

{
  if(Ch=='\n') 
    { ungetc ('\r', (FILE *) File->Data); }

  ungetc (Ch, (FILE *) File->Data);
}

It is more compact and therefore clearer in my opinion.


> Also, there are times when what
> you thought was a simple function might actually change to be a
> multi-line macro... and if so, BOOM! 

Because of this, I add braces to my multi-line macros. (In C++ I don't
use multi-line macros at all.)

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

On 3 Feb 2000 03:14:41 -0500, Nieminen Juha wrote:
>Jon A. Cruz <jon### [at] geocitiescom> wrote:
>: Could I bug you to try to always use braces, even for single line
>: bodies?
>
>:   if(Ch=='\n') {
>:           ungetc ('\r', (FILE *) File->Data);
>:   }
>
>  Good idea, as long as you don't put the braces that way.
>  The opening brace of a block should be at the beginning of the block, not
>at the end of the previous line.

I think this belongs in the "For your information" thread, as it's a 
religious battle.  FWIW, the indenting style above is at least as accepted
as the one you're advocating, for the simple reason that it lets you fit
more code in a screenful without sacrificing much in the way of readability.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

david sharp <dsh### [at] interportnet> wrote...
> Many macros are being rejected by MegaPov 0.4
> compiled for DOS (djgpp 2.03, gcc 2.95.2).

Opening POV and INC files in binary mode (as has been suggested) appears to
work, at least with the Windows compile.  I just changed the string
READ_TXTFILE_STRING to READ_BINFILE_STRING in two calls to fopen  (line 1112
in Initialize_Tokenizer and line 3651 in Open_Include).  Could people on
other OSs please test this potential fix (remove the #ifdef _GO32_ stuff in
unget first, though)?  Thanks.

-Nathan

Post a reply to this message

Nathan Kopp <Nat### [at] Koppcom> wrote in message
news:38999aa7@news.povray.org...
> Opening POV and INC files in binary mode (as has been suggested) appears
to
> work, at least with the Windows compile.  I just changed the string
> READ_TXTFILE_STRING to READ_BINFILE_STRING in two calls to fopen  (line
1112
> in Initialize_Tokenizer and line 3651 in Open_Include).  Could people on
> other OSs please test this potential fix (remove the #ifdef _GO32_ stuff
in
> unget first, though)?  Thanks.

This works (so far) for MS-DOS, with the advantage that it can now read UNIX
or
MS-DOS style files.

Post a reply to this message

Nathan Kopp wrote:

> Could people on
> other OSs please test this potential fix (remove the #ifdef _GO32_ stuff in
> unget first, though)?  Thanks.

I had no problems in Linux after making the change (though I couldn't
find any reference to _GO32_ anywhere).

-Mark Gordon

Post a reply to this message

Thomas Willhalm wrote:

> That's why I let EMACS do the indentation do for me. This results in
> a correct indentation in the sense that it reflects the assignment of
> lines to loops and if statements.

Yes. But once a single maintenance person comes by months or years later
who doesn't...

[SNIP]

> Because of this, I add braces to my multi-line macros. (In C++ I don't
> use multi-line macros at all.)

Right. Wich I also do (when I do it). I also make sure to user parenthesis
around macro parameters in the macro itself also...

But some may not. Especially in large and/or longer-lived projects.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Ron Parker wrote:

> On 3 Feb 2000 03:14:41 -0500, Nieminen Juha wrote:
> >Jon A. Cruz <jon### [at] geocitiescom> wrote:
> >: Could I bug you to try to always use braces, even for single line
> >: bodies?
> >
> >:   if(Ch=='\n') {
> >:           ungetc ('\r', (FILE *) File->Data);
> >:   }
> >
> >  Good idea, as long as you don't put the braces that way.
> >  The opening brace of a block should be at the beginning of the block, not
> >at the end of the previous line.
>
> I think this belongs in the "For your information" thread, as it's a
> religious battle.  FWIW, the indenting style above is at least as accepted
> as the one you're advocating, for the simple reason that it lets you fit
> more code in a screenful without sacrificing much in the way of readability.

Also, some argue that the lining up of closing braces with the opening brace
might be not as readable as lining it up with the construct that had the body.
i.e. the closing brace closes the 'if' not the '{'. So for many it is more
readable. Of course, if you also have the practice of always using braces, this
is more true.

But I don't care so much where they go, just that they are there somewhere.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Jon A. Cruz <jon### [at] geocitiescom> wrote:
:> I think this belongs in the "For your information" thread, as it's a
:> religious battle.  FWIW, the indenting style above is at least as accepted
:> as the one you're advocating, for the simple reason that it lets you fit
:> more code in a screenful without sacrificing much in the way of readability.

: Also, some argue that the lining up of closing braces with the opening brace
: might be not as readable as lining it up with the construct that had the body.
: i.e. the closing brace closes the 'if' not the '{'. So for many it is more
: readable. Of course, if you also have the practice of always using braces, this
: is more true.

  Of course both are lined. In this way:

  if(whatever)
  {
      command1();
      command2();
      command3();
      command4();
  }

  I seriously have trouble seeing where does the block begin and which command
does it belong to if the opening brace is at the end of the previous line.
I sometimes have to read code made that way and it takes a lot longer to
see and understand.
  I'm so accustomed to that format which I cited above that I almost
immediately see the beginning and ending of the block and the command which
it belongs to.
  Of course someone else may be accustomed to the other way. However, I have
serious difficulties interpreting that kind of code. This is specially true
when there are several nested and consecutive blocks with several lines of
code in each block.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I use this type:

if(whatever)
{
    command1();
    command2();
    command3();
    command4();
}

when writing C or C++, but I use this type:

object {MAIN_PARAMETERS
    OTHER_STUFF
}

when writing POV code.
Each one has it's own logical arguments, but I find the first one easier 
to read with loops and conditionals(probably because I am used to seeing 
C code that way). Since POV doesn't use curly brackets for those...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Mark Gordon <mtg### [at] mailbagcom> wrote...
> Nathan Kopp wrote:
>
> > Could people on
> > other OSs please test this potential fix (remove the #ifdef _GO32_ stuff
in
> > unget first, though)?  Thanks.
>
> I had no problems in Linux after making the change (though I couldn't
> find any reference to _GO32_ anywhere).

The _GO32_ stuff was David's first fix (post dated 2/2/2000), and was not
part of MegaPov 0.4.

-Nathan

Post a reply to this message