Robert Spier <[EMAIL PROTECTED]> wrote
> >>How about something a little more explicit than XXX, like TODO or FIXME?
> > Some syntax-highlighting editors highlight "XXX". Let's use that feature.
>
>
> Which ones? emacs doesn't seem to do it by default.
>
>
> > And how can you get more explici
>>How about something a little more explicit than XXX, like TODO or FIXME?
> Some syntax-highlighting editors highlight "XXX". Let's use that feature.
Which ones? emacs doesn't seem to do it by default.
> And how can you get more explicit than XXX, anyway?
Funny, but I still think TODO or
On Thu, Aug 30, 2001 at 01:40:15PM -0400, Sam Tregar wrote:
> What I've seen so far resembles a software CPU, which be analogy should be
> able to do anything from run Quake III to compile Java. Does that mean
> it's well-suited to compiling Perl?
The interpreter is highly unsuited to *compiling
On Thu, Aug 30, 2001 at 01:25:37PM -0400, Sam Tregar wrote:
> On Wed, 29 Aug 2001, Simon Cozens wrote:
> > It's almost time to start coding, people, almost.
> Not to be an ass, but is it?
Yes.
> It seems like we're still a long way from having a language spec.
That's not entirely relevant any
On Thu, Aug 23, 2001 at 08:11:26PM -0400, Robert Spier wrote:
> How about something a little more explicit than XXX, like TODO or FIXME?
Some syntax-highlighting editors highlight "XXX". Let's use that feature.
And how can you get more explicit than XXX, anyway?
> > In function definitions, the
At 08:11 PM 8/23/2001 -0400, Robert Spier wrote:
>Just some brief comments... $0.02 or some such. :)
> > The top-level structure of the Perl source tarball should be as
> > follows:
> >
> > /README, etca few top-level documents
> > /doc/ Assorted miscellaneous documentation
Just some brief comments... $0.02 or some such. :)
-R
Quoting Dave Mitchell <[EMAIL PROTECTED]>:
> =item *
>
> "K&R" style for indenting control constructs: ie the closing C<}>
> should
> line up with the opening C etc.
You should provide a short example here - K&R has lots of nasties, you
Okay, this really, really *really* the final draft.
can I have a PDD number, please Dan?
The only change since last is the stuff about if/else layout.
Dave M.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell <[EMAIL P
On Tue 14 Aug 2001 00:55, "Espen Harlinn" <[EMAIL PROTECTED]> wrote:
> Pardon me for butting in at this late stage :-)
>
> Since the purpose of coding conventions and guidelines is to make code more
> readable to the majority of developers, wouldn't it make sence to settle on
> something that can
I think then we are all agreed that the format is
/* comment */
if (...) {
...
}
/* comment */
else {
...
}
with mandatory {}s.
For completeness, we should also include chained else-ifs; I think the
following is reasonably uncontroversial:
/* comment */
if (...) {
...
}
/* comment
Pardon me for butting in at this late stage :-)
Since the purpose of coding conventions and guidelines is to make code more
readable to the majority of developers, wouldn't it make sence to settle on
something that can be processed by a utility like gnu indent ??? This way
developers could use a
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> BTW, I am not sure it has been mentioned already. We should enfore
>> {} even for single line block. Since we use plenty of macros that
>> may be expanded to multi lines, it is much safer and consistent
>> to always use {}.
DS>
At 11:58 AM 8/13/2001 -0700, Hong Zhang wrote:
>This style is not very consistent,
> > if (...) {
> > ...
> > }
> > else
> > {
> > ...
> > }
>
>I believe it would better be
>
>/* comment */
>if (...) {
> ...
>}
>/* comment */
>else {
> ...
>}
Yes, absolutely. Being able to put meaningfull
I believe the advantage of
> if (...) {
> ...
> } else {
> ...
> }
is to write very dense code, especially when the block itself is single
line.
This style may not be readable to some people.
This style is not very consistent,
> if (...) {
> ...
> }
> else
> {
> ...
> }
I believe it w
On Mon, 13 Aug 2001, Dave Mitchell wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > Does this mean avoid:
> >
> > if (...) {
> > ...
> > } else {
> > ...
> > }
> >
> > and instead use:
> >
> > if (...) {
> > ...
> > }
> > else
> > {
> > ...
> > }
> >
> > If my interpretation of what
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > =item *
> >
> > Uncuddled elses: ie avoid C<} else {>
>
> Does this mean avoid:
>
> if (...) {
> ...
> } else {
> ...
> }
>
> and instead use:
>
> if (...) {
> ...
> }
> else
> {
> ...
> }
>
> If my interpretation of what it means is cor
Here's the final draft. Please consider it formally submitted; someone
(Dan? Ask? Adam?) needs to assign it a number, please.
Dave.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell <[EMAIL PROTECTED]>
Class: Internals
17 matches
Mail list logo
