Chas. Owens wrote:
> header comment blocks are wastes of space, that is what good source
> control and documentation is for.
> [author information]
> [copyright]
That stuff used to be mandatory when I coded for a living. Has the industry
changed that much since then?
>> 2. I don't see comment section boundaries.
> What?
Please see bin/newest for examples:
http://www.holgerdanske.com/node/460
Feel free to review the entire package, if you're in the mood. :-)
>> 6. I don't see command line options/ processing.
> I don't think it has command line options, all of its options come
> from a config file.
I like to layer my options -- hard-coded defaults, that can be overridden by
environment variables, that can be overridden by configuration file settings,
that can be overridden by command line options, etc.. The number and kind of
levels, and their order of precedence, vary as needed.
>> [4 column indentation]
> the only True Way is to use tabs for indent levels and spaces for
> alignment, this allows the user to set his or her indentation to
> whatever he or she wants by modifying how many spaces a tab displays.
> [72 columns maximum] is still a religious issue, not a coding issue.
Readability is a coding issue. Kernighan and Pike make the valid point that
consistency is key [1].
I've tried the "let the user pick tab width" approach, but found that trying to
resist the "1 tab equals 8 spaces" legacy was futile. Code is displayed by
many programs other than editors operated by knowledgeable users; breaking
convention means breaks readability.
Of the C, Perl, etc., and similar code I've seen throughout my lifetime, 4/72
seems to have a plurality.
> Package management is a key differentiator between hacked together
> systems and professional systems. I should be able to ask the
> machine's package management system "what package does this file
> belong to and what version is that package" -- with a checksum
> comparison to ensure the file has not been tampered with.
Package management systems are nice, but I run/ experiment with many platforms
and don't have the time to package all my scripts on all of them. Many of my
Perl scripts are installed via:
scp dpchr...@fileserver:~/released/foo-1.23/foo /usr/local/bin/.
Thus, the need to make them stand-alone, with header comment blocks, version
control tags, etc..
The ones I've put more effort into are installed via:
perl Makefile.PL
make
make test
make install
Those have a README, LICENSE, Changes, etc., files, regression tests, POD, etc..
>> 11. Use h2xs ...
> Unless you are actually coding XS, you should use Module::Starter
> instead.
I wasn't aware of Module::Starter -- thanks for the tip! :-)
>> 13. You're using a lot of 'my' variables to fetch fields from data
>> structures.
> I just tend to use the data structure directly.
It's good to know I'm not missing out on a better technique.
David
[1] http://www.informit.com/store/product.aspx?isbn=020161586X
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
