Hi,

"Pavel Minayev" <evilone@omen.ru> wrote in message news:acm7f7$130f$1@digitaldaemon.com...
> "Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:acm5gq$116p$1@digitaldaemon.com...
>
> HOW is it easier to read? For you, maybe. But personally, I really hate unneeded braces.
>
> Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do
> with consistency, speed, safety, etc etc. It's just what one particular
> person considers neater (or easier to read, whichever you prefer). But
> even though most people seem to prefer to put braces everywhere, it's NOT
> the reason to force other people to code in their style. You wanna code
> it that way - NOTHING stops you from doing so. You work in a team - adopt
> a standard to be used by all members of that team. Just don't decide
> for other people, that might have opinion different from yours. As long as
> it doesn't harm, at least. And does it?

Of cause it is a matter of personal taste. I find it easier to maintain, mainly because it is easier for me to read. And it is easier to read, because I have gained the habbit due to style guides we are using. In C, I will claim that it is also safer, because you don't see errors like this one:

    if (something);
        conditional_statement;

However, this issue is already addressed by other means in D (by eliminating ";" as the empty statement).

Style guides are valuable within a development group, and I'll claim that some of the elements normally found in style guides can be moved into the language for the benefit of us all. The empty statement is a good example of this, already considered by Walter. Other elements that should definitely not be moved into the languages are guide lines that needs to be broken, although rarely, in order to solve specific problems. An example is a line length limit; if D had a limit on the line length, it would make it impossible to refer to extremely long external symbols. Also, when considering making a some style guide part of the language, the complexity of the language should be considered. Requiring braces does not making the language any more complex.

I'll prefer consistency over freedom, as long as no freedom is taken away from me, that I need to solve problems. Because a piece of code is part of one project today, it does not mean that it is not part of a dozen other projects tomorrow. And I would like the code in these projects to be consistent too.

Regards,
Martin M. Pedersen

I agree,

On another tact, D needs to maintain as much backwards compatibility as possible. And the more that can be ported to D, the faster it will gain acceptance. Image porting some program and having to check each if statement. Simple find replace tools are difficult to use in these situations.

Style guidelines can be very valuable when working in teams. I've found the best style guides to be ones with project specific ones with things like,

"All classes must attempt to be state machines"
"One space between closely related (or opposites) and two spaces between
less realated things"
"All properties will be sorted by letter"
or alternatively
"All properties/methods will be sorted by there association, under
categories"
"Categories will be listed as a contents and will be numbered."
"Each Categories will have a discription"
"Methods/Properties in categories will be indented, while ones that haven't
been placed into at cattorgory (yet) will not be."
"All structs/typedef/enums will appear at the top of the program" -Thats
less specific but you get the idea.
(Although some of these could probably be used in all cases)

Because then you know what to expect and where to find things.


"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ad09eo$2gdj$1@digitaldaemon.com...
> Hi,
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:acm7f7$130f$1@digitaldaemon.com...
> > "Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:acm5gq$116p$1@digitaldaemon.com...
> >
> > HOW is it easier to read? For you, maybe. But personally, I really hate unneeded braces.
> >
> > Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do with consistency, speed, safety, etc etc. It's just what one particular person considers neater (or easier to read, whichever you prefer). But even though most people seem to prefer to put braces everywhere, it's
NOT
> > the reason to force other people to code in their style. You wanna code it that way - NOTHING stops you from doing so. You work in a team -
adopt
> > a standard to be used by all members of that team. Just don't decide for other people, that might have opinion different from yours. As long
as
> > it doesn't harm, at least. And does it?
>
> Of cause it is a matter of personal taste. I find it easier to maintain, mainly because it is easier for me to read. And it is easier to read, because I have gained the habbit due to style guides we are using. In C, I will claim that it is also safer, because you don't see errors like this one:
>
>     if (something);
>         conditional_statement;
>
> However, this issue is already addressed by other means in D (by
eliminating
> ";" as the empty statement).
>
> Style guides are valuable within a development group, and I'll claim that some of the elements normally found in style guides can be moved into the language for the benefit of us all. The empty statement is a good example
of
> this, already considered by Walter. Other elements that should definitely not be moved into the languages are guide lines that needs to be broken, although rarely, in order to solve specific problems. An example is a line length limit; if D had a limit on the line length, it would make it impossible to refer to extremely long external symbols. Also, when considering making a some style guide part of the language, the complexity of the language should be considered. Requiring braces does not making the language any more complex.
>
> I'll prefer consistency over freedom, as long as no freedom is taken away from me, that I need to solve problems. Because a piece of code is part of one project today, it does not mean that it is not part of a dozen other projects tomorrow. And I would like the code in these projects to be consistent too.
>
> Regards,
> Martin M. Pedersen
>
>
>

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ad09eo$2gdj$1@digitaldaemon.com...

> Style guides are valuable within a development group, and I'll claim that some of the elements normally found in style guides can be moved into the language for the benefit of us all. The empty statement is a good example
of
> this, already considered by Walter. Other elements that should definitely not be moved into the languages are guide lines that needs to be broken, although rarely, in order to solve specific problems. An example is a line length limit; if D had a limit on the line length, it would make it impossible to refer to extremely long external symbols. Also, when considering making a some style guide part of the language, the complexity of the language should be considered. Requiring braces does not making the language any more complex.

I'd say such things are better left to the group.

> I'll prefer consistency over freedom, as long as no freedom is taken away from me, that I need to solve problems. Because a piece of code is part of one project today, it does not mean that it is not part of a dozen other projects tomorrow. And I would like the code in these projects to be consistent too.

The problem is, if I would use that piece of code in my projects, I'd prefer it to be "consistent" in a way slightly different from yours...

"anderson" <anderson@firestar.com.au> wrote in message news:ad02u6$28pq$1@digitaldaemon.com...

> wow, I've never had a reply this long before. And I'm kind of happy Walter keep out of this flame war.

Oh yes. I'm even more happy because the way D currently works is mostly what I'd like to see... =)

Hi,

> > I'll prefer consistency over freedom, as long as no freedom is taken
away
> > from me, that I need to solve problems. Because a piece of code is part
of
> > one project today, it does not mean that it is not part of a dozen other projects tomorrow. And I would like the code in these projects to be consistent too.
>
> The problem is, if I would use that piece of code in my projects, I'd prefer it to be "consistent" in a way slightly different from yours...

I don't think that neither yours or my personal preferences are very important. Of cause, I have preferences, and have arguments for them. So do you. But the real value comes when there is consensus in a larger group, and the larger the group is, the more valuable it is. Moving some aspects into the langauge makes the group the global community for these aspects. I would like to see both your and my as input to a style guide (whether enforced or not) that have as broad an audience as possible. When concensus is there, I would set my own preferences aside, and stick to that. Reaching consensus is what is difficult. I don't think it can be done by one dictator; it needs to be done using some sort of democratic process with lots of discussions - like the one we had. Perhaps http://www.digitalmars.com/d/dstyle.html is what I'm talking about, but I don't think it digs into enough detail as it is now. Perhaps we also need more experience with the language in order to develop this any further.

Regards,
Martin M. Pedersen

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ad2rch$pj3$1@digitaldaemon.com...

> the larger the group is, the more valuable it is. Moving some aspects into the langauge makes the group the global community for these aspects. I
would

Large groups are very unefficient when trying to find a consensus. Even in not very large teams (> 10 members), the coding style is set by the team leader, and is NOT the result of the consensus (some small parts of it can be, but 90% is not) - in my practice it is so, at least.

> like to see both your and my as input to a style guide (whether enforced
or
> not) that have as broad an audience as possible. When concensus is there,
I
> would set my own preferences aside, and stick to that. Reaching consensus
is

I wouldn't. As long as it differences from my concept significatly (and seen myself being outnumbered here, I guess I would), I would not follow them anyhow. Why pay such a price? What for? I understand why a single coding standard is needed in a team, but why do the same for the entire community?

> what is difficult. I don't think it can be done by one dictator; it needs
to
> be done using some sort of democratic process with lots of discussions -

Democratic institutes tend to be unstable in general, and the whole
principle
don't work at all often when applied to the Net. Besides, democracy means
freedom for everybody, not freedom for the largest group only - and the
latter
is what I see in those syntax proposals.

It is nice to have some general rules, something like what we've seen in the D reference, maybe a bit more detailed... but whether to follow them or not should be the _free_ choice of any coder. Sacrificing interests of ones for the benefit of others is something that should be avoided, IMO.

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:acviir$1e8g$1@digitaldaemon.com...
>
> "OddesE" <OddesE_XYZ@hotmail.com> ha scritto nel messaggio news:acqeh4$6d5$1@digitaldaemon.com...
> > "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:aclmhe$jit$1@digitaldaemon.com...
> > >
> > >
> > > Sure, then we can apply it to functions:
> > >
> > > int func(int x, int y, int z) return x+2*y+3*z*x;
> > > void func2(int x, int *y) *y = func(x, x+*y, x-*y);
> > >
> > > Or to switch:
> > >
> > > switch(number)    case 1:    return 0;
> > >
> > > Good. And what about structs:
> > >
> > > struct Astruct
> > >    int i;
> > >
> >
> > Mmmm... I didn't think he meant declarations, but
> > statements. struct and function declarations surely
> > should have mandatory braces!
>
> Function _declarations_ are prototypes.
> Theese are function _definitions_, so instructions.
>

I guess you are right that they are definitions, but
to then conclude that that makes them instructions...Mmm

At least if you talk about statements, I consider them
to be kind-of atomic in nature. A function is a definition
of a whole block of statements that can be called under
one name. I understand your standpoints and there is a
lot to say for mandatory braces, but I have tried both
styles and I just don't like mandatory braces. I feel
it obfuscates my code because the pieces of code where
the 'action' happens get spread to thin.

I am not saying I want to save lines, just that I like
to keep the 'action' together. I often code like this:


// ==========================================
/**
  Documentation....
*/
// ==========================================
void myFunction()
{
   myOtherFunction();
   anotherFunction();
   yetAnotherFunction();
}
// ------------------------------------------



// ==========================================
/**
  Documentation....
*/
// ==========================================
void myOtherFunction
{
   // ...
}
// ------------------------------------------


Note how there is lots of space between functions.
Some people call this wasting lines, but I think
that newlines are cheap :) and it helps me easily
seeing where a function ends and where a new one
begins.

Whith code like this however:

if (cond())
{
   myFunction();
}
else
{
   anotherFunction();
}
else if (cond2())
{
   yetAnotherfunction();
}
else
{
   return;
}

I feel the code gets spread too thin and I lose
oversight. Compare it to this:

if (cond())
   myFunction();
else
   anotherFunction();
else if (cond2())
   yetAnotherfunction();
else
   return;

A lot more compact. If there is more code it will
often mean the difference between making a complex
if structure fit on your screen or not. And out of
the screen, out of the heart and mind so to speak... :)

But unlike Pavel, if global consensus where reached
on this I would lay aside my proud and adopt them.
But this is easy to say, because I seriously doubt
that concensus on this wil ever be reached!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:acvt54$2251$1@digitaldaemon.com...
> Roberto Mariottini wrote:
>
> > if (flag1)
> >   if (flag2)
> >       live();
> >   else
> >      if (flag3)
> >         if (flag4)
> >            die();
> >      else
> >         live();
> > else
> >     die();
> >
> > Insert the right braces, and then tell me.
>
> Nice trick screwing up the indentation - almost had me there :-)
>
>         if( flag1 )
>  {      if( flag2 )
>   {     live()                  ;
>   }     else
>   {     if( flag3 )
>    {    if( flag4 )
>     {   die()                   ;
>     }   else
>     {   live()                  ;
>    }}   else
>    {    die()                   ;
>  }}}
>
> lets try a better implementation ...
>
> 1234    flags (1=true)
> 0xxx    nothing
> 100x    die()
> 1010    live()
> 1011    die()
> 11xx    live()
>
> 1&(2|(3&!4))    : live()
> 1&(!2&!(3&!4))  : die()
> ==1&!(2|(3&!4))
>         which is a mirror of live()
>
> hence =>
>
> if( flag1 ) { if( flag2 || ( flag3 && !flag4() ) live(); else die(); }
>
>         ||OR||
>
> if( flag1 ) flag2 || ( flag3 && !flag4() ) ? live(); : die();
>
>
> Which should be just as fast (due to lazy evaluation) and much clearer (or
> have I been doing boolean algebra for too long).
>
> C 2002/5/28


You have waaaaay to much time on your hands!
Get a life!    :P   :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ad365a$160j$1@digitaldaemon.com...

> But unlike Pavel, if global consensus where reached
> on this I would lay aside my proud and adopt them.
> But this is easy to say, because I seriously doubt
> that concensus on this wil ever be reached!

Yes, exactly. The problem is, there are just two radical solutions:
require braces or not. Whichever you choose, there will be A LOT
of people unsatisfied with your choice. I'm afraid that true concensus
is just impossible to reach on this subject.

In the meantime, we could discuss the problem of soft vs hard tabs... =)

OddesE wrote:

> "C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message

>> if( flag1 ) { if( flag2 || ( flag3 && !flag4() ) live(); else die(); }
>>
>>         ||OR||
>>
>> if( flag1 ) flag2 || ( flag3 && !flag4() ) ? live(); : die();
>>
>>
>> Which should be just as fast (due to lazy evaluation) and much clearer
>> (or have I been doing boolean algebra for too long).
>>
>> C 2002/5/28
> 
> 
> You have waaaaay to much time on your hands!
> Get a life!    :P   :)
> 

hehehe. By the way this only took 10 minutes - you can tell by the way I messed up and wrote flag4() due to inadequate checking :-)

C 2002/5/30

PS: I think this works though I have not tested it,  but by my method it seems logically sound.