Is it possible to define a union of unions? I don't succeed in doing
this.
-- 
Herman Serras
http://cage.rug.ac.be/~hs/

Post a reply to this message

"Herman Serras" <Her### [at] pandorabe> a écrit dans le message de news:
3D7B4516.C68C4B79@pandora.be...
> Is it possible to define a union of unions? I don't succeed in doing
> this.

You probably forgot a closing "}" somewhere.
Since you're using the windows version, check this by using the "Match
brace" command (Search>Match brace)
union{
    union{

    }
}
G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran <git### [at] wanadoofr> wrote:
> union{
>     union{

>     }
> }

  This is nitpicking, but IMHO it's easier to spot matching brackets when
they are in the same column, ie:

union
{
    union
    {
        ...
    }
}

  (It might take one extra line per bracket pair, but if it makes the source
more readable, that's perfectly ok IMO.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
3d7bc971@news.povray.org...
>   (It might take one extra line per bracket pair, but if it makes the
source
> more readable, that's perfectly ok IMO.)

Well yes, perhaps I should try this if it's more practical. I never liked it
for some reason (mostly because the extra lines I presume, I started coding
POV-Ray script on small MS-DOS displays, so extra lines did matter) but
since I change my coding and variable naming style every couple of years why
not. That's what I use for php anyway...

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

>   This is nitpicking, but IMHO it's easier to spot matching brackets when
> they are in the same column

I used to do this myself, and hated the other method... now, suddenly, I
find myself doing it the other way in POV-Ray, and occasionally in other
languages inside small if blocks.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3d7bd9c5$1@news.povray.org>, "Slime" <slm### [at] slimelandcom> 
wrote:

> >   This is nitpicking, but IMHO it's easier to spot matching brackets when
> > they are in the same column
> 
> I used to do this myself, and hated the other method... now, suddenly, I
> find myself doing it the other way in POV-Ray, and occasionally in other
> languages inside small if blocks.

I use the "{ at end of starting line" method in POV-Ray, Java, and 
Sapphire, but I use the "{ on new line" method in C and C++. I haven't 
really settled on one for Objective C, but the first method seems more 
common in existing Objective C code.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

"Gilles Tran" <git### [at] wanadoofr> wrote in
news:3d7b4867$1@news.povray.org 

> You probably forgot a closing "}" somewhere.
> Since you're using the windows version, check this by using the "Match
> brace" command (Search>Match brace)
> union{
>     union{
> 
>     }
> }

using #declare or maybe includes can help in complex scenes

#declare roof = union { ...  }

union { // My House
  object { roof }
  #include "peoples.inc"
}

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

in article 3d7bd9c5$1@news.povray.org, Slime at slm### [at] slimelandcom wrote on
9/9/02 12:14 am:

> This is nitpicking, but IMHO it's easier to spot matching brackets when
> they are in the same column

When I started programming in C, that was how I used to write my code. But
now, I just find it ugly for some reason. It is definitely easier to read,
but just can't get used to it no more.

All the best

Fidel.

Post a reply to this message

Warp wrote:
>   This is nitpicking, but IMHO it's easier to spot matching brackets
> when they are in the same column, ie:

It is impossible to come with any objective arguments that this is in
fact more easy, readable or effective to use. To me, I spot that the
start of the union keyword is on the same level as the end bracket.

And don't forget that I once caught you in posting some code with a
missing bracket, while that has never happened for me... ;)

Also, there will be more consistence in POV-Ray code made by different
people if more people stick to the style used in the vast majority of
the POV-Ray documentation and scene files.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> It is impossible to come with any objective arguments that this is in
> fact more easy, readable or effective to use. To me, I spot that the
> start of the union keyword is on the same level as the end bracket.

  I don't know about you, but to me it's easier to spot an opening bracket
at the same column as the closing one I'm looking the pair for, than
distinguishing that some word is at the same column (specially when
there are several blocks one inside another).

> Also, there will be more consistence in POV-Ray code made by different
> people if more people stick to the style used in the vast majority of
> the POV-Ray documentation and scene files.

  Have you actually looked at the documentation? For example look at the
primitives documentation (6.5). About half of the examples are indented
in one way and the other half in the other way.

  Even if "the vast majority" of people use that indentation style, that
doesn't automatically make it good.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
>   I don't know about you, but to me it's easier
> to spot an opening bracket at the same column as
> the closing one I'm looking the pair for, than
> distinguishing that some word is at the same column
> (specially when there are several blocks one inside
> another).

Nope that's not the same for me. Why would it be more difficult to
recognize a word than a starting bracket?

But really, the whole point of indention is that you *don't* need to
recognize any symbol or words in order to get an overview of the
structure. You simply need to notice that there is *something* at the
same indention level.

If you see a closing bracket and want to find the start of the block,
you simply scan upwards until you hit *anything* that is on that
indention level. So why does it make any difference what it is?

>   Have you actually looked at the documentation?
> For example look at the primitives documentation (6.5).
> About half of the examples are indented in one way and
> the other half in the other way.

Maybe so. But when you look at both the demo scenes and documentation, I
still think that my statement is correct, if we count in lines of code
(even though your indention method take up more lines!)

>   Even if "the vast majority" of people use that
> indentation style, that doesn't automatically make it good.

No, there are other reasons why it is good. It is equally* easy to read
with regard to indention, and it is more compact (without being
cluttered in any way), which mean that you can see more code in the same
view.

* at least we can't prove with objective arguments if one is easier to
read than the other.

But even if we assume that the two styles are equally good, it will
still make life easier for coders if most people used the *same* style
rather than different styles.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> But even if we assume that the two styles are equally good, it will
> still make life easier for coders if most people used the *same* style
> rather than different styles.


To be honest, I think a more worthwhile debate would be whether to use tabs
or spaces for indentation.

Personally, I'm all for tabs.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

"Slime" wrote:
> > But even if we assume that the two styles are equally good, it will
> > still make life easier for coders if most people used the *same* style
> > rather than different styles.
>
>
> To be honest, I think a more worthwhile debate would be whether to use tabs
> or spaces for indentation.
>
> Personally, I'm all for tabs.

Sure... but TWO SPACES tabs, mind you...

--
Jonathan.

Post a reply to this message

> Sure... but TWO SPACES tabs, mind you...


Well, tab size can be set differently on different programs, can't it? So I
can set mine to 4 (which I prefer) while you can set yours to 2.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

On Mon, 9 Sep 2002 19:50:24 -0400, "Slime" <slm### [at] slimelandcom> wrote:

>To be honest, I think a more worthwhile debate would be whether to use tabs
>or spaces for indentation.

But they are different beasts! Or have you never edited a makefile? :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Slime <slm### [at] slimelandcom> wrote:
> Personally, I'm all for tabs.

  Yes, and then someone viewing the file with different tab settings than
you will see it in a quite funny way (specially if you combine tabs and
spaces in the indentation).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> Nope that's not the same for me. Why would it be more difficult to
> recognize a word than a starting bracket?

  Because of its peculiar shape.
  From a bunch of text you can distinguish a lot better a '{' than a word.

> But really, the whole point of indention is that you *don't* need to
> recognize any symbol or words in order to get an overview of the
> structure. You simply need to notice that there is *something* at the
> same indention level.

  My point is that it's easier to spot that "something" if it has a peculiar
shape, like '{'.

> If you see a closing bracket and want to find the start of the block,
> you simply scan upwards until you hit *anything* that is on that
> indention level. So why does it make any difference what it is?

  *Anything* can be a lot of things and it may not always be clear which
of those things is the one you are looking for. It's easier to look for
something specific (ie. a '{') than looking for *anything*. Get my point?

> No, there are other reasons why it is good. It is equally* easy to read
> with regard to indention

  To me it's harder to read. You can't disprove that. :)

> and it is more compact

  Being more compact does not automatically mean it's better.
  If a code block is delimited by "empty" lines (not really empty, as the
line at the beginning as a { and the line at the end has a }, but as they
are the only characters at those lines, they look quite empty) it better
distinguishes the boundaries of a code block. That is, it's easier to see
where does the code block begin and where does it end.
  With the "more compact" style you don't see it as easily, as you only
have the indentation to act as a hint.

> But even if we assume that the two styles are equally good, it will
> still make life easier for coders if most people used the *same* style
> rather than different styles.

  That's why people should use the better style.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3d7db4dc@news.povray.org:

> Slime <slm### [at] slimelandcom> wrote:
>> Personally, I'm all for tabs.
> 
>   Yes, and then someone viewing the file with different tab settings
>   than 
> you will see it in a quite funny way (specially if you combine tabs
> and spaces in the indentation).

I use tabs in most of my code, but I settled for spaces for POV-Ray
sources, because most people seems to use it, because 2 spaces is quite
compact with code that can be deeply nested, and because they are better
to see in newsgroups... 

I also like to align my soft brackets, and keep this notation. I believe
that such religious war is useless, because by experience everybody
keeps its opinion. After all, it is a matter of taste. 

I think that consistency is more important for an individual or a
project, that accross a community. I am trying to write code with always
the same rules applied. But when I write Scintilla or VXCL code, for
example, I follow the style used by the author. It is just polite, as it
eases the work of integrating back the patches in the code base. 

Note that mixing tabs and spaces is, for me, the worst way of
indenting... It is confusing, often inconsistent, can fool some editors,
etc. 

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

>   Yes, and then someone viewing the file with different tab settings than
> you will see it in a quite funny way (specially if you combine tabs and
> spaces in the indentation).


Oh, well, certainly if you combine tabs and spaces. That would be stupid
though. I find the ability to view a file with different tab settings to be
an advantage.

You do have to be careful only to use tabs for indentation though, and not
formatting purposes.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Philippe Lhoste <Phi### [at] gmxnet> wrote:
> Note that mixing tabs and spaces is, for me, the worst way of
> indenting... It is confusing, often inconsistent, can fool some editors,
> etc. 

  Unfortunately this is what emacs does by default (and you might imagine
how many unix-users use emacs as their source code editor with default
settings...).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Slime <slm### [at] slimelandcom> wrote:
> Oh, well, certainly if you combine tabs and spaces. That would be stupid
> though. I find the ability to view a file with different tab settings to be
> an advantage.

> You do have to be careful only to use tabs for indentation though, and not
> formatting purposes.

  The problem is that the "standard" tab setting is 8 spaces, which is a bit
too much for code indentation...

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3d7db4dc@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Yes, and then someone viewing the file with different tab settings than
> you will see it in a quite funny way (specially if you combine tabs and
> spaces in the indentation).

Yes, but the point is to use tabs for _indentation_, not for anything else.
For indentation it does not matter.  If you use tabs to create columns (i.e.
when commenting), you of course run into trouble.  But for pure identation
that starts at the beginning of a line tabs work just fine.  Plus they parse
a tiny bit faster ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Warp wrote:
> My point is that it's easier to spot that "something"
> if it has a peculiar shape, like '{'.

(1) That's a statement not supported with an objective argument. I
happen to disagree.

>   *Anything* can be a lot of things and it may not
> always be clear which of those things is the one
> you are looking for.

(2) The one that's on the same indention level?

> It's easier to look for something specific
> (ie. a '{') than looking for *anything*.
> Get my point?

No. See (1) and (2).

> To me it's harder to read. You can't disprove that. :)

Correct. :)

> Being more compact does not automatically mean it's better.

If and only if the readability is the *same*, then it is better if the
code is compact at the same time.

Since it seems to be a subjective matter whether or not the compact
style is better or worse with regard to readability, we may as well look
apart from that discussion.

So we have style 1 which some people find more readable but which is not
very compact.

And we have style 2 which some people find more readable and which is
also more compact.

That leaves one advantage to style 2.

> That's why people should use the better style.

"Better" is a subjective term. "Widely used" is a rather objective term,
and very often, things are widely used for a good reason. And I don't
think there is any doubt about which POV-Ray style is more widely used?

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

"Rune" <run### [at] mobilixnetdk> wrote in news:3d7e1089@news.povray.org:

> "Better" is a subjective term. "Widely used" is a rather objective term,
> and very often, things are widely used for a good reason. And I don't
> think there is any doubt about which POV-Ray style is more widely used?
> 
> Rune

IE and Windows are widely used. Is it for a good reason, or because of 
Microsoft politics? Note: I am a Windows user only :-)

Most people in France don't use their turning lights (clignotants). Is it 
for a good reason? (OK, that's a negative example.)

Hamburgers and Coca-Cola are widely consummed. Are they de facto good food?

I can go on and on, with more or less disputable examples... :-)

More on the topic, Kernighan & Richie's C style, ie. with opening soft brace 
on the same line of the statement, were used in their book. It was the 
learning book of most C programmers. That's why their style was so widely 
used. Probably the same for the POV-Ray style...
I used K&R first, then I saw good arguments on the aligned braces style, and 
since then I sticked to it. With modern displays, compactness is not such a 
must. And for a more global view, printing is a solution.

Note: for C code, programs like AStyle can help to switch from a format to 
another. Perhaps we should make something similar for POV-Ray. I wish I have 
one when I look at some code :-)

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
>> My point is that it's easier to spot that "something"
>> if it has a peculiar shape, like '{'.

> (1) That's a statement not supported with an objective argument. I
> happen to disagree.

  I don't understand this. If you are told "look for *anything* at this
indentation level", I think that's a bit slower task to do than "look
for a { at this indentation level". With the later you are only searching
for a specific character (which is usually easy to spot) and you can just
visually skip anything else. With the former you can't skip anything, but
you have to visually check everything that could be a candidate for what
you are searching for.

  Also your indentation is more illogical. The starting character of the
code block is completely disconnected from the code block in question,
and could be located virtually anywhere with respect to the code block.
The starting character is also completely and arbitrarily misplaced
with respect to the ending character.
  IMO it's more logical that the starting character of the code block is
always located at the same place with respect to to the code block and
the block ending character.

  When someone posts a povray code showing some problem and I need to
read the code and understand it, usually the first thing I have to do
is to re-indent it by placing the brackets in their proper places.
That way it's a lot easier to see matching pair and, for example, if
an opening bracket is missing or whatever. It's a lot more difficult
to understand the code indented in your way.
  On the other hand, I don't remember anyone complaining that my way is
more difficult to understand. (Of course you could complain as a reply
to this, but I think that would be quite artificial.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Philippe Lhoste wrote:
>

I didn't properly explain what I meant when I said that things are often
widly used for a good reason. I was talking about situations where you
have several competitive alternatives. For example, out of the search
engine alternatives, google is most widely used (I think?), and for a
good reason.

> IE and Windows are widely used. Is it for a good
> reason, or because of Microsoft politics?

It's for good reasons, although you may not like the reaons. For
example, Windows is the platform most widely supported by software (I
think), and that is a good reason to use Windows.

> Most people in France don't use their turning
> lights (clignotants). Is it for a good reason?

That's not the kind of comparisons I was talking about.

> Hamburgers and Coca-Cola are widely consummed.
> Are they de facto good food?

Hamburgers and Coca-Cola are widely consumed compared to what exactly? I
think that water is more widely consumed. It doesn't make sense to do
comparisons like these... Besides, quality is certainly not the only
criteria for determining if something is widely used or not. There can
be many other good reasons than quality.

> More on the topic, Kernighan & Richie's C style, ie.
> with opening soft brace on the same line of the
> statement, were used in their book. It was the
> learning book of most C programmers. That's why
> their style was so widely used.

Yes, but...

> Probably the same for the POV-Ray style... I used
> K&R first, then I saw good arguments on the aligned
> braces style, and since then I sticked to it.

See? People can just change their style. I think that if a style did not
work very well, then most people would switch to other alternatives.

> With modern displays, compactness is not such a must.

But it's still a good thing (when it doesn't hurt readability).

> And for a more global view, printing is a solution.

No thanks. :)

> Note: for C code, programs like AStyle can help to
> switch from a format to another. Perhaps we should
> make something similar for POV-Ray. I wish I have
> one when I look at some code :-)

Me too! :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

In article <3d7dd67f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   The problem is that the "standard" tab setting is 8 spaces, which is a bit
> too much for code indentation...

In broken (Win)DOS editors perhaps, on Macs it has been four since 1984...
;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <Xns### [at] 204213191226> , Philippe Lhoste 
<Phi### [at] GMXnet>  wrote:

> More on the topic, Kernighan & Richie's C style, ie. with opening soft brace
> on the same line of the statement, were used in their book. It was the
> learning book of most C programmers. That's why their style was so widely
> used. Probably the same for the POV-Ray style...
> I used K&R first, then I saw good arguments on the aligned braces style, and
> since then I sticked to it. With modern displays, compactness is not such a
> must. And for a more global view, printing is a solution.
>
> Note: for C code, programs like AStyle can help to switch from a format to
> another. Perhaps we should make something similar for POV-Ray. I wish I have
> one when I look at some code :-)

It should also be noted that the ISO C++ standard uses both styles in its
examples.  So if ISO sees no reason to standardize on one, and has neither
found a common agreement (or the need to have one), I don't think there is a
need to have one for POV-Ray anywhere.

That said, my personal preference goes along with the indentation style used
in the POV-Ray core source code (which uses aligned braces), and as all
modern editors support tab width settings and come with reasonable defaults
(i.e. not 8 spaces for one tab), I used tabs ever since (1988)...


    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3d7dd67f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> You do have to be careful only to use tabs for indentation though, and not
>> formatting purposes.
>
>   The problem is that the "standard" tab setting is 8 spaces, which is a bit
> too much for code indentation...

Wasn't it you who recently argued to drop old and broken programs of a
specific kind?  Now you argue we all should support old and broken programs
used by less than 0.1% of the existing computer users???  ;-)


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

in article 3d7d43ad$1@news.povray.org, JRG at jrg### [at] hotmailcom wrote on
10/9/02 1:57 am:

> "Slime" wrote:
>>> But even if we assume that the two styles are equally good, it will
>>> still make life easier for coders if most people used the *same* style
>>> rather than different styles.
>> 
>> 
>> To be honest, I think a more worthwhile debate would be whether to use tabs
>> or spaces for indentation.
>> 
>> Personally, I'm all for tabs.
> 
> Sure... but TWO SPACES tabs, mind you...

I agree with you on this one Jonathan.

Fidel.

Post a reply to this message

Warp wrote:
>   I don't understand this. If you are told "look for
> *anything* at this indentation level", I think that's
> a bit slower task to do than "look for a { at this
> indentation level". With the later you are only
> searching for a specific character (which is usually
> easy to spot) and you can just visually skip anything
> else. With the former you can't skip anything, but
> you have to visually check everything that could be a
> candidate for what you are searching for.

There are no "candidates". It's always the first thing you find (on that
indention level), which is what you're looking for. It's not like these
are several things you have to look at, and then figure out which one is
the correct one.

> Also your indentation is more illogical.

By your definitions.

> The starting character of the code block is
> completely disconnected from the code block in question

I see the { character as an extension of the keyword coming before it,
and that marks the start of the block. The } character marks the end of
the block. The line defining the start of the block is on the same
indention level as the line defining the end of the block. This is
completely logical.

I acknowledge that your style is also completely logical, I just prefer
the style I use for several other reasons.

> The starting character is also completely and arbitrarily
> misplaced with respect to the ending character.

I really don't know what you mean.

> IMO it's more logical that the starting character
> of the code block is always located at the same
> place with respect to to the code block and the
> block ending character.

In the style I use, the starting *line* of the code block (keyword + {)
is always located at the same place with respect to the code block as
the block ending *line* (})

>   When someone posts a povray code showing some
> problem and I need to read the code and understand
> it, usually the first thing I have to do is to
> re-indent it by placing the brackets in their
> proper places.

Same here.

> That way it's a lot easier to see matching pair
> and, for example, if an opening bracket is
> missing or whatever. It's a lot more difficult
> to understand the code indented in your way.

In my experience, it's more difficult to understand the code in *your*
way. People are different.

>   On the other hand, I don't remember anyone
> complaining that my way is more difficult to
> understand. (Of course you could complain as a
> reply to this, but I think that would be quite
> artificial.)

Well, there was that one time where you had missed a closing bracket in
your code. There's a slight chance that it may have been someone else,
but I'm pretty sure it was you. My point below is valid either way.

Back then, it *did* take me a long time to find the error, because I
found the indention confusing, and I did indeed reindent the code to be
able to find it. However, as I respect your choice (or whoever it was)
to use a different style, I certainly didn't "complain", and still
don't. I would find it rather rude if people complained about the coding
style I have chosen to use, since it makes perfectly sense and is even
widely used.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Warp wrote:

>   When someone posts a povray code showing some problem and I need to
> read the code and understand it, usually the first thing I have to do
> is to re-indent it by placing the brackets in their proper places.

Whenever I try to understand your code I have to remove your indenting
to understand it :)

-- 
Ken Tyler

Post a reply to this message

Warp wrote:
>   This is nitpicking, but IMHO it's easier to spot matching brackets
> when they are in the same column

Run away, run away!

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> In broken (Win)DOS editors perhaps, on Macs it has been four since 1984...
> ;-)

  In unix it has been 8 from the beginning of time, I suppose.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Wasn't it you who recently argued to drop old and broken programs of a
> specific kind?  Now you argue we all should support old and broken programs
> used by less than 0.1% of the existing computer users???  ;-)

  That would probably mean dropping virtually every Windows and Unix program
out there (as well as all Unix shells, etc).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> There are no "candidates". It's always the first thing you find (on that
> indention level), which is what you're looking for. It's not like these
> are several things you have to look at, and then figure out which one is
> the correct one.
...
> By your definitions.
...
> I really don't know what you mean.

  It seems impossible to talk with you, so I'll just stop. You don't even
try nor want to understand what I'm talking about.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> 
> Rune <run### [at] mobilixnetdk> wrote:
> > There are no "candidates". It's always the first thing you find (on that
> > indention level), which is what you're looking for. It's not like these
> > are several things you have to look at, and then figure out which one is
> > the correct one.
> ...
> > By your definitions.
> ...
> > I really don't know what you mean.
> 
>   It seems impossible to talk with you, so I'll just stop. You don't even
> try nor want to understand what I'm talking about.

If you look at the original posting in this thread, you'll see that the
subject has changed quite a lot!
> 
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

-- 
Herman Serras
Gent (Belgium)
http://cage.rug.ac.be/~hs/

Post a reply to this message

I can't believe that you guys are still debating on this subject.
Not everybody has the same taste for anything. So why bother with the way
someone else writes his code, or what he uses?
I personally don't modify nobody's code just because it isn't in the same
style as mine. I have to respect his style as well. As long as I understand
it, I don't really care. You should just be aware of different styles.


All the best

Fidel.

in article 3D7F2114.CE5A85EB@pandora.be, Herman Serras at
Her### [at] pandorabe wrote on 11/9/02 11:55 am:

> 
> 
> Warp wrote:
>> 
>> Rune <run### [at] mobilixnetdk> wrote:
>>> There are no "candidates". It's always the first thing you find (on that
>>> indention level), which is what you're looking for. It's not like these
>>> are several things you have to look at, and then figure out which one is
>>> the correct one.
>> ...
>>> By your definitions.
>> ...
>>> I really don't know what you mean.
>> 
>> It seems impossible to talk with you, so I'll just stop. You don't even
>> try nor want to understand what I'm talking about.
> 
> If you look at the original posting in this thread, you'll see that the
> subject has changed quite a lot!
>> 
>> --
>> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
>> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> It seems impossible to talk with you, so I'll just stop.

If the fact that you can't convince me, and that I don't think the same
way as you makes you feel that it's impossible to talk with me, then be
it so. I don't really mind this discussion stopping anyway, and as I
already said, I respect people's choices to use different styles than
myself.

> You don't even try nor want to understand what
> I'm talking about.

That is incorrect. Is there even any possible way I could have disagreed
with you without you thinking that I didn't want to understand what
you're talking about? The fact that I disagree with you mean that I just
don't get it, doesn't it?

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Hi,

I can't decide if I should pour cold water over you all or
throw some dynamite into the flames, so I'll try both --
here comes the third style:

// typical indentation example
keyword { required_parameters
  optional_parameters
  optional_parameters
  }

This is completely logical, because
- *everything* belonging to the keyword is indented,
  including, of course, the "}"
- no (almost) empty line separates the keyword from
  its parameters
- it's easy to find the keyword belonging to a "}":
  (1) look at the "}";
  (2) move your focus to the white space preceding it;
  (3) move your focus up over WHITE space until you see
      BLACK;
  (4) you are looking at the keyword!

It isn't a dogma to me, just a rule of thumb to improve
readability of _my_ code. To check braces, I don't (ab)use
my eyes; 'Match Braces' will do that faster and more reliable
than I ever could. I don't care much about the braces -- they
are for the _computer_, not for me; I don't need them.
Indentation is for humans, that's all _I_ need.
For me the most powerful formatting means is white brace-
free space (horizontally and vertically; and comments, of
course).

The same style can be used for other 'bracing pairs' like
#case/#break, #if/#else/#end:

// typical indentation example
#macro MyObject ( Para )
  DoThis
  DoThat
  #end//macro MyObject

Those who want aligned braces (and 'bracing pairs') might
use my Pascal-Style:

/* typical Pascal indentation */
if Condition then             begin
    DoThis
    DoThat                    end
  else                        begin
    DoOther
    DoMore                    end;

Perfectly aligned AND readable, isn't it? :))

For a real POV-Ray example see my post in p.g on 3rd sept.
concerning with 'Intersection with quartic: bug?'.

Oh, I don't want to convince anybody that my style is the
best -- my intention is to show the friendly coexistence
of 3 (or more) 'truths'.

Make POV, not war!

   Sputnik


e-mail: fr (at) computermuseum (dot) fh-kiel (dot) de

Post a reply to this message

Frank 'Sputnik' Rothfuß <fr### [at] computermuseumfh-kielde> wrote:
>   (1) look at the "}";
>   (2) move your focus to the white space preceding it;
>   (3) move your focus up over WHITE space until you see
>       BLACK;
>   (4) you are looking at the keyword!

  This is not as easy with several nested code blocks. If there's a lot if
white space at *both* sides of the column you are looking at, it can be more
difficult to see which of the lines is at the same indentation level as the }.

> /* typical Pascal indentation */
> if Condition then             begin
>     DoThis
>     DoThat                    end
>   else                        begin
>     DoOther
>     DoMore                    end;

> Perfectly aligned AND readable, isn't it? :))

  Nope. The indentation is not logical. Some blocks are indented with 2 spaces
and others with 4 spaces. There's no consistency. The 'else' is not inside
of the 'if' block, but is at the same level, thus indenting it more than the
'if' is ilogical.
  With a simple example there's no confusion, but make 4 nested if-then-elses
and it begins to be quite a lot more confusing.

  Indentation should be logical, consistent and easy to understand.
Indenting one thing in one way and another thing in another way, and
specially indenting in a way that several nested blocks make the code
confusing is not good.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I am sorry, but I have to disagree with you. The other two styles are much
more readable. But then again, if it makes you happy and you can read it,
then good for you. But, I would have to take a while to understand it,
specially if there is a lot of nested code. I can get used to it, but it
isn't as readable as the other ones.
That's just my opinion on the subject. I do respect everyone's style, but
there are some styles more readable than others.

All the best

Fidel.
 

in article 3D834E68.BA3FFD7F@computermuseum.fh-kiel.de, Frank 'Sputnik'
Rothfuß at fr### [at] computermuseumfh-kielde wrote on 14/9/02 3:57 pm:

> Hi,
> 
> I can't decide if I should pour cold water over you all or
> throw some dynamite into the flames, so I'll try both --
> here comes the third style:
> 
> // typical indentation example
> keyword { required_parameters
> optional_parameters
> optional_parameters
> }
>
> This is completely logical, because
> - *everything* belonging to the keyword is indented,
> including, of course, the "}"
> - no (almost) empty line separates the keyword from
> its parameters
> - it's easy to find the keyword belonging to a "}":
> (1) look at the "}";
> (2) move your focus to the white space preceding it;
> (3) move your focus up over WHITE space until you see
> BLACK;
> (4) you are looking at the keyword!
> 
> It isn't a dogma to me, just a rule of thumb to improve
> readability of _my_ code. To check braces, I don't (ab)use
> my eyes; 'Match Braces' will do that faster and more reliable
> than I ever could. I don't care much about the braces -- they
> are for the _computer_, not for me; I don't need them.
> Indentation is for humans, that's all _I_ need.
> For me the most powerful formatting means is white brace-
> free space (horizontally and vertically; and comments, of
> course).
> 
> The same style can be used for other 'bracing pairs' like
> #case/#break, #if/#else/#end:
> 
> // typical indentation example
> #macro MyObject ( Para )
> DoThis
> DoThat
> #end//macro MyObject
> 
> Those who want aligned braces (and 'bracing pairs') might
> use my Pascal-Style:
> 
> /* typical Pascal indentation */
> if Condition then             begin
> DoThis
> DoThat                    end
> else                        begin
> DoOther
> DoMore                    end;
> 
> Perfectly aligned AND readable, isn't it? :))
> 
> For a real POV-Ray example see my post in p.g on 3rd sept.
> concerning with 'Intersection with quartic: bug?'.
> 
> Oh, I don't want to convince anybody that my style is the
> best -- my intention is to show the friendly coexistence
> of 3 (or more) 'truths'.
> 
> Make POV, not war!
> 
> Sputnik
> 
> 
> e-mail: fr (at) computermuseum (dot) fh-kiel (dot) de

Post a reply to this message

Frank 'Sputnik' Rothfuß <fr### [at] computermuseumfh-kielde> wrote in message
news:3D834E68.BA3FFD7F@computermuseum.fh-kiel.de...

It's because of these types of issues that I comment *every* line. That way,
when I think that breaking my style makes the code more readable/logical, I
can still see exactly what I was doing when I go back.

-Shay

Post a reply to this message