http://www.perlmonks.org?node_id=821738


in reply to How's My Style Now?

I like code reviews. Good idea.

(1) Since you have three SQL statements starting with identical text, I would create a subroutine for that part.

sub sql_select_from_musings{ return qq| SELECT musing_id, ref_id, heading, entry, DATE_FORMAT(entry_date, '%M %e, %Y') FROM musings |; }
Then for one of your SQL statements, you could type
$sql_statement = sql_select_from_musings() . qq|ORDER BY entry_date DESC|;

(2) I like using PerlTidy. I use the Perl Best Practices .perltidyrc with it.

This will help you apply ap1's suggestion above automatically. For example:

my $apples = 5; my $watermelons = 7;
becomes
my $apples = 5; my $watermelons = 7;

without my having to type extra spaces. If I changed $watermelons to $pears, then Perl Tidy can respace it without me having to add or delete spaces manually.

Several IDEs/editors have ways you can set it up to run Perl Tidy with a single command.


(3) I also like Data::Alias. For example, you could have this line:

alias my $musing_script = $scripts->{'musing'}->{'script'};

After which, you can just type

$musing_script

instead of having to use two levels of dereferencing.

Just my ideas; use whatever suits you.

Replies are listed 'Best First'.
Re^2: How's My Style Now?
by Spenser (Friar) on Feb 08, 2010 at 14:57 UTC
    Thanks for the suggestion. I see your point about making a sub-routine. I go back and forth on the idea of sub-routines: sometimes I can't get enough of them (e.g., that &panel_end() is just a print end_div() line). Other times, especially when I return to a program many months later and confuse myself with overuse of sub-routines, I decide to be more conservative. For instance, for CGI scripts I try to use only sub-routines (calling them from a library) to get data or to process it. I leave the printing of data in the program, not the library. I guess I could do a compromise and use sub-routines for printing, but leave them in the program, at the bottom. I just find that a program with only a list bunch of home-made functions can become confusing later when I need to modify the program.

    -Spenser

    That's Spenser, with an "s" like the detective.

      I understand the tension between too-much modularity and not enough. It's a continuing part of self-aware coding.

      Moving more of your code into modules with POD documentation will help make subroutines less burdensome.

      Using modules lets you group your code into specific name spaces, and when you use explicit imports, you have an instant reminder where the sub came from.

      Using POD lets you use perldoc to read about your code.

      Consider this code:

      use MyMod qw( foo ); foo( $somearg, $another, 57, 'bunnies' );

      I know that foo() comes from MyMod, so I can simply do a perldoc MyMod, to read about foo().

      This beats the heck out of:

      require './mylib.pl'; foo( $somearg, $another, 57, 'bunnies' ); # mylib.pl
      Escpecially since if I refactor MyMod or mylib, and move foo() to another file, failure to update the location info in my code causes a fatal error for the module. With library requires, I can easily get stuck with comments that lie.


      TGI says moo