In general, I don't find the list of rules themselves very interesting. What is interesting is knowing why someone picked the rules.

Abigail

In general, I don't find the list of rules themselves very interesting. What is interesting is knowing why someone picked the rules.

Short answer: because anything else is evil and not the one true style. :)

But here goes: (I'm lazy, so I'm formatting this as code.)

Read more... (16 kB)

* Always check return values where they are important

To avoid bugs. Die before something worse happens. (that sounds funny :)

But every experienced programmer knows (usually from personal experience) that there really can be a "Fate Worse Than Death"; I shouldn't be surprised if "FWTD" ends up as one of our common acronyms.

* No here-documents, but multi-line q/qq. Even repeated prints are better :)
The here-doc end marker cannot be indented, and I don't want something to be outdented in the middle of something that should be indented. Adding the indent spaces to the end marker means code stops working if it changes, which is VERY bad.

That's actually not true about the here-doc end marker not being able to be indented. pgs. 23-26 (ch. 1.11) of the Perl Cookbook give a few examples of how to do that. Below is an example with 4 space indents in front of each of the lines.

    (my $text = <<'    EOT') =~ s/^\s+//gm;
    This is a test of the multi-line, indented HERE 
    document.
    EOT
    print qq($text);
[download]

This code strips out the leading spaces in the text so that you don't have extra spaces there. It still has the drawback that if you change the spacing it will break unless you adjust the <<'    EOT' declaration as well, but at least it lines up better in the code.

On another note, great list and thanks for sharing it.


«Rich36»

Thanks for the annotated list. I don't always make the same decisions, but it's interesting to see where people take an different approach, and why they do that. One question I have, you write:

Logical order in comparisons: $foo == 4, but never 4 == $foo
[download]

It's inside a bunch of rules for which you give "Normal linguistics/interpunction." as a reason. I don't think that applies for the quoted rule - I'd like to know why you would never write 4 == $foo.

Abigail

Alas, many exploits start with a wiley h4x0r getting their foot in the door.

  Logical order in comparisons: $foo == 4, but never 4 == $foo

The latter form is occassionaly useful to quickly signal to the reader that we're interested in array size, not array contents. I.e.,

    foo(@stuff) unless 0 == @stuff;
[download]

The latter form is occassionaly useful to quickly signal to the reader that we're interested in array size, not array contents

That doesnt only apply to arrays. When comparing against literals I find using the literal on the left can make for more readable code, as it can emphasise the important part of the conditional. Just like the way it can be more readable to use $_ when doing a lot of regex work on one string. I also find an added advantage of putting the literal first in numeric context is that it avoids the problem of occasionally using "=" instead of "==", which gets caught as an attempt to assign to a read only value instead of (sometimes silently!) overwriting the variable.


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

Oh... and I think you probably have one too many negations in No map or grep not in void context, unless you really mean that you always use map in void context. :-)

-- Mike

--
just,my${.02}

Oh... and I think you probably have one too many negations in No map or grep not in void context, unless you really mean that you always use map in void context. :-)

You are right. There's a negation too many :)

Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).

Well, I think that for now is just this!

Graciliano M. P.
"The creativity is the expression of the liberty".

#!/usr/bin/perl
#usage:  $0  script
use warnings;
$newfile = $ARGV[0];
$outfile = $newfile . '.tmp';
open( FH,  $newfile ) or die $!;
open( OUT, ">> $outfile" );
while (<FH>) {
         #       $_ =~ s/^\s+//g;   #only gets leading whitespace 
    $_ =~ s/^\s+|\s+$//g;       #gets trailing also 
         #next if $_ =~ /^\s*$/;    #removes blank lines 
         #        $_ =~ s/[\t]+//g;  #gets tabs and ws inside strings 
+ 
                                                    #and leaves \n 
    print OUT $_ . "\n";

}
close FH;
close OUT;

system( "perltidy", $outfile );

rename( "$outfile.tdy", $newfile );
unlink $outfile;
chmod 0755, $newfile;
exit;
[download]

Speaking of style... I took the liberty of rewriting your script.

#!/usr/bin/perl -w
use strict;

my $infile = shift;
my $outfile = "$newfile.tmp";
open my $infh,  '<',  $infile  or die "Cannot open $infile: $!\n";
open my $outfh, '>>', $outfile or die "Cannot open $outfile: $!\n";

while (<$infh>) {
    s/^\s+//g;
    s/\s+$//g;
    print $outfh $_, "\n" or die "Cannot write to $outfile: $!\n";
}

close my $outfh or die "Cannot close $outfile: $!\n";
close my $infh  or die "Cannot close $infile: $!\n";

system('perltidy', $outfile) == 0 or die "Perltidy failed\n";

rename "$outfile.tdy", $infile or die "Cannot rename $outfile.tdy: $!\
+n";
unlink $outfile                or die "Cannot unlink $outfile: $!\n";
chmod 0755, $infile            or die "Cannot chmod $infile: $!\n";
[download]

Changes include:

• use strict
• Got rid of all global variables, including file handles
• Modern three argument open to avoid bugs
• Sane indenting instead of an awful mess
• Parens only where needed instead of ... I guess at random
• Error checking on all system stuff. In the real world, many things can go wrong
• Passing a list of $_ and \n to print instead of a concatenated string, for efficiency
• Renaming of 'newfile'. Why 'new' anyway?
I don't understand:
• why you remove whitespace. perltidy does that for you.
• why you chmod the file using a hardcoded value (use the original permissions!)
• why there is no error message that indicates usage if @ARGV != 1
And you should probably not just filter whitespace like that. The whitespace might be in a string literal!

Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).

Thanks for "purifying" that script Juerd. :-)

It's good to see you put so much thought into it. ++

Far more important though is not any given style of coding but the conformity to that style. There's no more heinous crime than to change the way code is presented half way through a program. Grrrr --.

What would be ideal then, would be to be able to reconfigure how the source looks when you want to work on it. Hmm something along the lines of a turbo-charged Perl::Tidy springs to min, driven by a users config file. (The include/remove unwanted constructors & POD interleaved/at end would be fun parts to write!).

P.S 3 space indent lines up nicely with if statements :o)

'I think the problem lies in the fact that your data doesn't fit my program'.

In vim you can fold lines. I found it really usefull and I have not tried it - but it should not be difficult to fold POD.

P.S 3 space indent lines up nicely with if statements :o)

But, it doesn't align with else, for, while, until and unless.

/prakash

• reads like natural language where appropriate: few abbreviations or multiple-crammed-words for names, postfix if when it reads better, method before Class when it reads better,
• interleave pod: name, synopsis, optional abstract, {globals}, {helpers}, methods/functions {pod, code, ...}, description, see also, license/author,
• help the smart editor within reason: curlies aligned vertically, not afraid to use vertical space, escape properly for weaker color-coders,
• hash+dash*76 visual cut-here lines to delineate logical sections,
• standard #TODO: #REVIEW: #HACK, #BUG: comment keywords for future planning and scanning,

My perltidy does the token-level style: http://www.halley.cc/ed/linux/configs/

See a reasonable example of my style on CPAN in Data::Binder or Data::Favorites.

• Extra spaces in arrayref constructor: [ foo, bar ]
  
• Extra spaces in hashref constructor: { foo => bar }
  

• Extra spaces in arrayref constructor: [foo, bar]
  
• Extra spaces in hashref constructor: {foo => bar}
  

It just takes up space and not necessarily easier to read.

I disagree. In my opinion, they are easier to read. Besides that, I want them to look very different since they construct new data structures, while parentheses are only for grouping.

Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).

I want them to look very different since they construct new data structures, while parentheses are only for grouping

I'll buy into that.