 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (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'
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
