• Pavel Minayev (11/17) Jun 11 2002 That's a different matter. Previously, all the flame was about the
• Walter (6/8) Jun 11 2002 One of the reasons why D is designed to be easy to parse, and why the
• Pavel Minayev (4/8) Jun 11 2002 work
• Matthew Wilson (11/19) Jun 11 2002 I've written one for Java, which I use when I am forced to touch the fil...
• Sean L. Palmer (8/17) Jun 11 2002 filthy
• Pavel Minayev (4/7) Jun 12 2002 It could be; the question is, does it worth the thing? Would you
• anderson (11/18) Jun 12 2002 I think this coding standard thing is a bit out of the water. We don't e...
• Matthew Wilson (26/48) Jun 12 2002 Agreed. In fact I think most of us stopped paying attention to this thre...
• Matthew Wilson (4/22) Jun 11 2002 Like the sound of that, especially if written in D!

"Pavel Minayev" <evilone omen.ru> writes:

"Matthew Wilson" <dm synesis-group.com> wrote in message
news:ae4269$1iga$1 digitaldaemon.com...

 Ouch!

 That's going to start a war
 I am not convinced we need a coding standard for the site, though.

That's a different matter. Previously, all the flame was about the
_compiler_ forcing coding style, and I strongly oppose this. However,
when a group of people works together - whatever the project is -
it would be convenient both for us, and for our readers to see the
same coding style in all programs.

Me personally, whatever the consensus will be, I will follow it.

 I would much prefer that we encourage contributions as much as possible,

and
 let the style evolve collaboratively. Also, it can be good mental exercise
 to read in another style every now and then.

Then maybe we could write a code beautifier for D, and use it to make
code snippets submitted by all authors to look the same?

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:ae492o$1qfa$1 digitaldaemon.com...
 Then maybe we could write a code beautifier for D, and use it to make
 code snippets submitted by all authors to look the same?

One of the reasons why D is designed to be easy to parse, and why the
parsing/semantic are completely separate, is so it is relatively easy to
write a code formatter that works without making assumptions that only work
most of the time.

"Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:ae4dgl$1v5h$2 digitaldaemon.com...

 One of the reasons why D is designed to be easy to parse, and why the
 parsing/semantic are completely separate, is so it is relatively easy to
 write a code formatter that works without making assumptions that only

work
 most of the time.

Oh yes. Such a tool would be quite easy to do.

"Matthew Wilson" <dmd synesis.com.au> writes:

I've written one for Java, which I use when I am forced to touch the filthy
stuff. It is a (COM) plug-in for a multi-language parsing architecture,
written in C/C++.

I could enhance it to include D - indeed I would want to do this anyway -
but it would have to wait a couple of months. Am a little swamped at the
moment. Also, being in C/C++, I guess that would make it less attractive to
our joint cause.

I would be happy to collaborate - in a minor capacity - with anyone who
wants to get together to write one in D.



"Pavel Minayev" <evilone omen.ru> wrote in message
news:ae4g7r$21ov$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ae4dgl$1v5h$2 digitaldaemon.com...

 One of the reasons why D is designed to be easy to parse, and why the
 parsing/semantic are completely separate, is so it is relatively easy to
 write a code formatter that works without making assumptions that only

 work
 most of the time.

 Oh yes. Such a tool would be quite easy to do.

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:ae4orm$2a9s$1 digitaldaemon.com...
 I've written one for Java, which I use when I am forced to touch the

filthy
 stuff. It is a (COM) plug-in for a multi-language parsing architecture,
 written in C/C++.

 I could enhance it to include D - indeed I would want to do this anyway -
 but it would have to wait a couple of months. Am a little swamped at the
 moment. Also, being in C/C++, I guess that would make it less attractive

to
 our joint cause.

 I would be happy to collaborate - in a minor capacity - with anyone who
 wants to get together to write one in D.

Couldn't there be some kind of CGI-bin that was written in D that did
dynamic customized D source code formatting based on user preferences?
(bracket placement, indent pixels, etc)

Sean

"Pavel Minayev" <evilone omen.ru> writes:

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ae5gdh$1pj$1 digitaldaemon.com...

 Couldn't there be some kind of CGI-bin that was written in D that did
 dynamic customized D source code formatting based on user preferences?
 (bracket placement, indent pixels, etc)

It could be; the question is, does it worth the thing? Would you
ever use it yourself, for example?

"anderson" <anderson firestar.com.au> writes:

I think this coding standard thing is a bit out of the water. We don't even
have a journal yet, why not wait a for a few eposodes first. Put your effort
into the mags content rather then ity-bity style standards. These things
will be developed overtime, you can't expect to have everything at once. The
journal may not ever get done if there is to much time spent on these little
things.

Typical programmers, always wanting to do the fun coding stuff and none of
the documentation.

(This is not ment to be a flame, it's just my thoughts)

"Pavel Minayev" <evilone omen.ru> wrote in message
news:ae705e$1is1$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ae5gdh$1pj$1 digitaldaemon.com...

 Couldn't there be some kind of CGI-bin that was written in D that did
 dynamic customized D source code formatting based on user preferences?
 (bracket placement, indent pixels, etc)

 It could be; the question is, does it worth the thing? Would you
 ever use it yourself, for example?

"Matthew Wilson" <matthew thedjournal.com> writes:

Agreed. In fact I think most of us stopped paying attention to this thread
since, as you say, there's a lot of work to be done before we even get to
the point.

Basically, and I hope this can be a last word, I am assuming we will take
the following approach:

1. It has to be readable (though not necessarily attractive) to the
technical editor(s) (decided on a case-by-case - got some more volunteers,
but more welcome!), the editor (me) and the person laying it out (Alix)
2. It has to fit within the space constraints of its presentation format
(initially web-page)

Beyond those two constraints there will be NO further editing or imposition
of a particular person's style. For example, I personally hate K &R, but if
you submit K&R and it's readable and fits, then K&R it will stay!

As well as avoiding the utterly unendable arguments over bracing
conventions, it is respectful to the original author to not bastardise their
work unnecessarily. Furthermore, it can be argued that being exposed to
other styles helps the mind maintain a flexibility that is very helpful on
collaborative projects ... such, as err ... this one!

'nuff said?

Matthew


"anderson" <anderson firestar.com.au> wrote in message
news:ae95po$2424$1 digitaldaemon.com...
 I think this coding standard thing is a bit out of the water. We don't

even
 have a journal yet, why not wait a for a few eposodes first. Put your

effort
 into the mags content rather then ity-bity style standards. These things
 will be developed overtime, you can't expect to have everything at once.

The
 journal may not ever get done if there is to much time spent on these

little
 things.

 Typical programmers, always wanting to do the fun coding stuff and none of
 the documentation.

 (This is not ment to be a flame, it's just my thoughts)

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:ae705e$1is1$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ae5gdh$1pj$1 digitaldaemon.com...

 Couldn't there be some kind of CGI-bin that was written in D that did
 dynamic customized D source code formatting based on user preferences?
 (bracket placement, indent pixels, etc)

 It could be; the question is, does it worth the thing? Would you
 ever use it yourself, for example?

"Matthew Wilson" <dmd synesis.com.au> writes:

Like the sound of that, especially if written in D!

"Pavel Minayev" <evilone omen.ru> wrote in message
news:ae492o$1qfa$1 digitaldaemon.com...
 "Matthew Wilson" <dm synesis-group.com> wrote in message
 news:ae4269$1iga$1 digitaldaemon.com...

 Ouch!

 That's going to start a war
 I am not convinced we need a coding standard for the site, though.

 That's a different matter. Previously, all the flame was about the
 _compiler_ forcing coding style, and I strongly oppose this. However,
 when a group of people works together - whatever the project is -
 it would be convenient both for us, and for our readers to see the
 same coding style in all programs.

 Me personally, whatever the consensus will be, I will follow it.

 I would much prefer that we encourage contributions as much as possible,

 and
 let the style evolve collaboratively. Also, it can be good mental


exercise
 to read in another style every now and then.

 Then maybe we could write a code beautifier for D, and use it to make
 code snippets submitted by all authors to look the same?