A couple questions:

1. Do you use hard tabs or soft spaces for indentation - and why?
2. How many spaces do you indent in? 4, 8 or (gasp!) 2?

Personally, I use soft spaces with an indent of 4 for every programming language. Trying to use 8 space indentation is just too hard when I try to keep my lines less than 80 characters.

I prefer the uniformity you get with the tab key (so in other words 4 in MVS6).

I use soft indentation and 4 spaces because I'm a big python programmer and that is the python standard. But that's just me.

I typically use hard tabs. But if I ever use soft spacing (such as when formatting code for a forum), I use 3 spaces.

I use whatever the source code formatter does in code::blocks. I think it's the K & R standard.
Previously before I had the formatter I used spaces, often only 2 because sometimes lines got too long when I used descriptive variable names.

I use tabs to indent, and spaces to align.

My IDE usually have the tab/indentation level set to 3, since it's not as space-wasting as 4, and easier to read than 2.

Although people who use tabs to indent also use tabs to align, I think it's a pain to visually match everything in their sources by either changing my IDE's tab/indentation level to match theirs or (in the extreme case) reformat their code to make everything align correctly.

--|--|std::cout << "Text that is so long that it needs to break across lines "
--|--|          << "have the tabs set the same as the line above, and then hit "
--|--|          << "SPACE until the <<'s are aligned visually.";

Now, whether I choose to have my tabs/indentation set at 3,4,8, or some other value, everything shifts by the same proportions and no reindentation is needed.

I use tabs. Mainly so that if I edit the file in an editor that doesn't use Shift+Tab to deindent (or doesn't auto indent) I have less keys to type.

Iusetabsbecausemykeyboarddoesn'thaveaspacebar.

I use the tab key to put in spaces up to the next tab stop using Code Blocks. 3 space indentation is just about perfect. Not too much extra space on the left with large indentation levels, and enough space to see at a quick glance which blocks are where.

I can't stand actual tabs though, because Code Blocks insists on displaying them as arrows, which makes any code with actual tabs in it look awful, at which point I immediately replace them with spaces. I may put in a request on the Code Blocks forums to have them allow invisible tabs as an option one of these days.

What bugs me the most is when people use an 8 space tab with a different indentation level, so there's one tab and a space to meet up with the 3rd 3 space indentation.

Huh? Why don't you set the Settings->Editor->General Settings->Indent Options->Show Spaces to 'No'?

Yikes! That made my code all floaty! I like having the dots indicate the spaces, but not the arrows indicating tabs. And besides, I didn't think that turning 'Show Spaces' off would turn off the tab characters as well. I learned something new. Thanks.

Soft tabs (in other words, tab inserts spaces), with a tabsize of 3.

Yeah, I guess they could have picked something less visually striking than an arrow... heh.

As for the OP: I use tabs (tab size 4), because I like them. Also, makes keyboard navigation easier for me. I've yet to see an editor that will respect indentation when moving using the arrow keys unless you use tabs.

I use four spaces, no tabs. I can't stand tabs.

I use four soft spaces. This is either done by CB when I press tab or when I do it myself. I'm not sure which one I use more because I haven't been paying attention.

I use whatever the environment I'm in defaults to, because I'm too lazy to go in a change a setting that looks and works fine by default. I've used Dev-Cpp for years and I'm still not sure what the default setting is.

If I had to pick a setting I'd go with four spaces.

In Code::Blocks I used to use 4 spaces with a tab, and save them as a tab character, but I reinstalled at some point and forgot to change the setting. So I use 4 spaces, but use two for case labels and public/private/protected in classes.

Eg.

I prefer tabs. But if I have to use spaces, 2 is enough.

I use tabs to indent, but spaces to align (i.e., multiline statements that don't line up with tabs). My tab size is always 4. I find tabs more easy to work with, but spaces are needed to align continued lines where tabs don't necessarily line up perfectly. I find 4 spaces to be the most comfortable size.

Always tabs. Spaces are evil. Tab size 2 or 3 is enough.

2 spaces. Any more and the nesting starts to slide off the side of the screen.

I use the '>' symbol as to know that I'm moving my characters to the right. Unfortunately, I had to build my own compiler to accomplish this.

Four spaces using hard tabs seems to be a common default for C-based languages. Why fight it?

Because if you use hard tabs you can fight it without anyone else noticing

I really couldn't care less, I take whatever the default is for TAB, it's only spacing.

I prefer 2 spaces. Soft indentation at all costs, doesn't matter if the number of spaces should be higher, but tabs are evil. Because tab character is represented by various number of spaces across the editors. So I set tab in IDE to insert 2 or 4 spaces instead.

And I know what I'm talking about, I opened .cs file generated in MSVC by two people in kwrite and what I got was a mess. Code wasn't aligned, because indentation was all messed up - sometimes spaces, sometimes tabs.

http://www.allegro.cc/forums/thread/596280

Tab characters are always ambiguous, some software show them as N hard spaces, some align on columns multiple of N.
I'm working on large existing code (1.5Mb of C) with a few other coders, and as long as nobody puts a tab character we're all fine.
When a tab does appear, it's easy to find and fix.
Googlecode doesn't handle tab characters, the code loses all indentation when viewed in the site.

Why don't I believe this? Oh, because it's completely untrue

Well, on Firefox 2 the tabs disappear entirely. I don't blame the software or site, I just try to do my best with what I have (which is windows 98).
Glad to know it works on whichever browser you're using.

Firefox 3, and tabs displayed fine in Firefox 2

In fact, they work in all versions of Firefox.

Working by myself, whatever the default tab is.
Working with anyone else, whatever the group decides.

Interesting reading for anyone interested in the coding style used in the linux kernel.

http://www.linuxfromscratch.org/alfs/view/hacker/part2/hacker/coding-style.html

My favorite quote from it:

That's stupid. In many modern languages, there is a namespace, a class and then methods... That's 3 levels of indentation right there. No control structures for you!
Tabsize 8 is just HUGE, and does not (imo) make it any more readable.

@Jonatan Hedborg: I'm pretty sure those are C specific style preferences.

I'm not so sure.

He seems pretty religious about it

To enforce a coding style you can convince people, or you can terrorize them into it

OT: CGamesPlay, I was doubly mistaken about googlecode, the rendering is flawless on all FF versions, it's on ie6 (at work, I must have used it by accident) that it fails. Not on the page you tested (text/plainm no HTML), but on http://code.google.com/p/linkage/source/browse/trunk/src/EditColumnsDialog.cc which converts TAB characters from source into 8 spaces of <pre> HTML, and in http://code.google.com/p/linkage/source/detail?spec=svn545&r=512 which preserves TABs and spaces. In both pages, all indenting is lost, no matter if it's done in spaces or tabs.

While it's true that the display of tabs depends on the viewer, tabs should not be used on a line after any non-tab characters. So they should be used strictly for leading indents. When that rule is followed, the readability of code shouldn't be affected by the number of spaces that the tab character represents for the person viewing it.

Well, there's something religious in the belief that there would be an optimal coding style, whether we're speaking about indents, is-a/has-a, global/local variables, mixing C with C++ or whatnot.

I hate tabs, they are awful, especially when people combine them with spaces (for example, if tab is set at 8 and they are indenting with 4, and need to do 12, they press a tab and four spaces!).

So, I press the space bar four times and done.

What kind of idiot would do that? One tab = one level of indentation. If they have 8 that would be at 8, 16 and 24. Why would they need to do 12?

We've already been over this... The optimal solution is to use tabs for indentation and spaces for alignment.

teh_codez
{
[tab]teh_codez
[tab]{
[tab][tab]teh_codez
[tab][tab]teh_codez moar_codez moar_codez
[tab][tab]                     moar_codez
         ^ identation         ^ alignment
[tab][tab]teh_codez
[tab]}
[tab]teh_codez
}

No matter what editor you view that code in, it should always appear cleanly indented. You can also indent with a single key press and remove indentation (even in simple editors) with a single key press.

Many. Especially if they want 4 spaces as tab, but they never configure tab to move 4 instead of 8, so they just do it manually mixing spaces and tabs.

3 spaces.

Softabs of 4 spaces in vim. Alignment comes out same in all editors. Vim's backspace doesn't break either.

Softabs of 42 spaces in vim. Alignment comes out same in all editors. Vim's backspace doesn't break either.

Indentation is for sissies. Real Programmers(TM) don't use line breaks, either. After all, unnecessary whitespace is wasteful.

That linux coding style is awful. And the doc is obviously written by an opinionated douchebag too.

It was written by Linus?

I like to indent the outtards instead of the innards. Since indented things stand out more the important stuff (like function names) get the most attention.

        void output(ostream &out)
        {
      for(int i = 0; i < 24; i++)
    if(i%24)
  for(int j = 0; j < i; j++)
out << i * j << endl;
        }

It also just looks prettier.

I prefer:

                 void output(ostream &out)
                                         {
           for(int i = 0; i < 24; i++)
                          if(i%24)
    for(int j = 0; j < i; j++)
     out << i * j << endl;
                                         }

I prefer:

                                         }
     ;ldne << j * i << tuo
    )++j ;i < j ;0 = j tni(rof
                          )42%i(fi
           )++i ;42 < i ;0 = i tni(rof
                                         {
                      )tuo& maertso(tuptuo

The compiler hates me.

public
static
void
main(String
args[]){
System.out.println("Hello
World");
}

My style of choice is a bit unorthodox.

int _main_loop_ = _tick<_while<_not<keys<KEY_ESC> >,_compound<_while<_gt<timer, _const<0> >,_compound< dec_timer,_compound<_compound<_compound<_if<_and<keys<p1_up>, _gt<_get<p1>, _get<top> > >, _addeq<p1, _neg<_const<1> > >, _if<_and<keys<p1_dn>, _lt<_add<_get<p1>, _const<paddle_h> >, _get<bottom> > >, _addeq<p1, _const<1> >, _nil> >, _if<_and<keys<p2_up>, _gt<_get<p2>, _get<top> > >, _addeq<p2, _neg<_const<1> > >, _if<_and<keys<p2_dn>, _lt<_add<_get<p2>, _const<paddle_h> >, _get<bottom> > >, _addeq<p2, _const<1> >, _nil> > >, _compound<_compound< _addeq<bx, _get<bxv> >, _addeq<by, _get<byv> > >, _if<_lt<_get<by>, _get<top> >, _compound<_set<by, _get<top> >, _set<byv, _const<1> > >, _if<_gt<_get<by>, _get<bottom> >, _compound<_set<by, _add<_get<bottom>, _const<-1> > >, _set<byv, _const<-1> > >, _nil> > > >, _compound<_if<_and<_lt<_get<bx>, _add<_add<_get<left>, _const<paddle_w> >, _const<ball_r> > >, _and<_not<_lt<_get<by>, _get<p1> > >, _not<_gt<_get<by>, _add<_get<p1>, _const<paddle_h> > > > > >, _set<bxv, _const<1> >, _if<_and<_gt<_get<bx>, _add<_add<_get<right>, _const<-paddle_w> >, _const<-ball_r> > >, _and<_not<_lt<_get<by>, _get<p2> > >, _not<_gt<_get<by>, _add<_get<p2>, _const<paddle_h> > > > > >, _set<bxv, _const<-1> >, _nil> >, _if<_lt<_get<bx>, _get<left> >, _compound<_compound<_set<bx, _const<paddle_w> >, _set<by, _add<_get<p1>, _const<paddle_h / 2> > > >, _compound<_set<bxv, _const<1> >, _addeq<s2, _const<1> > > >, _if<_gt<_get<bx>, _get<right> >, _compound<_compound<_set<bx, _add<_get<right>, _const<-paddle_w> > >, _set<by, _add<_get<p2>, _const<paddle_h / 2> > > >, _compound<_set<bxv, _const<-1> >, _addeq<s1, _const<1> > > >, _nil > > > > > >, _compound<_compound<draw<score<_get<s1>, _get<s2> > >, draw<ball<_get<bx>, _get<by> > > >, _compound<_compound<draw<paddle<_get<left>, _get<p1> > >, draw<paddle<_add<_get<right>, _neg<_const<paddle_w> > >, _get<p2> > > >, draw<flip> > > > > >(); // This line is 1984 characters long at this dot.

How did I know that was coming!

Yeah

Maybe because it was here before and this is a.cc?

Comments go before the code it describes, not on the same line.
There, no problems with aligning. Aligning always breaks every time you edit the code anyway so if anything is evil, it's comments behind code.

Oh, since this thread is still around, I want to highlight the experience I had with Dev-Cpp the other day. I needed to use that because it was the best available source code editor on a particular system.

In other words, Dev-Cpp indents with 8-width tabs plus spaces a number of times equal to the index of the first space character in the previous line plus one If you try to remove the idiotic scheme it's got, you can backspace to where you need to be and then hit tab to automatically reapply the idiotic indentation scheme

Yeah it sucks but there's a setting for it. The one thing Dev-Cpp is really missing is highlighting multiple lines and hitting tab or shift-tab.

X-Code does that too. I lose a whole block of code, and have to hit undo, and the whole time I'm thinking to myself "why would I ever want to replace a whole block of code with a tab?"

I use 4 spaces (not tab, spaces; is that "hard" or "soft" spaces?). When I'm posting code on a.cc I use just 2 spaces. I prefer to use spaces rather than tabs because they are more predictable. A space is always just a space on any computer in any (sane) editor, but tabs vary in size. (Disclaimer: I'm not trying to say that spaces are better than tabs or anything like that. I know there are many good reasons for using tabs. I'm just giving the main reason for my preference.)

A tab is always a tab: exactly how big I want it to be, regardless of whose code I'm reading.

Wow. I'd never thought of that before. I'm completely converted!

If your editor supports resizing tabs, and if you don't mind having to change your tab size setting every time you want to read someone else's code, invariably due to 'tab + space' indentation.

The only place that happens is in legacy Allegro source code, which was 3 space indentation with 8-space tabs used when possible. Seriously wtf.

Anyways, what you're saying is a lie. Anybody whose code I've read is tab indentation with space alignment and it works properly, every time.

Which wouldn't be a problem if everyone used tabs to indent, and spaces to align...

Some a.cc programmers here set their tabs to be equivalent to a single space, others to 8. As long as comments are indented with tabs to the same level as the lines before/after, and then spaces to align everything, there'd be no difference in different IDEs rendering the code (except for how far horizontally you have to scroll to see too-long lines).

Of course, with monitors being wider than they are tall in most setups, word wrap set to 80 characters is outdated for most except terminal connections.

Assuming the person used tab for indentation only, and no alignment what so ever. (That is, there's no place that is 8 (or whatever the editor is set to) spaces long that got replaced with a tab by the editor.

I said 'tab + space' indentation, not alignment. There was no lie, you're incorrect.

Which is a decent percentage of the current A4 code.

Ctrl-R for the win.

AStyle for the win, since it also fixed the incorrect bracket styles as well as doing proper indentation.

The Allegro problem is because of the three space rule. Most Windows IDEs automatically impose a tab indentation style because that's what the advanced world uses. I've still never yet seen a useful argument why somebody would want to press a key three or four or eight times when you can just press tab once. Why impose your tab size on other people?

Working on the Allegro codebase with space indentation makes me angry inside.

And the terrible mix of tabs and spaces I accidentally commit makes the space-aholics angry inside.

The other thing that makes me angry inside is opening curly braces at the end of the line. I'll never get used to doing that when working on Allegro code. And that makes the unaligned-curly-aholics angry inside.

Ah, but pressing tab once in Code Blocks lets you put a set number of spaces down in it's place if you wish it to. Which is infinitely preferable to seeing all those flipping tab arrows. Yes, you can turn off the tab arrow display as SiegeLord pointed out to me, but then you don't get to see the dotted space indicators.

Get the Code Blocks guys to implement the option to display tabs as a set of dotted spaces, and I'll quit being annoyed at all the !@#$%@# tabs.

Whitespace should be invisible.

There should be a language where whitespace is replaced by punctuation. Tabs are actually #s and spaces are actually .s.

#if.(.whitespace_is_bad.).{
##return.waffle;
#}.else.{
##return.crouton;
#}
#//This.is.a.comment.where.anything,.including     spaces     is.allowed!
#//And,.this.is.properly.indented.and.aligned!

Notepad++ lets you view all characters. It's kind of fun to see whitespace. At the same time, I think it could get in the way during real work... I usually have that feature disabled.

That's not what we're talking about. As Edgar pointed out, one doesn't have to press a key three of four or eight times to get that number of spaces. Edgar uses codeblocks, and that does it for him. I use gVim. With my gVim settings, pressing tab makes 4 spaces. It has auto-indentation, and ... well lets just say that it works in exactly the way that tabs would usually work except that the spacing is done using the space character rather than the tab character.

One reason to "impose your tab size on other people" is that sometimes I line up chunks of code that don't match the tab spacing. For example I might do something like this:

create_level("level 1 - warm up",   easy_ai,      unlimited_resources);
create_level("level 2 - challenge", medium_ai,    basic_resources);
create_level("level 3 - death",     difficult_ai, no_resources);

... Maybe that's not a good example, because you could still have tabs at the start and use the spaces inside the functions -- but the point is that sometimes the readability of code is damaged by changing the tab size. To be honest though, I don't really care much if other people are unhappy with the tab size in my code. If it is a shared project then we should agree on that kind of stuff before hand, but in my own code it doesn't matter. So I do what I do for my own convenience.

AHHH. You press TAB when you want to indent. You press space when you are lining things up. Anything else is insane. It never affects code readability.

Right. Because you've configured it to do something bizarre. (I could configure my keyboard to press ZZZZ when I press $.) Instead, you could configure it to show a single tab AS 4 spaces. Then everybody wins.

Like I said, Matthew, I have chosen my setting for my own convenience. Do you think that I haven't tried using tabs before? I prefer spaces. I've had a shot at trying to explain why. About all I can say now is this: if you don't like it, too bad.

It's okay. You use vim... tabs are the least of my concerns for you.

Meaning I would have to set up the tab key to produce tabs at the start of a line but spaces (for alignment) in the middle of a line. That's doable, I've seen configuration options that do that. Still - it wouldn't be clever enough to insert spaces when I'm aligning a continued line, so it's not good enough.

Anyway, another reason I generally prefer spaces to tabs, personally: FORTRAN doesn't allow tabs to indent.
Sorry, let me rephrase that: some FORTRAN compilers do not allow you to use tabs to appear at the beginning of a line. Others do, but that doesn't help.

That said, anyone getting overly upset about something like this needs a hobby.

I can see Matthew foaming at the mouth from here.

You'd use the space bar to put spaces in the middle of the line...

I don't get it. If you wanted to align this code:

012345678901234567890123456789

struct foo {
         | press tab 6 times |
         v                v
   int x;                  // lala
   int meaning_of_life;    // lala
                       ^  ^ 
                      | press tab 2 times, then backspace 2 times
                      | or press tab 1 time and space 1 time
}

Do you ever press spacebar? Or do you use tab between words too?

Ah, see, now, I don't - I align comments at the end of a line by pressing tab (which inserts spaces). Fewer keystrokes and more convenient to hit rapidly in succession.

What sort of broken editor would you use that you'd need to do that? I have tab stops set every three characters, hitting tab brings me to the next tab stop (inserting spaces).
Unless you don't line up comments on tab stops. But that would just be weird.

That's different from claiming that hitting tab inserts three spaces, which is what the other tab users on this thread have been saying.

And no, I don't see any point to lining up on "tab stops." If I want to align my comments (or whatever), they'll be uniform relative to the length of the longest line in the area.

It would be handy to have a key combination to enter spaces instead of a tab for the times when you are aligning with spaces (you could get within the tabsize of the alignment tabsize times faster and then adjust as appropriate). I wonder what editors support such a thing...

In my code they're on the next tabstop after the longest line needing a comment in the same logical block - which is typically one or two spaces after the end of the line anyway.

I've seen configuration settings that do that (or similar) for vim. Also configurations for making the tab key insert tabs at the start of a line, spaces in the middle of a line (if there are non-white space characters to the left) and cleverly act as a completion key (as in the shell) while you're typing a word.

The tab stop thing is what I had in mind when I said this: "It has auto-indentation, and ... well lets just say that it works in exactly the way that tabs would usually work except that the spacing is done using the space character rather than the tab character." I just didn't want to describe the details of what it does only to have someone in the next post say "tabs do that too. That's what tabs are for!"

The answer, obviously, is 42.

ps: tabs, size 4.

Tabs don't break Python?

By the way, you need to fix your tabs if you want to write in Whitespace.

Of course not. A soft tab width of 1 (i.e. 1 space) won't break python either, as long as you are consistent. You can even mix tabs and spaces, as long as you are consistent: if the first line of a block is indented with a string of whitespace characters (tabs, spaces, or both), all lines in that block must be indented similarly.

Does anyone else keep there line length below 80 chars like me?

The max line length on my current project is 134 characters. Developing on a wide screen is nice.

I try to. On (rare) occasions it's difficult or unsightly to, though, so I let it spill over sometimes.

I normally use tabs, with tabs set to display at 3 spaces. I find 4 is too large, and 8 is insane. But for some projects, like allegro, I try to set tab to insert spaces instead of tabs.

Still do, mostly because, from time to time, I use console/DOS. It also helps to keep the code tidy: if you got an if that has 5 or 6 expressions, there is something wrong.

My .vimrc:

colorscheme darkblue
set ts=4
set history=100
set et
set noautoindent
set nocindent
set path=/usr/include,/usr/local/include,../include,.,/usr/include/c++/4.2.1
syntax on

tabstop at 4, expand tabs into spaces (I hate the tab character), and remove both autoindentations, I like having full control.

I follow as a guideline to keep my code under 80 characters, but break that often because some code is really just too long to break neatly. I'd rather have a very long, but easily understandable, line of code than something broken at funny places just to get things within parentheses within those constraints.

But I have a lot of wide monitors also, and find that on some projects where I like to use descriptive variable (and function) names, as long as it doesn't make me scroll horizontally, it's not too long.

Normally, yes. For the same reason the standard TeX line is relatively narrow: it's easier to read if lines are not too long.
Although FORTRAN is so annoying with continuing lines that are to long that I sometimes ignore it. To continue on the next line in FORTRAN you have two options, depending on whether your dialect is F77 or F90. In F77, break the line and then insert a character in column 6 of the next line to indicate that line continues from the previous one. In F90 mode, insert an & at the end of the line you wish to break - of course these conventions are incompatible.
Naturally, I have to tell my compiler that I'm using lines that are longer than 75 characters, or it will truncate the line at that point and most likely produce an error.

My current, WIP, .vimrc (littered with commented lines; " is a comment character, IIRC):

:set number
:set ruler
:set tabstop=4

"set term=ansi
"set term=color_xterm
syntax on

":hi Normal
:hi comment cterm=none ctermfg=darkgreen

:hi constant cterm=none ctermfg=black
:hi identifier cterm=none ctermfg=black
:hi operator cterm=bold ctermfg=black
:hi string cterm=none ctermfg=black

:hi matchparen cterm=none ctermfg=white

:hi boolean cterm=none ctermfg=darkblue
:hi statement cterm=none ctermfg=darkblue
:hi type cterm=none ctermfg=darkblue

:hi preproc cterm=none ctermfg=darkcyan

:hi character cterm=bold ctermfg=darkgray
:hi special cterm=none ctermfg=darkgray

":hi underlined
":hi error cterm=none ctermfg=red

I configured the syntax highlighting to be more like the Visual Studio defaults I started with (i.e., keywords are blue, close to 0x0000FF, comments are dark green, numbers and strings are black, etc.). I just prefer it that way... There's probably a more correct place to put the highlighting, but oh well...

I try to as well. I often work from a Linux terminal and also just find that as a rule 80 chars is a good cut off point.

I use tab's, simply because they're faster than pressing the space bar. But I've been forced to use the space more and more recently, because codeblocks didn't want to link up to allegro properly, so I had to use Dev-Cpp which seems to do wierd things when it comes to spacing.

When I'm doing DirectX though, I use MSV, which seems to be a lot more friendly about layout . (So tabs there).

That's a rather silly reason; most people using spaces will press the tab key too, but just have it configured to insert spaces rather than tabs.
That's actually maybe the main the reason I use spaces rather than tabs: it's faster to align code by pressing tab than by pressing the space bar repeatedly. On the other hand, "ni <esc>" might be even faster.

In the end, there is always indent to indent if necessary.

CodeBlocks links to Allegro just fine for me - start a new thread and I'll help you with it if you like.

I was disappointed to learn that GNU indent is apparently C only. I guess there are a few C++ formatters, but none seem to stand out. I had hoped to use it to automatically format code between some project agreed standard and my preferences, but would need support for C++ (and something that supported other languages, like C# would also be great).

SiegeLord mentioned using AStyle for formatting the other day - looks like it supports the uses you just mentioned.

I think Visual Studio does C++. If it does it as well as it does C#, you should be good.

Yeah, I had found that when I did a search. I was still in disappointment mode though from learning the GNU solution wouldn't satisfy my needs and haven't really given anything else a chance yet. Have you tried it yet?

There are a few things Visual Studio doesn't budge on, like for example my (possibly odd) habit of putting the colon for inheritance against the class/struct name, and then listing the various base classes (and, in C#, interfaces) that it inherits, each on it's own line, indented one level.

class MyClass:
    public YourClass,
    public HisClass
{
};

I can't get Visual Studio to do that automatically. It will either list them on the same line as the class name, or will drop the colon onto it's own line indented one level as well.

I also got into the habit of using return syntactically like a function, in that I always follow it with parenthesis:
return(0);
Visual Studio insists on putting a space between the return and (0);, which I find annoying. Perhaps I should just get in the habit of not using parenthesis for statements like that. It would be nice though if whatever was formatting the code would allow specific rules, like if there is no outer parenthesis around the return value, put a space, but if there is, don't.

Also, though, I'm mostly interested in a UNIX solution because I don't like to develop in Visual Studio (I don't want to become dependent on a Windows-specific). And also, I expect UNIX probably has a more powerful and flexible solution. For example, something that could be scripted and automated.

Speaking of which, does anybody know if it's possible to tie something like a source formatter in with subversion? Preferably on the server-side so the repository's configuration was consistent, but also on the client-side so each client could configure the format for their own preferences.

For the server-side, I had the impression that hook scripts were able to affect the committed code in some way, but when I looked them up yesterday to confirm I was disappointed to see no suggestion and no data being passed that stood out as providing that kind of detail. I think there is a pre-commit or something that does get a transaction identifier, so in theory maybe it would be possible to affect the code at that time? It doesn't sound overly likely though.

** EDIT **

I took the time today to install AStyle and write up a configuration file for myself. I really like the configuration files that are full of comments and walk you through the configuration inline, so I basically created a template out of the online CLI options documentation. I figured it might be useful for some other people (even if you don't like my [untested] configuration, it should serve as a useful template to work with).

.astylerc

I tried to avoid the options that have disclaimers attached to them. I figured changing the suffix to something like .pre-astyle would be less likely to collide with a previously backed up version. Since AStyle doesn't seem to document what it would do in such a circumstance, I'm assuming that it must assume it created the .orig files and would subsequently overwrite them without thinking.

Note that while the command line arguments are supposed to override the configuration file, it doesn't look like all options have an off switch and I didn't see any syntax to undo an option from the command line, so I expect there are some options that the configuration file will insist upon. This is something that I believe should be fixed.

This should summarize the options I'm going with initially:

[bamccaig@rufus ~]$ cat ~/.astylerc | grep '^[^#]'
indent=tab
brackets=break
indent-namespaces
unpad=paren
suffix=.pre-astyle
preserve-date

** EDIT **

So far I am not impressed. Not only did it [seemingly] modify the in-place file, but it also seems to have made changes to the "backup" file. Not only that, but instead of removing padding from parenthesis, it's ADDING it! Fortunately, fixing the padding was apparently fixed with sed:

[bamccaig@rufus iq]$ sed -r 's/\( /\(/g' app.cpp | sed -r 's/ \(/\(/' > app.cpp 2>&1

As evidenced by meld¹. I could be wrong about this (I certainly hope the mistake was mine)... I'm going to do some more testing (on backup files!) to see what the real result of AStyle is.

Unfortunately, I also forgot to put in the indent=tab option the first time so now my source file has spaces. I think I'll try to fix that with sed too (which I've been meaning to become more competent with anyway) until I have more faith in astyle...

** EDIT **

Confirmed that AStyle is padding parenthesis... >:( Then WTF is unpad=paren for?!

¹ I'm happy to find a nice and simple diff viewer. vimdiff is probably super powerful for experienced vim users, but right now I just find it difficult to use. I wonder if meld is cross-platform. sdiff also seems like a nice diff viewer, but it doesn't seem to support coloring and the like to make differences stand out (just a vertical bar by the looks of it)... Still should be a good complement to diff though.