On Tue, 5 Jun 2001, Hugo wrote:
I'd also like to see a specification for indentation when breaking long
lines.
Fwiw, the style that I prefer is:
someFunc( really_long_param_1,
(long_parm2 || parm3),
really_long_other_param
On Tue, 29 May 2001 18:25:45 +0100 (BST), Dave Mitchell wrote:
diffs:
-KR style for indenting control constructs
+KR style for indenting control constructs: ie the closing C} should
+line up with the opening Cif etc.
On Wed, 30 May 2001 10:37:06 -0400, Dan Sugalski wrote:
I realize that no
Hi Dave, I'm not currently subscribed to the p6 lists but noticed your
guidelines while browsing.
I'd like to see some more 'should's in the layout section; in particular:
- binary operators should have a space on either side;
- parentheses should not have space immediately after the opening
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans multiple lines, the opening brace must line up
with the if or while, or be at the end-of-line otherwise.
I certainly will not change existing
On Tue 29 May 2001 19:25, Dave Mitchell [EMAIL PROTECTED] wrote:
=item *
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans multiple lines, the opening brace must line up
with the if or while, or be at
On Tue 29 May 2001 19:25, Dave Mitchell [EMAIL PROTECTED] wrote:
=head2 Portability
Related to extensibility is portability. Perl runs on many, many
platforms, and will no doubt be ported to ever more bizarre and obscure
ones over time. You should never assume an operating system,
On Wed 30 May 2001 16:37, Dan Sugalski [EMAIL PROTECTED] wrote:
At 04:23 PM 5/30/2001 +0200, H.Merijn Brand wrote:
But I know I'm rather alone on this, though I'm not just someone saying:
Cause that looks nice. I have several reasons for dong so and can defend
my stance.
Just to head off
On Wed 30 May 2001 16:12, Dave Mitchell [EMAIL PROTECTED] wrote:
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans multiple lines, the opening brace must line up
with the if or while, or be
On Wed, May 30, 2001 at 04:23:58PM +0200, H.Merijn Brand wrote:
On Wed 30 May 2001 16:12, Dave Mitchell [EMAIL PROTECTED] wrote:
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans
At 04:23 PM 5/30/2001 +0200, H.Merijn Brand wrote:
But I know I'm rather alone on this, though I'm not just someone saying:
Cause that looks nice. I have several reasons for dong so and can defend
my stance.
Just to head off potential formatting/code style issues... (And this is
*not*
On Wed 30 May 2001 16:29, Graham Barr [EMAIL PROTECTED] wrote:
On Wed, May 30, 2001 at 04:23:58PM +0200, H.Merijn Brand wrote:
On Wed 30 May 2001 16:12, Dave Mitchell [EMAIL PROTECTED] wrote:
:::
But I know I'm rather alone on this, though I'm not just someone saying: Cause
that looks
Larry Wall [EMAIL PROTECTED] writes:
Dan Sugalski writes:
1) The indentation should be all tabs or all spaces. No mix, it's a
pain.
This will devolve into an editor war, and I don't think it's a real
issue.
I'm not positive that it will. I can provide the magic incantations that
work for
On Wed, May 30, 2001 at 06:27:39PM -0500, Jarkko Hietaniemi wrote:
On Wed, May 30, 2001 at 03:51:11PM +0200, H.Merijn Brand wrote:
On Tue 29 May 2001 19:25, Dave Mitchell [EMAIL PROTECTED] wrote:
=head2 Portability
Related to extensibility is portability. Perl runs on many, many
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
-Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wredundant-decls -Wnested-externs
-Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings
-Wconversion -Waggregate-return -Winline
The only problem
Well, My first draft of Conventions and Guidelines for Perl Source Code
passed by with remarkably little scathing. Either you all loved it,
or just didn't read it. (Shades of Warnock's Dilemma). I've just produced
a second draft, hopefully taking on board the comments from the first round.
(And
On Tue, May 29, 2001 at 04:48:59PM -0400, Dan Sugalski wrote:
1) The indentation should be all tabs or all spaces. No mix, it's a pain.
(As has been already pointed out) 4 column indent per level, all spaces.
Can you explain why you think it is a pain. I would say converting between
all tabs
At 09:55 PM 5/29/2001 +0100, Graham Barr wrote:
On Tue, May 29, 2001 at 04:48:59PM -0400, Dan Sugalski wrote:
1) The indentation should be all tabs or all spaces. No mix, it's a pain.
(As has been already pointed out) 4 column indent per level, all spaces.
Can you explain why you think it is
Dan Sugalski writes:
: 1) The indentation should be all tabs or all spaces. No mix, it's a pain.
This will devolve into an editor war, and I don't think it's a real issue.
Larry
At 03:35 PM 5/29/2001 -0700, Larry Wall wrote:
Dan Sugalski writes:
: 1) The indentation should be all tabs or all spaces. No mix, it's a pain.
This will devolve into an editor war, and I don't think it's a real issue.
Nope, the text editors aren't at all the issue. It's much more an issue of
On 2001-05-29 18:25:45, [EMAIL PROTECTED] wrote:
The following Imust apply:
=over 4
=item *
8-wide tabs
=item *
4-wide indents for code, 2-wide indents for nested CPP #directives
Please don't *require* the use of literal TABs (8 characters wide) to
achieve 4-character
20 matches
Mail list logo
