David Cantrell writes:
On Thu, Feb 02, 2012 at 02:57:35PM +, Smylers wrote:
1 Make lots of small commits, one for each separable bug, feature,
refactoring, or whatever, and clearly described as much: make a
commit whenever you have something which is an unambiguous
On 3 Feb 2012, at 11:25, Smylers wrote:
David Cantrell writes:
On Thu, Feb 02, 2012 at 02:57:35PM +, Smylers wrote:
1 Make lots of small commits, one for each separable bug, feature,
refactoring, or whatever, and clearly described as much: make a
commit whenever you have
Leo Lapworth writes:
I've been asked what would be a good minimum to have as a coding
police for a company that isn't focused on Perl, but uses it
occasionally.
Hi. Thanks for posing such an interesting question, Leo, and for
everybody who's contributed answers -- it's been useful to see the
On Thu, Feb 02, 2012 at 02:57:35PM +, Smylers wrote:
1 Make lots of small commits, one for each separable bug, feature,
refactoring, or whatever, and clearly described as much: make a
commit whenever you have something which is an unambiguous
improvement on the previous
On Sun, Jan 29, 2012 at 9:02 PM, Leo Lapworth l...@cuckoo.org wrote:
I've been asked what would be a good minimum to have as a coding police
for a company that isn't focused on Perl, but uses it occasionally. So if
Perl Best Practices is too much, and you could only have 5 rules for any
perl
On Sun, Jan 29, 2012 at 06:34:06PM -0500, Joseph Werner wrote:
So if Perl Best Practices is too much, and you could only have 5 rules
for any perl script, what would they be?
...
3. Strictures: Always 'use strict' (and 'use warnings' during development)
and
explicitly state your
On Sun, Jan 29, 2012 at 09:02:41PM +, Leo Lapworth wrote:
I've been asked what would be a good minimum to have as a coding police
for a company that isn't focused on Perl, but uses it occasionally. So if
Perl Best Practices is too much, and you could only have 5 rules for any
perl script,
On Mon, Jan 30, 2012 at 11:07:53AM +1100, Damian Conway wrote:
This advice is mainly because there are still an absurd number of people
stuck on 5.8 (for perfectly good reasons), which version I now no longer
support. A simple 'use 5.010' in the code avoids an endless amount of
fruitless
On Sun, Jan 29, 2012 at 09:02:41PM +, Leo Lapworth wrote:
2) all files to be perl tidied (ideally automatically)
How do people recommend setting up automatic perltidy? I've been
considering setting it up so vim would perltidy any time I save a file
with filetype perl. Or maybe tying it to a
On 30 January 2012 13:04, Dominic Humphries d...@thermeon.com wrote:
On Sun, Jan 29, 2012 at 09:02:41PM +, Leo Lapworth wrote:
2) all files to be perl tidied (ideally automatically)
How do people recommend setting up automatic perltidy? I've been
considering setting it up so vim would
I would suggest that Perl::Critic, version control, and modularization
combined with use of perldoc (instead of just comments with hoped for
documentation to be made later/never) and make when a project is ready for
production allow a high coding standard. If incorporated from the start
they are
On 30/01/12 13:46, Dominic Thoreau wrote:
The issue I have with perltidy, nice as it is, is that just making it
a rule can be problematic with existing untidy code bases. Untidy code
+ small change = unrelated blame attaches to unfortunate developer. If
you were writing new code, yes perl tidy
On 30 Jan 2012, at 13:50, Guinevere Nell wrote:
I would suggest that Perl::Critic, version control, and modularization
combined with use of perldoc (instead of just comments with hoped for
documentation to be made later/never) and make when a project is ready for
production allow a high
On Mon, Jan 30, 2012 at 03:00:00PM +, Sam Kington wrote:
One problem with perlcritic is that many of its rules, out of the box, are
silly and annoying. You need to do a fair amount of tweaking to stop it
bitching about stuff you don't care about, before you can get to the bits
where
On Mon, Jan 30, 2012 at 15:00, Sam Kington s...@illuminated.co.uk wrote:
# Checking return values is a good thing. Checking the return value of
# close or print STDERR is downright silly.
You've clearly not done much IPC…
P
On 30 Jan 2012, at 15:26, Paul Johnson wrote:
could you explain why you think checking the return value of close() is
silly? I tend to have the opposite opinion.
I don't have the slides of the talk I gave on Defensive Perl Programming a
couple of years ago, but there's a definite case or
On 30 Jan 2012, at 15:26, Paul Johnson wrote:
On Mon, Jan 30, 2012 at 03:00:00PM +, Sam Kington wrote:
One problem with perlcritic is that many of its rules, out of the box, are
silly and annoying. You need to do a fair amount of tweaking to stop it
bitching about stuff you don't care
On 30 Jan 2012, at 15:40, Sam Kington wrote:
In the code that we write at $WORK, any filehandle we close tends to be a log
file or something, so adding extra boilerplate to our close statements would
just be annoying.
use 5.10;
use autodie;
perhaps?
On Mon, Jan 30, 2012 at 3:40 PM, Sam Kington s...@illuminated.co.uk wrote:
# Checking return values is a good thing. Checking the return value of
# close or print STDERR is downright silly.
In the code that we write at $WORK, any filehandle we close tends to be a log
file or something, so
On 30 Jan 2012, at 15:44, Mike Whitaker wrote:
On 30 Jan 2012, at 15:40, Sam Kington wrote:
In the code that we write at $WORK, any filehandle we close tends to be a
log file or something, so adding extra boilerplate to our close statements
would just be annoying.
use 5.10;
use
On Sun, Jan 29, 2012 at 11:11 PM, Damian Conway dam...@conway.org wrote:
3. Strictures: Always 'use strict' (and 'use warnings' during development) and
explicitly state your minimum Perl version requirement. (e.g. 'use v5.10')
[Ch18: Strictures, Warnings]
I'd point out that if you state a
On 30 Jan 2012, at 16:28, Mark Fowler wrote:
On Sun, Jan 29, 2012 at 11:11 PM, Damian Conway dam...@conway.org wrote:
3. Strictures: Always 'use strict' (and 'use warnings' during development)
and
explicitly state your minimum Perl version requirement. (e.g. 'use v5.10')
[Ch18:
On Mon, Jan 30, 2012 at 4:21 PM, Sam Kington s...@illuminated.co.uk wrote:
If that makes perlcritic shut up, possibly.
Once you no longer need that to happen in your code (because it
happens automatically) you can remove the Perl::Critic policy that
complains about that for you. As long as
On Mon, Jan 30, 2012 at 04:19:19PM +, Mark Fowler wrote:
On Mon, Jan 30, 2012 at 3:40 PM, Sam Kington s...@illuminated.co.uk wrote:
# Checking return values is a good thing. Checking the return value of
# close or print STDERR is downright silly.
In the code that we write at $WORK,
On 29 Jan 2012, at 21:02, Leo Lapworth wrote:
Mine:
1) use strict; use warnings;
- obvious why
2) all files to be perl tidied (ideally automatically)
- it makes reading code easier, as long as there is a standard
3) All variable names to be clear about what they contain, no short
I'm afraid i'm going to be boring and suggest some business requirements.
In comments or pod, note the following:
When you are doing this (even if version control can tell people), and who you
are.
Why? if there is a long worded document/spec, at least give its name. Check it
in under
So if Perl Best Practices is too much, and you could only have 5 rules
for any perl script, what would they be?
Can I have six, please Sir???
These are in decreasing order of bang for your buck
[and with PBP references, in case PBP *isn't* too much]...
1. Commenting: Code in commented
So if Perl Best Practices is too much, and you could only have 5 rules
for any perl script, what would they be?
...
3. Strictures: Always 'use strict' (and 'use warnings' during development) and
explicitly state your minimum Perl version requirement. (e.g. 'use v5.10')
[Ch18:
don't use subroutine prototypes unless you've read about them and know
what you're doing.
On Sun, Jan 29, 2012 at 3:34 PM, Joseph Werner telco...@gmail.com wrote:
So if Perl Best Practices is too much, and you could only have 5 rules
for any perl script, what would they be?
--
Live in a world
Joseph Werner wrote:
I will agree with always 'use strict', I have never [yet] had to not
'use warnings' AFTER development.
If your test suite's code coverage is thorough and your tests closely
mimic your users' real-world usages, then I agree that leaving warnings
on in deployed code does no
don't use subroutine prototypes unless you've read about them and know
what you're doing.
Damn straight.
But I'd also add: even if you *have* read about them and think you know
what you're doing...think again. ;-)
Even when used correctly, prototypes change the behaviour of client code
in
31 matches
Mail list logo
