[Tutor] Semantic division of source code with U+000C FORM FEED (was: What is the best approach to organizing the order of functions in a module?)

Ben Finney ben+python at benfinney.id.au
Fri Mar 20 03:57:05 CET 2015


(Since this has moved beyond “tutor” material, I'm redirecting to the
‘python-list’ forum; anyone interested, please follow up there.)

Steven D'Aprano <steve at pearwood.info> writes:

> On Fri, Mar 20, 2015 at 09:09:16AM +1100, Ben Finney wrote:
>
> > Use a page break (the U+000C FORM FEED) white space character on a
> > line by itself, to break up the source code into
> > conceptually-separate areas. Your text editor should have a way of
> > navigating to the previous/next form-feed character, as a way of
> > navigating your file at this level.
>
> I thought I liked that idea, but I've since *almost* decided that
> giving semantic meaning (section break) to \f characters is an
> anti-pattern.

To be clear, I'm fine with others choosing not to use U+000C for
semantic divisions in text. As far as I'm concerned, you avoiding the
practice doesn't harm anyone, and (AFAICT) my using it doesn't harm
anyone either. There's room for coexistence.

So I am not convinced by your argument that it's an anti-pattern.

> (1) Not all editors allow you to insert, jump to, and see such page
> breaks. Not even all programmer's editors. I think it's an Emacs
> and/or Vim feature which is basically unheard of anywhere else.

All editors allow you to insert U+000C. They may not go to any special
effort to do so, but I don't rely on an editor for producing characters;
that's what the overall OS user interface is for. So this one is just
false.

Perhaps there are editors which don't display U+000C distinctly; I would
say that excludes them from being “programmer's editor” then. I have yet
to see a programmer's editor which won't render a U+000C as visually
distinct. So this one is mostly false, and the cases where it isn't
aren't relevant IMO for programming.

Not all programmer's editors allow navigation by pages at form-feed
boundaries, true. My “should” can be read as normative: if there's a
programmer's editor which doesn't have that feature, it should :-) So
this one doesn't harm anyone and is irrelevant to an argument for
“anti-pattern”.

> (2) Page breaks are invisible whitespace. If you have a commit hook
> that deletes trailing whitespace at the end of lines and normalises
> line breaks, your page breaks may disappear.

Again, I haven't seen a default “delete trailing whitespace” operation
which deletes U+000C, nor U+000A nor U+000D. All three of those are
defined as vertical whitespace operations, not “trailing whitespace”.

Conventional “delete trailing whitespace” includes U+0020 and U+0008
which are horizontal whitespace.

If you've made one specially to strip U+000C as well, then that's a
perverse case and I don't think that argues against the practice of
inserting them for vertical separation.

> (5) Pedantic: Formfeeds aren't for section breaks, they're for page 
> breaks. Using them in this way is abuse.

They're for page breaks, sure. I did say as much. I don't see how this
argues against the practice.


So, I'm fine with you disliking the practice, but I am not convinced
anything is harmed beyond anti-patterns themselves (e.g. choosing
deliberately to remove U+000C when that's not conventional; choosing to
use a non-programmer's editor). I reject the claim of “anti-pattern”.

-- 
 \      “Software patents provide one more means of controlling access |
  `\      to information. They are the tool of choice for the internet |
_o__)                                     highwayman.” —Anthony Taylor |
Ben Finney



More information about the Tutor mailing list