On Tue, Oct 17, 2006 at 11:41:06PM +0200, Leopold Toetsch wrote:
> Anything that has the smallest smell of ever needing an extra statement after
> if or else shall use braces in the first place (IMHO).
Predicting the future is something humans are bad at, sadly.
--
Chip Salzenberg <[EMAIL PROTEC
On Nov 12, 2006, at 6:46 PM, Chip Salzenberg wrote:
char *p, q; /* not misleading, at least */
Here we see clearly expressed that both *p and q are of type char.
I think it IS misleading. I would do this as:
char *p;
char q;
As MJD says, it's better to look than to think.
On Tue, Oct 17, 2006 at 04:01:36PM -0500, Andy Lester wrote:
> if ( foo ) {
> bar();
> }
> else {
> bat();
> }
Well, that's not correct either: Our coding standards already say to omit
needless braces, and don't space inside the parens of if/while/etc. Thus,
this is the preferred format:
On Tue, Oct 17, 2006 at 02:33:55PM -0600, Kevin Tew wrote:
> While exploring Parrot internals I started cleaning up some code.
> I'll post patches to the list, but here are some things that are not
> defined by the coding standards, but of which I'm a fan.
> So the question is are they acceptable
mes.) instead, this should be one test, and should
report filenames upon failure, like the coding standard tests do.
~jerry
On Oct 25, 2006, at 3:23 PM, jerry gay wrote:
one overall test for perlcritic is fine with me. there's nothing
stopping us from parsing perlcritic output if we want a different
format, however i'd rather not go that far.
additionally, i'd like to see less verbose output from perlcritic. the
tho
On 10/25/06, Chris Dolan <[EMAIL PROTECTED]> wrote:
On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote:
> modify perl coding standard test format to match the c tests--one test
> per standard, rather than one test per file.
>
> coding standard tests are designed to test ma
On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote:
modify perl coding standard test format to match the c tests--one test
per standard, rather than one test per file.
coding standard tests are designed to test maintainability, not
functionality. testing parrot functionality is much more
On 10/24/06, Will Coleda <[EMAIL PROTECTED]> wrote:
Not all tests follow the "one test reporting on many files" paradigm:
see t/codingstd/perlcritic.t
FWIW,in general, I prefer the perlcritic method.
as i just wrote in a new ticket for perl coding standard test reforma
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40596]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40596 >
modify perl coding standard test format to match the c tests--one test
per stand
]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40593 >
this test differs from other coding standard test in output format:
~ should display filenames for failing files
~ should execute as one test, not many
there may be othe
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40593]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40593 >
this test differs from other coding standard test in output format:
~ should disp
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew:
> > I view lines as a valuable resource. I like to fit whole functions on
> > the screen when possible so I'm more of a fan of
If you are out of lines:
$ perl -e'++$lines for 1..1000'
helps for some time, then pleae restart.
> > if (foo) b
Please, let's go with whatever's written in the PDD.
Coding standards discussions = much heat, little light.
I'm sorry I responded to anything in this thread in the first place.
Please.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew:
> if ( foo )
> bar();
> else
> bat();
> if ( foo )
no spaces in the parens. No example in pdd07 is looking like this. There where
some ident rules in that pdd some time ago regarding that.
Above vs.:
if (foo) {
bar();
}
else {
Kevin Tew wrote:
> 1) *s should go right next to the type in function declarations and
> definitions
>
> /* incorrect */
> do_thaw(Parrot_Interp interpreter, PMC * pmc, visit_info *info)
> /* correct */
> do_thaw(Parrot_Interp interpreter, PMC* pmc, visit_info* info)
Disagree. Consider:
char* fo
Am Dienstag, 17. Oktober 2006 22:33 schrieb Kevin Tew:
> While exploring Parrot internals I started cleaning up some code.
> I'll post patches to the list, but here are some things that are not
> defined by the coding standards, but of which I'm a fan.
> So the question is are they acceptable in th
Kevin Tew wrote:
Jerry thanks for finding the reference in pdd07.
Note I'm not trying to start a preference war here, I would just like
Chip to rule on some things that are not in the coding spec yet.
Thanks,
Kevin
Prvious mail should have read:
if ( foo )
bar();
else
bat();
I cant find
I cant find it in the spec pdd07 but I though Chip said no curlies on
single statements bodies of ifs
if ( foo )
bar();
else
bat();
I view lines as a valuable resource. I like to fit whole functions on
the screen when possible so I'm more of a fan of
if (foo) bar();
else bat();
Cu
On Tuesday 17 October 2006 14:01, Andy Lester wrote:
> On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
> >if (!info->thaw_result) info->thaw_result = pmc;
> >else *info->thaw_ptr = pmc;
>
> No, definitely not.
>
> if ( foo ) {
> bar();
> }
> else {
>
On 10/17/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
>if (!info->thaw_result) info->thaw_result = pmc;
>else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
if
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
if (!info->thaw_result) info->thaw_result = pmc;
else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:
On 10/17/06, Kevin Tew <[EMAIL PROTECTED]> wrote:
1) *s should go right next to the type in function declarations and
definitions
I disagree; they should go right next to the name being declared,
since C declarations are designed to reflect the way the declared item
is later used: PMC *pmc, vi
While exploring Parrot internals I started cleaning up some code.
I'll post patches to the list, but here are some things that are not
defined by the coding standards, but of which I'm a fan.
So the question is are they acceptable in the parrot code base.
1) *s should go right next to the type
Jerry Gay (via RT) wrote:
> *.l and *.y are c files, and must meet the coding standards for this filetype.
> ~jerry
>
By "this filetype" I assume you mean the C standard. Although these
files contain C code and that code should be written to the C standard,
they are not C files. Each should have
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40513]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40513 >
*.l and *.y are c files, and must meet the coding standards for this filetype.
~jerry
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> this patch adds a POD section on top of 'src/nci_test.c'. I also tried to
> make 'nci_test.c' more conformant to the coding standards from 'pdd07'.
Thanks, applied.
leo
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #31447]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31447 >
Hi,
this patch adds a POD section on top of 'src/nci_test.c'. I also tried t
On Sat, Sep 15, 2001 at 03:11:33PM -0500, Gibbs Tanton - tgibbs wrote:
> Ok everyone, I have changed all of the .c and .h files to match the coding
> standard. I also changed all instances of Perl_Interp to Parrot_Interp. I
> want to give everyone a chance to yell NOOO
&
29 matches
Mail list logo
