Re: My coding guidelines

Excellent list. It's not often you see style guidelines along with some informative prose as to the why of the guidelines.

I was surprised by this part (24):

Note that there is whitespace between ++ and -- and their operands, and between -> and its operands.

What's the consensus on this one? I've always liked snug ++/-- and dereferencing:

   ++$wolverines;
   $rabbits--;
   $wombat->move();
   $turtle = $menagerie->[4];
[download]

As opposed to:

   ++ $wolverines;
   $rabbits --;
   $wombat -> move();
   $turtle = $menagerie -> [4];
[download]

For that matter, I've always made unary operators snug so that you can immediately find it's operand. This might be a holdout from C, but I do actually find the snug form more aesthetically pleasing.

On a somewhat visually related note, the arrow form of the left-associative operator works well with whitespace, however:

   %myhash = ( lizard => 'gecko' );
[download]

Whereas the equivalent comma operator is snug with the left operand.

Thanks again for the list,
Matt

Comment on Re: My coding guidelines Select or Download Code

Replies are listed 'Best First'.
Re: My coding guidelines by Abigail-II (Bishop) on Nov 26, 2002 at 10:47 UTC
Don't say always too fast. Are you sure you always snug unary operators? Including `not`? Abigail	[reply] [d/l]
Re: Re: My coding guidelines by mojotoad (Monsignor) on Nov 26, 2002 at 17:22 UTC
Since I never use 'not' in my code ... yes. ;) I take your point, however -- there are indeed exceptions. I think "english language" unary operators might be a whole class of exceptions since they parse (to us) as English rather than code. By the way, why is '->' a binary operator? From perldoc: "->" is an infix dereference operator, just as it is in C and C++. If the right side is either a ..., {...}, or a (...) subscript, then the left side must be either a hard or symbolic reference to an array, a hash, or a subroutine respectively. (Or technically speaking, a location capable of holding a hard reference, if it's an array or hash reference being used for assignment.) See perlreftut and perlref. Otherwise, the right side is a method name or a simple scalar variable containing either the method name or a subroutine reference, and the left side must be either an object (a blessed reference) or a class name (that is, a package name). See perlobj. Seems like dereferencing is dereferencing is dereferencing, no RHS required. Is there an association going on as well? Matt	[reply]
Re: Re: Re: My coding guidelines by helgi (Hermit) on Nov 28, 2002 at 16:35 UTC
You wrote: Since I never use 'not' in my code ... yes. ;) If not, why not? What do you use instead? I find not is usually the cleanest and most readable operator for all sorts of tests. `die "$usage" if not @ARGV; if (not -r $file) { die "Cannot read $file\n"; } print "$pattern not found in $file\n" if not $found;` [download] And so forth. -- Regards, Helgi Briem helgi AT decode DOT is	[reply] [d/l]
Re(4): My coding guidelines by mojotoad (Monsignor) on Nov 29, 2002 at 23:38 UTC
Re^5: My coding guidelines by Aristotle (Chancellor) on Nov 30, 2002 at 18:18 UTC
Re: Re(4): My coding guidelines by helgi (Hermit) on Dec 02, 2002 at 16:27 UTC


Perl Monk, Perl Meditation
	PerlMonks