Hi, I learnt perl by reading those perl books (camel,etc.). There has never been someone to look over my shoulders. I suspect there're many people like me, maybe a majority of perl programmers. In the back of my mind, I am always wondering how much of what I've been doing is not quite right, e.g., there is a better way. Although "there is more than one way to do it", I'm sure some of those are bad. PM is a great place, yet I don't feel comfortable posting a code example, and say "guys, please do a code review for me". Is there an appropriate node at PM for that?

Just as an example, here's a piece of code I came up in the past few minutes since I'm tied of writing those java been getter/setters (and my old emacs function is seeing its limits). I just wanted an interactive way to create a java bean class, i.e., in stdout, enter "int,age" will add a bean property "age" with type "int" and its getter/setter, and enter a blank line to quit. How's the code? what can be improved, in terms of idioms,styles, etc. 

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

my %init_value = ('int'=>'0',
                  'long'=>'0l',
              );

print "package: ";
my $package = <>;
chomp $package;
print "class: ";
my $class = <>;
chomp $class;

#print the header
open(OUTFILE, ">$class.java") or die "Can't open $class.java for writi
+ng: $!";
print OUTFILE<<HEADER;
/**
* \$Source:\$
* \$Date: \$
* \$Revision: \$
* \$Author: \$
*
**/
package $package;

public class $class\{
HEADER

my %map = ();
print "Enter bean property (e.g. int,name\n";
my $line;
do{
    $line = <>;
    chomp $line;
    my($type,$name) = split(/,/,$line);
    if ($type && $name){
        $map{$type} = $name;
    }else{
        if($line){
            print "Invalid: $line\n";
        }
    }
}while($line);

# print out the fields, and init values
foreach my $type ( sort keys %map ){
    my $value = defined $init_value{$type} ? $init_value{$type} : "nul
+l";
    print OUTFILE "\tprivate $type _$map{$type} = $value;\n";
}

#print out getters/setters
foreach my $type (sort keys %map){
    my $name = $map{$type};
    my $method = ucfirst $name;

    print OUTFILE<<END;
    public $type get$method(){
        return _$name;
    }

    public void set$method($type $name){
        _$name = $name;
    }

END
}
print OUTFILE "}\n";


close(OUTFILE);

[download]

Replies are listed 'Best First'.
Re: A place for code reviews
by BUU (Prior) on Aug 30, 2004 at 20:35 UTC
[reply]
Re: A place for code reviews
by ambrus (Abbot) on Aug 30, 2004 at 18:06 UTC
[reply]
      Well, those are sections for code that might be useful for other people. What I'm thinking maybe code that's useless to others, or not even complete.
[reply]

        I would think even incomplete things can go to Snippets.

        Pity the site documentation (Guide to the Monastery) is outdated so does not give you much help in this.

        Updated link.

[reply]
Re: A place for code reviews
by hv (Prior) on Aug 31, 2004 at 10:48 UTC

    For this sort of thing I prefer to build up a string, and print the whole string at the end. This allows me to keep related things together: it scares me, for example, that there is so much distance between the point that you emit the public class $class\{ and the point you emit the closing '}'. Instead I might wrap it as something like:

      sprintf <<CLASS, $class, $classdef;
public class %s {
%s
}
CLASS

    [download]
    .. and I'd probably end up putting it in a little function.

    I do this because I find it more robust against future changes. Programs like this tend to get extended over time in a manner rather like the expansion of the universe - any two lines of code will tend to get further apart as time passes, and by the time the code emitting the '{' and the '}' are in separate source files you've created a big maintenance headache.

    Another benefit of building up a string to be written at the end is that it doesn't create a (broken) output file if you break out of the program during the 'enter properties' loop.

    Hugo

[reply]
[d/l]
[select]

      Programs like this tend to get extended over time in a manner rather like the expansion of the universe - any two lines of code will tend to get further apart as time passes,

      Good advice and even better metaphor. This advice is pertinent and relevent to something ive been working on recently, and will almost certainly lead to some implementation changes. Thanks a lot. :-) ++


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi
[reply]
Re: A place for code reviews
by greenFox (Vicar) on Aug 31, 2004 at 13:03 UTC

    Seekers of Perl Wisdom with a suitable subject line "Request for review- code that does x" is probably the best place for this sort of thing, you are after all seeking Perl wisdom :)

    --
    Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

[reply]
Re: A place for code reviews
by rickest (Novice) on Sep 03, 2004 at 07:04 UTC
    This isn't exactly what you were asking for, but I'd recommend Effective Perl Programming by Joseph N. Hall and Randal Schwartz. It's for people who know how to program and know perl but don't necessarily know how to program in Perl. Good luck, Rick
[reply]

Back to Perl Monks Discussion