On 2013-04-06 05:23, Russ Allbery wrote:
> Niels Thykier writes:
>> [...]
>
>> Ah, that makes sense. I just learned that autodie also have an issue with:
>> open(STDERR, '>&', STDOUT);
>
>> (requring the latter bareword to be \*STDOUT to avoid a syntax error).
>> But it still beats having to c
Niels Thykier writes:
> Do you have some examples of complex usage of Getopt::Long::Descriptive
> by the way? I had a stab at rewriting lintian's option parsing and for
> sometimes I cannot find the way to do it with G::L::Descriptive.
I don't... I don't think we've tried to do anything complic
On 2013-04-06 23:13, Niels Thykier wrote:
> On 2013-04-06 05:26, Russ Allbery wrote:
>>> $opt->mode eq 't' instead of $opt->mode eq 'tags'
>>> $opt->h instead of $opt->help
>> Yeah, I was looking at that when I reviewed the document, and I think
>> that's backwards. It's left over from an old
On 2013-04-06 05:26, Russ Allbery wrote:
>> $opt->mode eq 't' instead of $opt->mode eq 'tags'
>> $opt->h instead of $opt->help
> Yeah, I was looking at that when I reviewed the document, and I think
> that's backwards. It's left over from an old style we had for
> Getopt::Long where it didn't
Niels Thykier writes:
> On 2013-03-29 18:24, Russ Allbery wrote:
>> * For loading configuration files, use Config::Any in most situations.
>> Some older files use AppConfig, but Config::Any is the current
>> standard.
> How do you get errors from Config::Any? Documentation has nothing about
> i
On 2013-03-29 18:24, Russ Allbery wrote:
> * For loading configuration files, use Config::Any in most situations.
> Some older files use AppConfig, but Config::Any is the current
> standard.
How do you get errors from Config::Any? Documentation has nothing about
it AFAICT and the implementation j
Niels Thykier writes:
> I tried to convert lintian-info to Getopt::Long::Descriptive today.
> Attached is a functional patch as far as I have tested.
> I wonder why you recommend the use of the "short" option first. It
> seems to me that putting the long option first will be much more
> descri
Niels Thykier writes:
> On 2013-04-04 01:52, Russ Allbery wrote:
>> For some larger, more complicated code, I've thought about switching to
>> OO exception objects, since that seems to be a best practice and lets
>> you do some other interesting things, like carry a lot more context
>> informatio
On 2013-03-29 18:24, Russ Allbery wrote:
> * Use Getopt::Long::Descriptive for option parsing in any script that
> takes options. Give each option a corresponding single-character option
> unless it's rarely used. When listing the options, give the short
> option first, then |, and then the long op
On 2013-04-04 01:52, Russ Allbery wrote:
> Niels Thykier writes:
>> On 2013-03-29 18:24, Russ Allbery wrote:
>
>>> * Always check the results of operations. For many functions this can
>>> be done with 'use autodie' at the start of a script or module. For
>>> anything not covered by autodie, you
Jakub Wilk writes:
> * Russ Allbery , 2013-03-29, 10:24:
>> * Avoid C-style for statements when possible. Unless you have a need
>> for a subscript when iterating with for, operate on the object directly
>> instead. (ie: "for my $item (@array)" rather than "for my $i
>> (0..@#array)".
> The si
Niels Thykier writes:
> On 2013-03-29 18:24, Russ Allbery wrote:
>> * Always check the results of operations. For many functions this can
>> be done with 'use autodie' at the start of a script or module. For
>> anything not covered by autodie, you should add 'or die "some error:
>> $!\n"' to the
* Russ Allbery , 2013-03-29, 10:24:
* Avoid C-style for statements when possible. Unless you have a need
for a subscript when iterating with for, operate on the object directly
instead. (ie: "for my $item (@array)" rather than "for my $i
(0..@#array)".
The sigil should be $# rather than @#.
On 2013-03-29 18:24, Russ Allbery wrote:
> * Always check the results of operations. For many functions this can
> be done with 'use autodie' at the start of a script or module. For
> anything not covered by autodie, you should add 'or die "some error:
> $!\n"' to the end of function calls that ma
On 2013-04-01 20:57, Russ Allbery wrote:
> Niels Thykier writes:
>> On 2013-03-29 18:24, Russ Allbery wrote:
>
>>> In general, follow the rules in the perlstyle man page and Perl Best
>>> Practices, except we use cuddled elses (else on the same line after }).
>>> And, of course, follow rules belo
Niels Thykier writes:
> On 2013-03-29 18:24, Russ Allbery wrote:
>> In general, follow the rules in the perlstyle man page and Perl Best
>> Practices, except we use cuddled elses (else on the same line after }).
>> And, of course, follow rules below rather than perlstyle if they
>> conflict.
> I
On 2013-03-30 00:16, Niels Thykier wrote:
> On 2013-03-29 18:24, Russ Allbery wrote:
> [...]
>> * Use perltidy and perlcritic. Default [perltidyrc](perltidyrc) and
>> [perlcriticrc](perlcriticrc) files are available.
>>
>
> If we can codify our style in a fashion these can check for that would
>
On 2013-03-29 18:24, Russ Allbery wrote:
> This is the evolution of my original style document, much modified by
> contact with Perl Best Practices. There are some things here that I'd
> personally do differently (I prefer omitting the parens around arguments
> to Perl built-ins, for example), but
This is the evolution of my original style document, much modified by
contact with Perl Best Practices. There are some things here that I'd
personally do differently (I prefer omitting the parens around arguments
to Perl built-ins, for example), but this was the compromise reached
across the group
19 matches
Mail list logo
