in reply to Style and Coding Criticism (part 2)

Update: Congrats on your homework score, and thanks for telling us up front. ;)

1. Don't use POD to store test data. Instead of =item test, consider putting test data under a __DATA__ token at the end of your sources. Or if you're disabling a section of code and want to use POD, use the proper POD tags to disable compilation. =item isn't always seen as a proper beginning of a POD chunk.

2. Completely optional, but I would put a call to exit() before you start defining subs. If I don't see one, I start looking for extra mainline code between and after all the subs.

3. Pick a capitalization style for subroutine identifiers, and stick with it. Your format_time is Perl standard, but CheckRanges is different.

4. Minor note about your #-- END foo sub-routine comments. If I can't see both the top of the sub and the bottom of the sub on a large screen (or with fewer than two page-ups on an average screen), it might be too long. Consider how the task can be naturally divided. These are short subs, and the indentation is mostly consistent, so I wouldn't bother with these closing comments.

5. Dennis and Kernighan (of C fame) fought this battle too, but consider putting a space after keywords like for (...) and return (...). If it doesn't have a space, it looks like a subroutine identifier, and for is not a function.

Check perlstyle for more general Perl style ideas.

--
[ e d @ h a l l e y . c c ]

Replies are listed 'Best First'.
Re: Re: Style and Coding Criticism (part 2)
by PodMaster (Abbot) on Aug 05, 2003 at 23:09 UTC
    Or if you're disabling a section of code and want to use POD, use the proper POD tags to disable compilation. =item isn't always seen as a proper beginning of a POD chunk.
    While I agree with part 1, part 2 is untrue -- stick to properly formed pod, like 
    
#hey some code followed by a blank line

=butter is the pod, and the pod is the butter

=cut followed by a blank line, no more pod

#and here we have some other code

    [download]
    Even if use fictional pod tags, perl will parse it correctly. You should stay away from hidden pod/code, as the behaviour is not guaranteed in future versions (see Pod::Stripper, perlpod if you don't know what it is).

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
      I agree.

      As with Perl syntax, perl will parse a lot of POD constructs which other tools just don't bother to try to read properly. This has been improving, but there are a lot of different tools, from formatters to text editor modes.

      --
      [ e d @ h a l l e y . c c ]

[reply]
[d/l]

In Section Seekers of Perl Wisdom