Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Cohesive source formatting 15 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I've never added the additional newlines between functions, but you've convinced me to experiment with it for a while.

  • I am not sure I would do it that way but at least I can understand why you do.
    • Oh and that, of course, assumes you put your POD in with the code and not at the end of the file or in its own separate .pod file (which I don't do but have seen).
    • So what's your "why"?
      • I am not sold on anything by any means but I generally don't like a lot of POD intermixed with code because for me it makes it harder to read (call it "eye noise").

        I like your way though and may try that. It may be easier to read it "blocks".
      • I tend to favor the PBP book practices and it recommends placing POD at the end of the file. I had no real reason to do any but.
  • One reason I prefer extra blank lines everywhere simply has to do with how I navigate in vim: I use curly brackets to say "jump to the next line". It's enormously useful, give it a try.

  • … POD commands are supposed to go in a paragraph of their own, ie. you are supposed to have a blank line above and below every =foo line.

    • Is this for technical or conventional reasons? I do recall that there were some older POD parsers that had issues with there not being a newline after the final =cut (yeah, that was real fun to debug), but I don't think that such an artifact is a good reason to disregard jplindstrom's proposal.

      • That’s how POD is specified [perl.org]. Interestingly, I see now that =cut is exempt from this rule, at least insofar as it doesn’t have to be followed by a blank line.

        (This rule that POD is broken down paragraph-wise for processing is why Perl 5 POD is so terribly verbose for marking up lists, which is why I have stopped using POD as my personal document markup of choice and soon afterwards switched to Markdown, btw. I hear POD6 is going to do this much better.)

  • Having this kind of discussion can easily become very unproductive and stupid if you just spew opinions.

    Well, this part of the post I agree with 100% :)

    At work, I've already told jplindstrom and others that I don't care what the source code formatting rules are, so long as they're consistent and automated. There's no way in hell I want to enforce them manually, but even if I don't like them, I'll follow them since most (reasonable) programmers have at least semi-coherent styles and when people start

    • Heh. I chose mine in part because I can cajole perltidy into spitting it out… alas, not entirely:

      1. I have a rule that a comma-separated list is either all on one line, or it gets bracketed/parenthesised and written one item per line. (Fat commas do not count.) Perltidy does not help with this.

      2. The other problem is not due to perltidy, but because I don’t know how to deal with it: line-wrapping.

        I have never found a satisfactory rule for how to break lines to hard-wrap them at a specific col

      • Your comma separated list reminded me that I have stuff [perl.org] to make that easier to reformat. Well, I see you use Vim, but maybe someone else will find it useful.
    • Yes, agreed. It's all about trade-offs, and when weighing consistency against arbitrary-layout-rule, consistency has a lot going for it.

      But sometimes you can get two out of two.
  • The perceived affordance idea may be similar to
    the idea of leveraging natural language.

    The difficult thing is that though the
    relationship between statements is like the
    relationship between sentences in written text,
    the relationship between subs is not like the
    relationship beween paragraphs. A program is
    differently structured than an essay, or other
    written work.
    Some higher order graphic organizers become
    necessary.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.