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