"Ben Scott" <[EMAIL PROTECTED]> writes: > Personally, in the proper context, I find this:
When writing code which will be used, looked at, modified, and maintained by no one else, doing whatever makes you happy and more efficient makes sense, and is more efficient and expedient. When writing code which will be used, looked at, modified, and maintained by a group of people, it is best to agree upon and strictly adhere to a common set of coding standards. This makes the entire group more eficient. The personal likes and/or dislikes of anyone person may or may not bother anyone else in the group. > @foo = split m{blah}; > > to be easier to read and comprehend at a glance than this: > > @foo = split (m{blah}, $_); I find both of these bothersome :) *I* prefer: @foo = split (/blah/); or: @foo = split (/blah/, $actualVariableName); The former implies $_, which need not be explicitly stated in this case. The latter clearly denotes where you're getting your data from. $_ has a *lot* of magical properties which can really screw things up, especially in cases like: map { grep { ... $_ } $_ } @foo; Which $_ is which, and where is each getting it's data from? This is where the use of named variables I find to be better than just depending upon built-ins like $_. > Explicitly specifying $_ over and over again just clutters up the > code with pointless syntax. It's one more thing my brain has to > recognize and process. Right, which is why you shouldn't depend upon $_ in these contexts and explicitly state a variable name (which should also be my'ed into the proper scope :) > I don't arbitrarily assign to $_ and use it at random, the way some > people do. And I do make use of parenthesis, braces, and such, even > when they are not needed, when I find it makes the code clearer. But > I also leave them out when I find it makes the code clearer. No arguments with that. In general, IMO, clarity is of the utmost importance. There are many "best practices" which can help aid clarity though. I find one such practice is to always use func(args) because it makes it blatantly obvious you're calling a function. (perhaps the one exception is with print, but even then, I find myself very often using it there too. To me: print (join("\s", "Some text", func(args), "more text",), "\n" ); is far more readable than print join " ", "Some text", func(args), "more text", "\n"; In the former, if I need to add "stuff" to the join, it's blatantly obvious where it goes. In the latter, it is not. > For a slightly less contrived example, take a script which trims > leading and trailing whitespace from each line in an input file. I > already have one implementation, and I just wrote up another one. [...] > Assuming the reader is familiar with the language, which do you > think will be easier/quicker to comprehend? Both of these hurt my eyes! :) This one is short and sweet: > #!/usr/bin/perl -wp > s/^[\x20\t]*//; # trim leading space > s/[\x20\t]*$//; # trim trailing space but I'd rewrite it as: #!/usr/bin/perl -p s/(^\s*|\s*$)//g; # trim leading/trailing whitespace For a script which optionally took stdin, I'd write it as: #!/usr/bin/perl -w use English; my $file = shift; my $FH; if (!$file) { *FH = *STDIN; } else { open(FH, "$file") || die("Could not open $file: $ERRNO\n"; } while (my $line = <FH>) { $line =~ s/(^\s*|\s*$)//g; # trim leading/trailing whitespace print("$line\n"); } close(FH); > It may be true that someone who *isn't* familiar with Perl would > find it easier to puzzle out the meaning of the longer version. I'm fairly comfortable with perl. I could puzzle out the meaning fairly easily. And I'll even concede that as far as most perl, it's pretty good. But, as is true I'm sure even with my own code, there's always room for improvement :) (/me waiting for Kevin to pipe in here in 4...3...2...1... ;) > But I don't find that a particularly compelling argument. The compelling argument is this: It should be blatantly obvious to whomever is going to be maintaining your code in 6 months what you were thinking :) The easier you make it up front to read your code and discern your mindset, the less time it take the maintainer in 6 months. Many times, that future maintainer is *you* :) > I write Perl programs with the assumption that the reader > understands Perl, the same way I am assuming readers of this message > understand English. :) Ahh, yes. But as the superintendent of the Lawrence, MA, School system has recently shown, even those who *claim* to know the language, often times are just fooling themselves. Just "axe" him :) > This may mean Perl, as practiced, is harder to learn than a language > which is more rigid and always verbose. I think perl is incredibly easy to learn if you learn from a good source. The documentation is one such source. Other people's code is most often NOT a good source! > Many say similar things about Unix. Or Emacs. :-) I'm don't argue > that one approach is right and the other wrong, but I do think that > both approaches have their merits. Which approaches are you talking about? Approaches to learning, or to writing? Or are you saying that there may be an approach to learning Unix without Emacs ? In which case, I declare you a heretic and cast aspersions and insults in your general di-rection! ;) -- Seeya, Paul _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/