I collected some different code formatting guidelines when people started talking about this on the OpenACS bboard. I have a religion as well, but I decline to state it :)

A good article to read is Tabs versus Spaces: An Eternal Holy War by Jamie Zawinski (who is not at all disinclined to state his religion on the issue).

Jakarta Turbine

http://jakarta.apache.org/turbine/common/code-standards.html

3. 4 space indent. NO tabs. Period. We understand that many developers like to use tabs, but the fact of the matter is that in a distributed development environment where diffs are sent to the mailing lists by both developers and the version control system (which sends commit log messages), the use tabs makes it impossible to preserve legibility.

Jakarta Avalon

http://jakarta.apache.org/avalon/code-standards.html

4 spaces. NO tabs. Period. We understand that a lot of you like to use tabs, but the fact of the matter is that in a distributed development environment, when the cvs commit messages get sent to a mailing list, they are almost impossible to read if you use tabs.

In Emacs-speak, this translates to the following command:

(setq-default tab-width 4 indent-tabs-mode nil)

In vim, having the following in your .vimrc will help:

set tabstop=4
set expandtab
set list
set listchars=tab:>.

OpenVRML

http://sourceforge.net/docman/display_doc.php?docid=7253&group_id=7151
Whitespace and formatting

    * Never use tab characters in source files.

    * Avoid lines longer than 80 characters. What that means is:
      ensure that if you do go over 80 characters, the result will be
      no less readable in an editor that wraps long lines
      automatically than if you had broken the line up manually.

    * The whitespace convention in OpenVRML is heavily influenced by
      the Java convention, which is itself a K&R derivative. The
      preferred form is to use an indentation increment of 4 spaces,
      with braces ?cuddled?.

Mozilla

http://www.mozilla.org/hacking/mozilla-style-guide.html

Naming and Formatting code

OpenBSD

http://www.openbsd.org/cgi-bin/man.cgi?query=style&apropos=0&sektion=9&manpath=OpenBSD+Current&arch=i386&format=html Indentation is an 8 character tab. Second level indents are four spaces.
             while (cnt < 20)
                     z = a + really + long + statement + that + needs +
                         two lines + gets + indented + four + spaces +
                         on + the + second + and + subsequent + lines;

Do not add whitespace at the end of a line, and only use tabs followed by spaces to form the indentation. Do not use more spaces than a tab will produce and do not use spaces in front of tabs.

Closing and opening braces go on the same line as the else. Braces that aren't necessary may be left out, unless they cause a compiler warning.

OpenOffice

http://tools.openoffice.org/coding.html

Source code formatting.

After some discussion we agreed that basic indentation should be four spaces, no tabs. Please use an editor setting which expands a typed tab into spaces. Some examples:

vim: set expandtab

emacs: (setq-default indent-tabs-mode nil)

msdev: check Options->Tabs->Insert Spaces

Linux (from Linus)

http://www.purists.org/linux/

Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a logt easier to see how the indentation works if you have large indentations.

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. 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.

Last modified: Wed Dec 11 15:27:02 EST 2002