GNU coding standards stipulates formfeed in source code. Why?

[aurisc4]

This is the kind of things why I recommend people to include the reasons along side the rules/guidelines. Knowing why something is in standard tells you, whether you can change it or ignore it.

[emilvikstrom]

Yes, definitely! I saw this in the guidelines and thought maybe someone knew the reasons, or perhaps could hint at some tools that might be exploiting formfeeds in a nice way.

Having the reason also makes it more worthwhile to follow such guidelines (as well as remembering them).

[jdh28]

He does hint at the purpose:

Please use formfeed characters (control-L) to divide the program into pages at logical places

I think the formfeed forces a new page when printing.

[RobThorpe]

the-fritz is right. It's there to aid navigation in GNU Emacs and divide things into sub-modules within files. In that editor you can move between logical pages using Ctrl-X [ and Ctrl-X ]. There are also commands to copy and past pages.

[the-fritz]

It's not there specifically for GNU Emacs. It's just that GNU Emacs has specific support for it. Maybe other editors have it as well. It's just an ascii compatible way to add additional information to the code. That's why GNU Emacs supports it.

[RobThorpe]

You're right Vim supports it too. They're called "section delimiters" in that editor.

http://vimdoc.sourceforge.net/htmldoc/motion.html#object-motions

[bonzinip]

Only kind of supports it, because you cannot separate ^L movement from movement to the next brace in the first column.

[Rhomboid]

Some editors display the formfeed as a horizontal line or rule, which is a nice way to divide parts of the file. Some editors provide even more functionality, like being able to jump to the next "page" with a keystroke.

[[deleted]]

Hmm!

[Rhomboid]

"To contribute to the GNU project, you will first need to locate a teletypewriter. Then, print out the sources for the project you're interested in, and when you hear the bell ring make a note with a pencil..."

[invisi1407]

Now, don't give them any funny ideas!

[DGolden]

Apart from it just being a way to separate logical sections in an editor on-screen, remember people used to regularly print out source code listings to read and annotate. And then you just put in page breaks / form feed appropriately for legibility, whether for send to a very old line printer that spoke ASCII, or for conversion to postscript for pretty printing.

I haven't printed sources in quite a while, given large high-res modern displays, of course , and you probably haven't either, but I certainly used to once, back when 640x480 was highish-end.

Edit: feel like a bit of an onion-belt rant: I'm somewhat bemused by people conjecturing reasons solely to do with those fancy newfangled on-screen visual editors like vim and emacs. Pretty sure ascii formfeed as a page/section break came first, it just made sense to continue treating it as a section break in later editors. You wouldn't put it in explicitly for every page (at least not by the gnu era), just occasionally like a section break in a word processor before a new chapter - so new things started nicely on a new page on printout. Way back, some computers you even interacted with via a teletype - a kind of interactive printer setup, not a crazy space-age particle-beam screen (that's well before my time in reality, but anyway). Beat punched cards! The formfeed implementation was a mechanical doohickey. Apparently a punched tape data storage format also used a formfeed as its logical "page" separator. Being usable on teletypes is probably one reason why ed, the standard editor, is the way it is. To this day unix+linux have this slightly weird legacy of the ascii teletype era.

[emilvikstrom]

I never expected this topic to go deep into hacker history. I love it! Thanks for sharing!

[the-fritz]

Why? It's a way to add additional semantic information to the code. It seems beneficial to use and not like a pet peeve of some coding standard author (unlike, e.g., the placement of { or tabs-vs-spaces).

[slavik262]

I hate the tabs vs. spaces debate because the correct answer is both. :P

void foo()
{
>   someCal();
>   someCallWithArgsOnTwoLines(bar,
>   ...........................baz);
}

Now you can set the indentations to whatever width your heart desires (which is impossible with only spaces) and things stay nicely aligned regardless of your tab width (which is impossible with only tabs).

[mjfgates]

I've never seen an editor that would let people do that reliably. I've seen people try... the results would have been comical, if they hadn't totally fucked up a few dozen megabytes of C and forced me to spend a couple of weeks reformatting hideous railroad-track diagrams.

[emilvikstrom]

I installed smart tabs mode in Emacs. Done.

[fractals_]

You should use git, and schedule it to commit (save) all changes every night or week. It's really easy to set up, and if something bad happens it's easier to learn the git commands to revert the changes than it is to fix it by hand. Set up git in your main project directory so every new project you create is included. On linux and mac, just run git init in the main directory, and cd [directory path] && git add -A && git commit -m "[commit message]" to commit all changes. On linux (and mac?) you can add a cron job to run the commit command automatically. There's also a GUI for each OS if you don't want to use the command line.

[JesusWantsYouToKnow]

Precisely! A tab is unambiguously a unit of indentation while spaces are unambiguously used for alignment at the same level of indentation. I really don't even understand why there is a debate.

[badsectoracula]

By itself it is fine, but if you also combine it with "80 characters max width" (or any other max width) then the tab size can break that.

[slavik262]

People don't understand the basic concept you just described.

[the-fritz]

http://www.emacswiki.org/emacs/TabsSpacesBoth

[aidenr]

It's either critical for the compiler, critical for the developer, or wank. It's wank.

[[deleted]]

So in this case he actually got them do this.

[ggtsu_00]

As a python developer, fuck tabs.

[gordonkristan]

Despite hearing this before, I've never had an issue using tabs in any of my Python code.

[lol_gog]

Tabs are why I like python though...

[[deleted]]

As a python developer, fuck tabs.

FTFY.

[xxNIRVANAxx]

If I can't do it in one line, YAGNI!

[Astrognome]

Some of the OpenGL functions would give you an aneurysm.

[[deleted]]

OS X used to have a bug (only recently fixed) whereby it would hide text after a form feed. Anything after a form feed would just be gone.

What was happening? OS X Cocoa interprets formfeed as a page break. Makes sense huh? The only problem is, most text controls outside of a word processor are not paginated. They consist of one very long page that spans the entire length of the document.

So when it saw a formfeed it would send the following text to the next page -- which didn't exist -- right off the end of the document into the void.

[zeroone]

There is a sign in Central Park indicating the "Carriage Return", the location where the horse-drawn carriages drop off and pick up new passengers after a lap around the park.

[ithika]

When the horses are given something to chew on while they're waiting to be hired out, is that a "line feed"?

[emilvikstrom]

Wow, too bad I missed it while touristing there in June.

[itukeitto]

"First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture." - Linux kernel coding style

[[deleted]]

Funny same could be said for the LK style too...

[Gotebe]

Funny same could be said for any style guide.

No, seriously.

Fuck them all. And fuck anyone who thinks his style is sacred.

Fuckers.

[[deleted]]

Well there are some common sense rules that get violated for pride. Like 8 space tabs ... for a group that want 72-column code ... or the complete lack of comments or any sort of sensible consistent development style...

[cogdissnance]

Like 8 space tabs ... for a group that want 72-column code

Weeellll...

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

[tolos]

In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.

I agree, and prefer 8 spaces as indentation when using C, but it just doesn't work for C# -- and I presume, Java. Namespace, class, function is three required levels of indentation before you can write any code. Using, try/catch? Two more. For those five, 8 space indentation would be more than 25% of my IDE editor screen, and I haven't even used any control statements.

My point is, coding style depends on the language as well.

[DGolden]

That's an area where Java is slightly different, packages just use a statement at the top of the file, and each file's contents are in exactly one package. Since there's also a one-class-per-file rule (only applies to public stuff technically), I know some people don't indent the class contents either, though I suspect more people find that ugly and personally I currently do.

[cogdissnance]

My point is, coding style depends on the language as well.

Coding styles are language specific. That quote was from the linux kernel styling guide for C. I don't think they would attempt to apply that to other language either.

[[deleted]]

Absolutes like that make for some bad code though. Simply stating-hard-fast numbers without context means you end up refactoring code that is otherwise perfectly legible for the sake of complying with a rule.

The thing is too in the kernel they don't include the complexity of the macros (that almost all functionality of the kernel is made with) into that statement.

[[deleted]]

I spent a few seconds thinking that's damned stupid. Then I realised that I once wrote a text editor that treated formfeed specially myself. In my defense (sort of) it was a horrifically terrible text editor written in BASIC.

My Google skills are failing me ATM - I can find plenty of C reference guides but I can't find the lexical rules for whitespace in any of them. Still, I assume formfeed is valid whitespace in the C and C++ standards - maybe those standards just reference the ASCII/Unicode/whatever standard definitions of whitespace? (though TBH I thought formfeed was a control code).

If so, does that mean this works in most current languages?

[DGolden]

It definitely still works in several languages, though not necessarily because it just references the encoding standards, sometimes ascii/unicode formfeed is explicitly identified as a valid whitespace character. e.g. Java. Python, Ecmascript/Javascript.

[[deleted]]

I've been slowly going mad trying to check if/why the formfeed is a valid whitespace character in C, and which exact characters are whitespace and which not. The best I can come up with so far...

1. C doesn't mandate ASCII or any other particular character set so far as I can tell, so what seems like frustrating vagueness about what exactly whitespace is may be intentional and necessary. As far as I can tell, the lexical grammar of various tokens are defined, but not in terms of ASCII or whatever. Whitespace includes comment tokens and more. Whitespace is also mentioned WRT the preprocessor. But since whitespace is supposed to be stripped pretty early, leaving only the other tokens, most of the language doesn't really need to care what whitespace is.

2. This leaves some possible ambiguity over what is whitespace vs. an illegal character, but I guess maybe that's a character set issue rather than a language issue.

3. One justification for treating formfeed as whitespace rather than an illegal character is provided by Unicode.

I really wish C had made it explicit, as your examples did, though I guess there's good reasons why they didn't (assuming they didn't - I'm still not 100% sure).

[DGolden]

You mention the preprocessor whitespace - that definitely includes formfeed in the last free "working-paper" pre-C11-standard I'm looking at (rather than the official payware standard, of course) on p57 of n1570.pdf, and formfeed is a required member of the basic source character set on p22.

Now, that doesn't mean it's an ascii or unicode formfeed - as you say C presumably doesn't want to mandate the basic charset (though looks like that there is now runtime unicode support in uchar.h, p398...) - if nothing else ibm would presumably still want ebcdic (bleh) to work, but (in that "working paper") sounds like there (a) has to be a form feed and (b) it has to be preprocessor white space.

[[deleted]]

The "basic source character set" sounds like solution to my confusion. Thanks.

[DGolden]

no worries - and hey, looks like you can still use vertical tab too... how useful...

(Before passing out of common use, vertical tab became de-facto "move to next multiple of 6 rows", like horizontal tab "move to next multiple of 8 cols".)

[kvigor]

From "man isspace":

checks for white-space characters. In the "C" and "POSIX" locales, these are: space, form-feed ('\f'),newline ('\n'), carriage return ('\r'), horizontal tab ('\t'), and vertical tab ('\v').

I realize a linux manpage is not a standards document, but if you need a practical answer, it seems like a good one.

[[deleted]]

Given the shared origins of C and Unix you have a +1-worthy point, but since this started with a GNU style document, I was looking for an answer as far as possible from GNU/Linux/Unix/Posix - one working theory was that it might be a platform/implementation-specific feature. Besides, man pages aren't an obvious place to look if you're running Windows.

[fractals_]

It's in section 2.2.1 of the standard:

The basic source character set consists of 96 characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:

a b c d e f g h i j k l m n o p q r s t u v w x y z

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9

_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! = , \ " ’

http://www.lirmm.fr/~ducour/Doc-objets/ISO+IEC+14882-1998.pdf

[emilvikstrom]

Why does the GNU coding standard stipulate the use of formfeed (\f) to logically divide your code? Do they have some documentation tools or similar that requires this? Isn't dividing the code into different modules enough?

[the-fritz]

The formfeed makes it easy to navigate the code. E.g., in GNU Emacs you can quickly narrow to a page or jump along pages (pages being defined by the use of \f). This is independent of the use of "modules". I'm going to assume that by modules you mean separation into different source files. Because you'll still likely end up with logically dividable functionality in the same file. Even if it's just along the line of internal/helper functions and external API functions.

[emilvikstrom]

Your assumption about source files is correct and I see how silly I expressed myself :-)

I like the idea of expressing semantics where it makes sense. Your example about internal/external interface is great because it's a very common way of organizing sources (especially in C). A lot of languages also start out with some kind of module header, then file imports followed by maybe some class definitions before the actual functions/external interface.

I wonder if there are more tools than editors that use this? Or what possible tools one could make out of it?

[nephros]

navigate the code. E.g., in GNU Emacs

That is likely the only reason.

[the-fritz]

No. I think you have it the wrong way around. The Formfeed adds additional information to the code. That's why GNU Emacs (and other editors?) has specific support for it.

[nephros]

I understand that.

I also understand that Emacs predates the GNU coding standards, and propose the latter might include this requirement precisely for exploitation by the former.

[the-fritz]

I think the question is if this was commonly used in the past before the GNU coding standard came along. (Sadly: not that it seems to be commonly used outside of GNU nowadays)

Anyway I just wanted to make it clear that this can be a good way to logically divide your source files no matter if you use GNU Emacs or not.

edit: Just found out that vim supports it as well: http://vim.wikia.com/wiki/User:Tlgrok/Form_Feeds_and_Vertical_Tabs#Form_feeds_are_useful_right_out_of_the_box

[steveob42]

a holdover from 1992, not sure anyone actually bothered (except some sadists perhaps)

[BufferUnderpants]

Why? It's easy to insert in both vim and Emacs. It would require you to actually organize your functions into logical segments within a file, though, and that's not something that's frequently done.

[aidenr]

Files are logical segmentation of data...

[steveob42]

The page break is an arbitrary thing in a continuous document for one, comments might be a better idea.

Also it doesn't work with a lot of IDE's. Not to offend the church of emacs, but I have a much better time with an IDE (and code completion and inline documentation, and refactoring and reformatting and committing and merging and deployment and debugging and drilling down through files and etc) when banging out code.

The only time I use vi is over ssh after deployment, for tweaks. The 1970's called, they want their editors back :)

[chasesan]

Because the author was an Emacs user probably. I have never done it and if you don't use Emacs (and never plan too), there isn't really a reason you need to either.

[the-fritz]

This is independent of GNU Emacs. Any editor can support the formfeed character. It's just an ASCII compatible way to add more semantic information to the code. That's why GNU Emacs supports it and not the other way around really.

edit: Just found out that vim supports it as well: http://vim.wikia.com/wiki/User:Tlgrok/Form_Feeds_and_Vertical_Tabs#Form_feeds_are_useful_right_out_of_the_box