 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <slm### [at] slimeland com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
