# New Ticket Created by Allison Randal
# Please include the string: [perl #60020]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60020 >
1) Remove the coding standards tests from the main 'make test' target.
On Mon Sep 08 00:12:44 2008, cotto wrote:
> On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote:
> > Christoph Otto wrote:
> > >
> > > If those are your thoughts on the subject, then it seems to make
sense
> > > to add the pdd format test to make test. The attached patch does
this.
> > > I'll a
On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote:
> Christoph Otto wrote:
> >
> > If those are your thoughts on the subject, then it seems to make sense
> > to add the pdd format test to make test. The attached patch does this.
> > I'll apply it and mark this ticket as resolved before the ne
Christoph Otto wrote:
If those are your thoughts on the subject, then it seems to make sense
to add the pdd format test to make test. The attached patch does this.
I'll apply it and mark this ticket as resolved before the next
#parrotsketch unless there are any objections.
Excellent idea. T
Allison Randal via RT wrote:
Christoph Otto wrote:
The non-draft PDDs are all passing t/codingstd/pdd_format.t as of
r30810, but two of the draft PDDs aren't. Since they're still drafts
and as such are very likely to change, it doesn't seem worthwhile to
bring them into compliance or to have
Christoph Otto wrote:
The non-draft PDDs are all passing t/codingstd/pdd_format.t as of
r30810, but two of the draft PDDs aren't. Since they're still drafts
and as such are very likely to change, it doesn't seem worthwhile to
bring them into compliance or to have a test depend on them.
I p
James Keenan via RT wrote:
The PDDs in docs/pdds/ are now in substantial compliance with the coding
standard, those in docs/pdds/draft/ much less so. I'll leave this
ticket open, but it's the sort of thing that only needs some cage
cleaning attention every month or so.
The non-draft PDDs are
tewk++ for fixing the remaining tests. We're back to 100% passing:
http://smolder.plusthree.com/app/public_projects/report_details/4350
# New Ticket Created by James Keenan
# Please include the string: [perl #58296]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58296 >
I've spent several hours this morning trying to fix failing coding
standar
The PDDs in docs/pdds/ are now in substantial compliance with the coding
standard, those in docs/pdds/draft/ much less so. I'll leave this
ticket open, but it's the sort of thing that only needs some cage
cleaning attention every month or so.
On Thu Apr 03 12:17:32 2008, [EMAIL PROTECTED] wrote:
> I began working on this today and noticed that many PDDs lack a SYNOPSIS
> section -- and they do quite well without it.
>
> I recommend relaxing the requirements in docs/pdds/pdd00_pdd.pod and
> t/codingstd/pdd_format.t that each doc have SY
Did more work on this tonight. This is a test that, in a certain sense,
will probably never pass completely because there will always be oddball
lines that have to exceed 78 characters. So it will probably never go
into 'make test'.
It is interesting to note that there are extensive stretches of
I began working on this today and noticed that many PDDs lack a SYNOPSIS
section -- and they do quite well without it.
I recommend relaxing the requirements in docs/pdds/pdd00_pdd.pod and
t/codingstd/pdd_format.t that each doc have SYNOPSIS section.
All opposed say "Nay!" within next 24 hours!
k
All PDDs are supposed to conform to coding standards per
docs/pdds/pdd00_pdd.pod. As of r26528 today, we now have a coding
standards test which identifies where particular PDDs fail to live up
to the standards (cf. http://rt.perl.org/rt3/Ticket/Display.html?
id=40653).
As you might expect, quit
On Saturday 17 November 2007 01:43:25 Paul Cochrane wrote:
> That's why I posted a patch to the list, so that this could be
> discussed. My opinion is that code is easier to read if there are
> spaces after commas, and spaces after semicolons (especially in for
> loops).
+1
-- c
On Sat, Nov 17, 2007 at 10:43:25AM +0100, Paul Cochrane wrote:
> > > One nit I have about C-code is that I think there should be a space
> > > after commas and semicolons.
> >
> > I am not a C-coder, so I don't have an authoritative opinion about this.
> > But I would like to ask: In this a comm
On 17/11/2007, James E Keenan <[EMAIL PROTECTED]> wrote:
> Paul Cochrane wrote:
> > # New Ticket Created by Paul Cochrane
> > # Please include the string: [perl #47523]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.org/rt3/Ticket/Display.html?id=475
Paul Cochrane wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #47523]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47523 >
Hi everyone!
One nit I have about C-code is that I think there
ace
after commas and semicolons. The attached file adds a new test to the
coding standards suite and searches for places where a comma or
semicolon is not followed by a space if it does not appear at the end
of a line.
Is this an ok test to add? Are we at least reasonably happy that this
is a good i
isn't a firm standard like many of the other coding standards
> > tests as it will return a false positive on statements like:
>
> Hi Paul,
>
> could you check whether the tests of returns.t are already covered
> by t/codingstd/c_parens.t ?
>
> If so we could close t
On Tue Dec 19 16:30:34 2006, [EMAIL PROTECTED] wrote:
> Nicholas Clark wrote:
> >
> > To seek clarification - having those as global settings for cperl
isn't
> > likely to be an issue? Or having them in editor blocks?
>
> I meant globally.
>
> It's really not a big deal, though. For the immedia
R files? Is this workable?
# Local Variables:
# mode: pir
# fill-column: 100
# End:
# vim: expandtab shiftwidth=4:
I'll add it to the coding standards PDD.
For pir-mode that looks ok to me.
Paul
: pir
# fill-column: 100
# End:
# vim: expandtab shiftwidth=4:
I'll add it to the coding standards PDD.
Allison
Tests have been corrected and now pass again. People are aware of problem.
Closing ticket.
Failed Test Stat Wstat Total Fail List of Failed
---
t/cmd_cd.t 255 65280 36 1-3
t/cmd_exit.t 255 65280 36 1-3
t/cmd_exprOld.t255 6528080 160 1-80
t/cmd_inline.t 255 65
James,
In r16751, certain code was repositioned to conform with Parrot
coding standards. However, when repositioning code in test files,
one is well advised to re-run the tests to see if they all still
pass. This apparently was not done. If they had been done, it would
have been evident that
To quote ticket 41329:
> However, when repositioning code in test files,
> one is well advised to re-run the tests to see if they all still
> pass. This apparently was not done.
Ditto tcl: after the coding standards were blindly applied, the
following tests fail in tcl:
I di
t; one is well advised to re-run the tests to see if they all still
> pass. This apparently was not done.
Ditto tcl: after the coding standards were blindly applied, the
following tests fail in tcl:
Failed Test Stat Wstat Total Fail Li
In each of the 7 affected test files, the initial mention of $topdir in the
BEGIN block was replaced
by 'our $topdir'. These tests now pass when run via 'make buildtools_tests' or
'prove t/tools/
pmc2cutils/*.t' after running 'Configure.pl' but before running 'make'. I also
ran 'make'
succes
ake buildtools_tests
or
prove -v t/tools/pmc2cutils/*.t
You will get the output in the attachment.
ANALYSIS:
In r16751, certain code was repositioned to conform with Parrot
coding standards. However, when repositioning code in test files,
one is well advised to re-run the tests to see
On Mon Jan 22 10:17:48 2007, [EMAIL PROTECTED] wrote:
> On Fri Jan 19 01:48:36 2007, ptc wrote:
> > Which revision of Parrot was this using? The reason I ask is that
> > these files are supposed to be exempt from the coding standards
tests
> > as they are automatically gener
be exempt from the coding standards tests
as they are automatically generated by flex/yacc. I just tried it
with r16702 and the tests pass even when languages/cola/lexer.c has
trailing spaces. Perhaps an 'svn up' makes the tests pass?
Thanks for pointing this out though!
Regards,
Paul
# New Ticket Created by "James Bence"
# Please include the string: [perl #41292]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41292 >
The test t/codingstd/trailing_space.t fails on two files. This patch makes
the test pas
On Mon Jan 08 10:07:38 2007, particle wrote:
> On 1/8/07, Paul Cochrane via RT <[EMAIL PROTECTED]>
wrote:
> > On Thu Nov 16 05:00:35 2006, coke wrote:
> > > Any files that are copied from somewhere else should be immune
from
> > > our coding standards.
&
On 1/8/07, Paul Cochrane via RT <[EMAIL PROTECTED]> wrote:
On Thu Nov 16 05:00:35 2006, coke wrote:
> Any files that are copied from somewhere else should be immune from
> our coding standards.
>
> This includes items in
>
> lib/Parse/RecDescent.pm, which is from CP
On Thu Nov 16 05:00:35 2006, coke wrote:
> Any files that are copied from somewhere else should be immune from
> our coding standards.
>
> This includes items in
>
> lib/Parse/RecDescent.pm, which is from CPAN, or
>
> languages/tcl/library/*, from tcl's standard
On Thu Nov 16 05:00:35 2006, coke wrote:
> Any files that are copied from somewhere else should be immune from
> our coding standards.
>
> This includes items in
>
> lib/Parse/RecDescent.pm, which is from CPAN, or
>
> languages/tcl/library/*, from tcl's standard
On Tue, Dec 19, 2006 at 04:30:08PM -0800, Allison Randal wrote:
> Nicholas Clark wrote:
> >
> >To seek clarification - having those as global settings for cperl isn't
> >likely to be an issue? Or having them in editor blocks?
>
> I meant globally.
Ah. There have been times when it would have been
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl files with
__END__ or __DATA__ blocks.
Sounds good. I can update the Perl::Critic policy, and make a note in pdd07.
Mark it as a cage cleaner task for some point down the
All it does is turn on cperl mode for emacs, and set tabs to 4 spaces
for vim and emacs. Not likely to significantly interfere with any
repository you work on. (I actually gave up on the tab key in vim years
ago. I type literal spaces, and my brain automatically adjusts my
indenting to the surroun
Nicholas Clark wrote:
To seek clarification - having those as global settings for cperl isn't
likely to be an issue? Or having them in editor blocks?
I meant globally.
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl
On Tue, Dec 19, 2006 at 01:08:14PM -0800, Allison Randal wrote:
> Nicholas Clark wrote:
> >On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
> >
> >>to every source file, and a maintenance burden. Both vim and emacs allow
> >>top-level settings of these preferences, which is a more a
Nicholas Clark wrote:
On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
to every source file, and a maintenance burden. Both vim and emacs allow
top-level settings of these preferences, which is a more appropriate
place for them.
This assumes that all the projects you use the e
On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
This assumes that all the projects you use the editor for have the
On Tuesday 19 December 2006 10:05, Allison Randal wrote:
> The editor hints aren't actually very helpful, but they do add clutter
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
I a
s of these preferences, which is a more appropriate
place for them.
The coding standards tests need to check the format of the source code
files directly anyway (for developers who don't use vim or emacs).
Why don't we
just let them be an exception which doesn't require such edi
Having editor hints in the source can have value as it can reduce the
cage cleaning load by getting the editor to indent people's code
consistently (admittedly this only helps people who use emacs and vim
in this case) so in that sense it is worthwhile having them around.
The coda is added to all
On Tue, Dec 19, 2006 at 05:20:06PM +0800, Lee Duhem wrote:
> Allison wrote:
> >My vote is on removing all emacs and vim settings from our source code
> >files.
> and so you can get really bad code appearance.
I'm curious, why is that? We're already discouraging (if not
disallowing) hard tabs in t
My vote is on removing all emacs and vim settings from our source code
files.
and so you can get really bad code appearance.
Paul Cochrane wrote:
The problem that I'm trying to solve
here is: how do we add the settings information to perl language files
such that it doesn't cause problems with __END__ and __DATA__ blocks,
is testable by perlcritic, emacs *and* vim pick up their settings
values, and it doesn't interfer
On Dec 18, 2006, at 1:57 AM, Paul Cochrane wrote:
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless the file is shorter than 3000 bytes.
See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy
for more details:
So this means we need t
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless the file is shorter than 3000 bytes.
See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy
for more details:
So this means we need to put the emacs and vim settings at the end of
the f
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sun, 17 Dec 2006 15:03:10 -0500
From: Chris Dolan <[EMAIL PROTECTED]>
Date: Sun, 17 Dec 2006 13:22:53 -0600
. . .
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless th
From: Chris Dolan <[EMAIL PROTECTED]>
Date: Sun, 17 Dec 2006 13:22:53 -0600
On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote:
> Hi all,
>
> We could close this ticket if a decision were made as to whether or
> not
> the emacs/vim formatting information can be put
On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote:
Hi all,
We could close this ticket if a decision were made as to whether or
not
the emacs/vim formatting information can be put at the *beginning*
of a
file in the case where __END__ or __DATA__ blocks are used within a
perl source
Hi all,
We could close this ticket if a decision were made as to whether or not
the emacs/vim formatting information can be put at the *beginning* of a
file in the case where __END__ or __DATA__ blocks are used within a
perl source file.
What are people's opinions? Would it be too ugly to p
# New Ticket Created by Will Coleda
# Please include the string: [perl #40905]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40905 >
Any files that are copied from somewhere else should be immune from
our cod
Hi all,
The attached patch to the coding standards pdd concerns how we handle
the parrot emacs/vim coda in perl source files when the files contain
__END__ or __DATA__ blocks. The reason for the patch is that vim looks
at only the first or last five lines of a file to see if there is any
Sure.
On Nov 12, 2006, at 7:56 AM, Paul Cochrane via RT wrote:
On Tue Sep 05 13:13:05 2006, coke wrote:
From the recently updated pdd07:
C source files, and files largely consisting of C (e.g. yacc, lex,
PMC, and opcode source files), must end with this block:
/*
* Local variables:
*
s that return
statements look like C rather than C.
This isn't a firm standard like many of the other coding standards
tests as it will return a false positive on statements like:
return (void *) malloc( size );
however, it will pick up the instances it is intended to fix.
Comments welcome,
Pau
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40589]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40589 >
Hi,
This patch adds the C, C and C
tests to the default list of tests run when one p
Hi,
This patch changes the semantics of the checking for the Perl code
coda in Perl::Critic::Policy::CodeLayout::UseParrotCoda. At present
the Perl code coda is checked at the end of the file if no __END__ or
__DATA__ block is present, and is checked before the __END__ or
__DATA__ block if such
On Sep 26, 2006, at 10:21 PM, Will Coleda wrote:
I took a first pass at a perlcritic test: t/codingstd/
perlcritic.t ; this test isn't run by default.
[snip]
Cool! Attached is a patch to simplify this test code a little bit by
leveraging Test::Perl::Critic. I also reworked
CodeLayout::Us
On Tue Sep 19 10:10:45 2006, [EMAIL PROTECTED] wrote:
> On Tuesday 19 September 2006 07:56, jerry gay wrote:
>
> > ~ all non-perl test files must have a shebang
> >
> > i strongly suggest that this be extended to cover all test files.
> > then, as you say, it can easily be tested, and it's value
I took a first pass at a perlcritic test: t/codingstd/perlcritic.t ;
this test isn't run by default.
It reports on only the following perlcritic rules at the moment:
TestingAndDebugging::RequireUseStrict
TestingAndDebugging::RequireUseWarnings
Variables::ProhibitConditionalDeclarat
On Tuesday 19 September 2006 07:56, jerry gay wrote:
> ~ all non-perl test files must have a shebang
>
> i strongly suggest that this be extended to cover all test files.
> then, as you say, it can easily be tested, and it's value can be used
> in other tests to determine it's file type. if you w
On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote:
Jerry,
> all new rt tickets are created via parrotbug. it may not be sexy, but
> it's what we've got :-)
I'm not 100% sure if it worked, as parrotbug gave this warning:
Use of uninitialized value in concatenation (.) or string at
./parrotbug
Jerry,
all new rt tickets are created via parrotbug. it may not be sexy, but
it's what we've got :-)
I'm not 100% sure if it worked, as parrotbug gave this warning:
Use of uninitialized value in concatenation (.) or string at
./parrotbug line 525, line 7.
and the ticket doesn't seem to have
On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote:
This is going to sound rather silly, but... how does one enter a new
ticket to RT? I've got an account, but can't see anywhere on
rt.perl.org where one can add a new ticket. There's also no help link
I can go to to work out what to do. Shou
Jerry,
oh, and yes, i believe the shebang should be in all perl files... but
this isn't specified *yet* in pdd07. if you can enter the ticket, that
would be fantastic, and we'll get a ruling from chip.
This is going to sound rather silly, but... how does one enter a new
ticket to RT? I've got
On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote:
> firstly, line endings are unrelated to this effort and should be a
> separate patch. that's no biggie, and alone wouldn't stop me from
> applying.
I can do that in a separate patch if you want. That's not a major
problem, and probably a good
Jerry,
firstly, line endings are unrelated to this effort and should be a
separate patch. that's no biggie, and alone wouldn't stop me from
applying.
I can do that in a separate patch if you want. That's not a major
problem, and probably a good idea.
I'd not realised some of the issues you b
is a patch of more Perl files that I missed with my previous
patch concerning the perl coding standards coda (the last patch was
only .pl files, this one patches as many of the .t files that I could
find). Some of the files affected by this patch have also been
converted from dos to unix line
Hi Bernhard,
thanks for adding the codas in the Perl files.
No worries! I actually found some more perl files so will make the
necessary changes when I get the tuits.
Could you also provide a test in t/codingstd/code_coda.t, so that future
Perl files will automatically be checked?
Will do :
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40349]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40349 >
Hi,
This is a patch to (attempt to) close the Cage Cleaner's RT ticket
#40278. The
On 9/5/06, via RT Will Coleda <[EMAIL PROTECTED]> wrote:
From the recently updated pdd07:
C source files, and files largely consisting of C (e.g. yacc, lex,
PMC, and opcode source files), must end with this block:
/*
* Local variables:
* c-file-style: "parrot"
* End:
* vim: expandtab
# New Ticket Created by Will Coleda
# Please include the string: [perl #40279]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40279 >
From the recently updated pdd07:
C source files, and files largely consisting of C (e.g
# New Ticket Created by Will Coleda
# Please include the string: [perl #40278]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40278 >
From the recently updated pdd07:
Perl source files must end with this block:
# Local V
# New Ticket Created by Will Coleda
# Please include the string: [perl #39663]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39663 >
Need to:
1) Decide on perl coding standards (stealing from PBP)
2) implemen
On Tue, 14 Dec 2004 14:21:40 -0800, Kevin Scaldeferri
<[EMAIL PROTECTED]> wrote:
> On Dec 14, 2004, at 2:10 PM, H.Merijn Brand wrote:
> > Yes. Ditch emacs. It knows only the *wrong* styles.
>
> uh... yeah... okay. You realize elisp is Turing-complete, right?
Um, yeah. Right. My cat is Turing
On Tue, 14 Dec 2004 23:10:51 +0100, H.Merijn Brand <[EMAIL PROTECTED]> wrote:
>
> Yes. Ditch emacs. It knows only the *wrong* styles.
>
Way to totally make a cogent argument. Next I suppose we'll hear about
how the Sun compilers totally pwn gcc2.
--
Shawn Boyette
<[EMAIL PROTECTED]>
H.Merijn Brand wrote:
Just only today I hit an M$Access database with a table named
`./onderw`.`"Bus"; "Taxi"; "Auto"`
My mail client inexplicably just quit. I assume because it was so
disgusted.
--
David Cantrell
On Dec 14, 2004, at 2:10 PM, H.Merijn Brand wrote:
On Tue 14 Dec 2004 21:49, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Here's what I have to say about clever bracing/spacing styles.
Your bracing/spacing style should not be a detriment. It should not
be a limitation. If common editors have trou
On Tue, Dec 14, 2004 at 11:10:51PM +0100, H.Merijn Brand wrote:
> > If programmers outside your project look at it and go "Huh?" you've just
> > lost yourself a potential patch as they recoil.
>
> Don't think so. spaces and bracing is hard to do it so bad as to other people
> unable to be able to
On Tue 14 Dec 2004 21:49, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Here's all I have to say about tabs.
>
> I expect the source to look the same no matter whose editor, pager, printer
> or utility I run it through. Literal tabs violate this. The end.
>
> Here's what I have to say about
Here's all I have to say about tabs.
I expect the source to look the same no matter whose editor, pager, printer
or utility I run it through. Literal tabs violate this. The end.
Here's what I have to say about clever bracing/spacing styles.
Your bracing/spacing style should not be a detrim
On Tue, Dec 14, 2004 at 11:15:13AM +, Ben Evans wrote:
> On Tue, Dec 14, 2004 at 05:35:53AM -0500, Michael G Schwern wrote:
> > Tripped across this on WardsWiki just now. #5 is my favorite as its often
> > forgotten in the noise.
"Oh, the noise! Oh, the noise! Noise! Noise! Noise!
That's one
On Tue 14 Dec 2004 18:21, Ricardo SIGNES <[EMAIL PROTECTED]> wrote:
> * "H.Merijn Brand" <[EMAIL PROTECTED]> [2004-12-14T11:28:19]
> > About spaces, another thing springs to mind, for which I would gladly kill
> > the
> > responsible people to allow it (I bet M$ was the first to push it): Spaces
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2004-12-14T11:28:19]
> About spaces, another thing springs to mind, for which I would gladly kill the
> responsible people to allow it (I bet M$ was the first to push it): Spaces in
> database table and field names. DON'T! NEVER! Once you start it, you will
>
On Tue 14 Dec 2004 15:15, [EMAIL PROTECTED] (Dominic Mitchell) wrote:
> On Tue, Dec 14, 2004 at 12:21:50PM +, Matt Sergeant wrote:
> > On 14 Dec 2004, at 11:26, Clayton, Nik wrote:
> > >To be honest, I don't care if someone's house style is for TAB to
> > >indent
> > >2, 4, or 8 characters; ho
issues of naming conventions as
> problems a coding standard could/should fix, so everyone improvised in
> their own special way with the stuff that wasn't standardized. At the
> onset, though, a lot of issues we had to deal with were completely
> unknown, since the project took t
On Tue, 14 Dec 2004 16:14:32 +0100, H.Merijn Brand <[EMAIL PROTECTED]>
wrote:
> On Tue 14 Dec 2004 16:04, "Clayton, Nik" <[EMAIL PROTECTED]>
> wrote:
> > I've normally got enough going on in my head when writing code,
> > worrying about the house style should not be one of them.
>
> Wrong. It shoul
On Tue 14 Dec 2004 16:21, "Clayton, Nik" <[EMAIL PROTECTED]> wrote:
> > > I've normally got enough going on in my head when writing code, worrying
> > > about the house style should not be one of them.
> >
> > Wrong. It should be. You write, and someone else - or yourself - has to
> > maintain the
On Tue, Dec 14, 2004 at 02:15:45PM +, Dominic Mitchell wrote:
> On Tue, Dec 14, 2004 at 12:21:50PM +, Matt Sergeant wrote:
>> On 14 Dec 2004, at 11:26, Clayton, Nik wrote:
>>> That's something the editor can care about. When I hit the TAB key it
>>> should just do whatever the house style
> > I've normally got enough going on in my head when writing code, worrying
> > about the house style should not be one of them.
>
> Wrong. It should be. You write, and someone else - or yourself - has to
> maintain the code later. This means that you have to write with style and
> maintainabilit
On Tue 14 Dec 2004 16:04, "Clayton, Nik" <[EMAIL PROTECTED]> wrote:
> > I /think/ he means what the tab key's effect is when typed in
> > his editor of choice
>
> Correct. Hitting TAB should indent to the correct level for the current
> context. I don't especially care whether the editor does b
> I /think/ he means what the tab key's effect is when typed in
> his editor of choice
Correct. Hitting TAB should indent to the correct level for the current
context. I don't especially care whether the editor does by inserting
actual TAB characters or a bunch of spaces.
I've normally got eno
On 14 Dec 2004, at 11:26, Clayton, Nik wrote:
http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards
On coding standards:
I'd add an additional:
* Make sure your tools enforce them, and make complying with them
as simple as possible.
To be honest, I don't care if someone's hou
On Tue, Dec 14, 2004 at 12:21:50PM +, Matt Sergeant wrote:
> On 14 Dec 2004, at 11:26, Clayton, Nik wrote:
> >To be honest, I don't care if someone's house style is for TAB to
> >indent
> >2, 4, or 8 characters; how much second level indentations are indented
> >by;
> >whether or not braces c
; > http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards
> >
> > On coding standards:
> >
> >1. Let them evolve during the first few iterations.
> >2. Let them be team specific instead of company specific.
> >3. Don't write them down if you can avoid it. Rathe
1 - 100 of 121 matches
Mail list logo
