Personally, I tend to use a 4 character indend for languages that use braces to delimit blocks, and 5 characters that uses keywords to end blocks. But I've used a 2 character indent for more than a decade as well.

As for <TAB>s, <TAB>s have their place. That's "place", singular, not "places", plural. The place for <TAB>s is called Makefile.

Abigail

As for <TAB>s, <TAB>s have their place. That's "place", singular, not "places", plural. The place for <TAB>s is called Makefile.

And, there's something interesting about that, too! I've met Stu Feldman, the original author of make, and when I asked him about the tab thing, he told me that he never intended for it to be the case. It turns out that by the time he realized his accident, he already had about a dozen people using make, and he made the decision just to keep the tabs because he didn't want to break any existing Makefiles. Now, he's been hearing hell about it ever since. :)

Decades of programming practise hasn't been able to settle this matter.

Hey, RPG programmers solved it years ago! Then they unsolved it by introducing Free Form. I'd like to officially welcome all the old RPG programmers out there to the wonderful world of tabstop flamefests.

(Languages meant for punchcards)--

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Don't know if I count as an RPG programmer; I can neither read nor write it, but have had to do bug fixes in it in the past :(

It seemed to me like a bizarre cross between a fourth generation language and assembler.

From what I have encountered previously, questions regarding "tabs vs. spaces" and "how wide should a tab be" are generally good ways to start a minor flamewar, so my only advice in that department would be pick one and be consistent.

As for converting scripts (either now or later on), you may want to look at perltidy as a way of converting your scripts to a consistent style. IIRC, it has a number of options for controlling tabs, whitespace placement, line length, and many other options, but defaults to a style very close to that described in perlstyle.

I personally use 4 spaces, and never tabs, with an 80column max. I find that, with Perl, my lines can go very long while still being readable and reasonable. In C, I would agree that 8 spaces is good, though I would still probably use 4. *shrugs* TMTOWTDI.

For level of indentation: 8 is popular in C. Java style guidelines mostly follow K&R, but specify a level-4 indent. The reason is that Java identifiers tend to be very long, and that if you are strict about indenting braces, you end up with a lot of levels of indentation before you get to any real code (one level for the class block, one for your method, and another for a try, which any non-trivial code will need). Perl is closer to C than Java, so I usually use 8, but I wouldn't be surprised to see many experianced Perl programmers use 4.

How to deal with people who don't use the same tabstop as you do is a problem. You could set it to output spaces instead of a literal \t, but I don't like having to do 8x or 4x to remove a level of indentation (in vi) when I can use simple x instead. Further, I like the level of indentation to show up exactly the number of spaces I have my editor set to. At the same time, I must remember that otehr people also want it to look right with different tab settings. I must respect their settings if I expect them to respect mine.

This code shouldn't have a problem with anyones' settings:

sub foo 
{
<TAB>my ($bar, $baz) = @_;
<TAB>if($bar) {
<TAB><TAB>return $baz;
<TAB>}
<TAB>return 0;
}
[download]

If I have tabstop set to 8 and someone else has it set to 4, it will look right in both cases. However, this code might not:

sub foo 
{
<TAB>my %hash = (
<TAB><TAB>bar<TAB>=> 1, 
<TAB><TAB>baz<TAB>=> 1, 
<TAB>);
<TAB>return %hash;
}
[download]

The tab embedded in the hash syntax could end up at very different places. In the specifc example above, it probably won't be an issue. It would be an issue where one of the hash keys was particularly longer than the other. Instead of this:

my %hash = (
    foo        => 1, 
    longer_key => 1, 
);
[download]

Someone with a shorter tab stop might see this:

my %hash = (
    foo    => 1, 
    longer_key => 1, 
);
[download]

The solution I've found is to tab at the beginning levels of indentation for the block, but to put spaces in internal indentation. For example:

<TAB>foo<SP><SP><SP><SP><SP><SP><SP><SP>=> 1, 
<TAB>longer_key<SP>=> 1,
[download]

(It doesn't line up above, but it should if you replace each <SP> with a real space).

There are still a few situations where this won't work, but I think it's as close to making everyone happy as we can get. Except for Abigail-II, who isn't happy about anything :)

You could set it to output spaces instead of a literal \t, but I don't like having to do 8x or 4x to remove a level of indentation (in vi) when I can use simple x instead.

Learn your vi. Assuming your cursor is on the code, and not on the indent, using the 'x' method to remove a tab takes you two key strokes: 0x, or ^X. But there's another way, that will work with spaces as well, doesn't require the cursor to be on the indentation, and which is sensitive to movement commands (so you can outdent regions): <<. And to indent: >>.

sub foo 
{
<TAB>my ($bar, $baz) = @_;
<TAB>if($bar) {
<TAB><TAB>return $baz;
<TAB>}
<TAB>return 0;
}
[download]

If I have tabstop set to 8 and someone else has it set to 4, it will look right in both cases.

Sure, in this simple example it will. But suppose you have your tabstop set to 8, write the above code, check it in to source control, and someone with a tabstop set to 4 checks it out, and modifies it as follows:

sub foo 
{
<TAB>my ($bar, $baz) = @_;
<TAB>if($bar) {
<TAB><TAB>if (fuzzle ()) {
<TAB><TAB><TAB># Expression taking 60 characters.
<TAB><TAB>}
<TAB><TAB>return $baz;
<TAB>}
<TAB>return 0;
}
[download]

Looks great, with an 8 character margin on the right to spare, so it fits in the pleasing "72 character" width, and certainly it fits in the default 80 character window.

The code is checked in, and you check it out again. You look at the code in your 80 character window, and the last four characters of the new code will appear wrapped to the next line. Yuck!

If even becomes much yuckier if the coding guideline says "4 character indent", and some people use an 8 character tab-stop, and some use a 4 character tab-stop. Say the current block has <TAB> as indentation and two if/else statements are added, by different programmers. One will use <TAB><TAB> as indentation - the other <TAB><SP><SP><SP><SP>. Fun! Fun! Fun!

Abigail

Assuming your cursor is on the code, and not on the indent, using the 'x' method to remove a tab takes you two key strokes: 0x, or ^X.

Hrm? A simple x has always worked for me, but then I also use vim with its nearly-modeless settings whenever I can get away with it. (I probably should have specified this above). Admittedly, removing any sizeable block of indentation can be done faster with a search-and-replace on those lines anyway.

Sure, in this simple example it will.

And that's exactly what I was trying to show: a simple example where any sane value of tab settings will work. There are probably more cases where they won't work than everyone on this site could list.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

As far as indentation goes, I tend to use 4, but again use what will be consistent for the way you write code. For example, I've seen some people write code with multiple levels of indentation, but then stick with 8-character indentation and allow their lines to go past 80 columns -- absolutely hideous for someone to read.

bluto

The coding standards for the Krang project include our indentation standard only with Emacs and Vim code to implement it:

http://krang.sourceforge.net/docs/coding.html

-sam

In my entire life, no matter how much people may disagree on how many spaces to use for each indent level, I have never heard anyone offer a compelling reason to use TABs to indent source code.

With spaces, regardless of who looks at the code (or what application they look at it in) it will allways look the same way (barring some hair brained fool looking at source code in a proportional width font)

With TABs, you have no idea what the code will look like when other people read it. The width of a TAB is inherently left up to interpretation.

In theory, one could use tabs to indicate indentation of the block and use spaces to indicate a line continuation or to make things vertically aesthetic:

sub foo {
<tab>while (<FOO>) {
<tab><tab>chop;
<tab><tab>   /^ \s* (\w+) \s* = \s* " (.*) " $/x
<tab><tab>or /^ \s* (\w+) \s* = \s*   (.*)   $/x
<tab><tab>or die "Malformed line $. in FOO";
<tab>}
}
[download]

It is unambiguous from the tabs that the first // is at the same block level as its surrounding lines. Unambigous, at least, to a machine or to somebody with visible tabs and/or spaces.

That said, I don't do this, and I've never seen anybody that did. (But I use pico and I don't have many friends. (Draw your own conclusions there.)) And if not everybody follows the convention, then you can't rely on the system.

FWIW, I have had to work with code indented twice around the screen before the inking characters, and had I been using an editor that would shorten tabs, I'd have still ended up with one in ten lines having 160 leading spaces. While K&R and Linus probably overgeneralized with the three-indent rule, I've yet to see any code whose biggest flaw was the characters it used for spacing.

While indent and perltidy are marvelous tools, we also need "unindent" and "perluntidy". Each would take (1) the original source before you got stuck with it, (2) the tidied source, and (3) the tidied source plus your fixes, and spit out (4) the fixed source in the style of the original.

In my entire life, no matter how much people may disagree on how many spaces to use for each indent level, I have never heard anyone offer a compelling reason to use TABs to indent source code.

Smaller size? For example:

$ unexpand < bbbike | wc -c
 488645
$ expand < bbbike | wc -c
 605458

When you can buy a 500 GB hard drive, size is not a good reason to use tabs.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Why 3? Well, FORTRAN (my mother tongue) has only columns 7->72 to work with. With only 66 columns to work with, 4 spaces consumed to much too soon, and 2 spaces was harder to read, especially on print-outs (no colour coding in the good 'ole days, no full-screen editor, ... cards...) Also, continuations aren't always easy to read.

What I truly want to know, do people ident their comments? I've seen both in C and in Perl.

I use spaces as the only character for indentation; personally i cannot handle changes in tab width of a foreign editor. I use 2-space indentation; 4 is too much (as in first character being too far away to move the cursor to from the previous line). I tried 3-spaces once or twice; i (think i) prefer even number of spaces.

I sure do indent my comments, same as rest of the code. Unindented comments, for indented part of the code, indicate some sort of specialness to me: a bug, pay extra attention, most important thing, and such.

To OP, as it has been repeated, be consistent in your own code; try to conform for the good of the project while working w/ others. (I personally would try at least once to push for using only the spaces, not tabs, for indentation; difference in indentation level & position of braces are much easier to tolerate.)

- Parv

I use 2-space indentation; 4 is too much (as in first character being too far away to move the cursor to from the previous line).

Then get your editor to do it. The majority of the indents happen after a line whose last character is a '{' or a ':', and almost always if such a character is the last character of the previous line, you want an extra level of indentation. In my vi-clone, if 'perl' or 'C' mode is turned on, ending a line with a '{' or a ':' causes an extra level of indentation to happen. Starting a new line with ^D removes a level of indentation. Hitting <TAB> inserts the right amount of spaces to get to the next tab stop. '>>' adds an extra level of indentation to the current line, '<<' removes it. I rarely have to type 4 spaces to do indentation.

Abigail

If long, I place my comments on the line above the code it
describes && indent to the same level as the code itself.

If short, it goes after the code on that line.

3 space is just the right about of readable to me, I really can't explain it. I guess I don't like to see a lot of whitesapce, and 2 is not enough for me to read indent levels quickly.

Also, when I feel like it, I intent places that typically are not intended, such as parameter lists like in Tk or OO functions:

Whatever::Foo->new( 
   -bar => 'xyz',
   -baz => 'def',
);
[download]

Let's not start the flamewar as to where curly braces go, but I like them on the same line as the if, since (at least to me) scrolling cuts into readability. At least Perl enforces blocks on if statements!

I use a two-space indent, but four also seems reasonable; I find that eight is overkill. You should standardize this within your team or project, or if you're contributing to someone else's code, use their value.

Conversion of tabs to spaces or vice-versa is optional. I'd let this vary, even from file to file or within a file, since people use different editors and typing styles, and the indents can be easily converted back and forth automatically as long as you stick with the standard tabstop.

(I use Apple's "TextEdit" editor, which lets you set the number of spaces to be used for the line/block indent commands, and which automatically converts leading runs of spaces to tabs.)

(I use Apple's "TextEdit" editor, which lets you set the number of spaces to be used for the line/block indent commands, and which automatically converts leading runs of spaces to tabs.)

Hack much Python recently? *g*

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

That's one reason I haven't been real excited about picking up Python.
I'm not sure my eyes are good enough to catch when my indent isn't right.

Personally, I use 3 spaces for block indentation. The majority of Perl code I've seen has used either 4 spaces or some aweful combination of varying indentation. I just prefer 3 spaces because it shows the level of indentation just as well as 4 spaces, but requires that one less keystroke per indentation. I honestly don't see how people can stand using 8 spaces (not to be confused with an 8 space tabstop). I could not see myself banging in an additional 8 spacebar presses every time I enter a new block, as by the time you're in a 4th level block, you're punching in 32 spaces for each line of code and taking up 40% of the screen width (assuming 80 character width terminal) just for the whitespace. I have to wonder if there aren't code samples out there that use 8-space indentation that contain more whitespace characters than non-whitespace ones. Talk about a waste of bandwidth and storage space.

As for using tabs rather than spaces, I despise that all to hell. Tabs are even worse than 8 space indentation because of cross-editor type behaviour. Ugh! Who invented the damn tab key anyhow? It should be deprecated, except for tabbing between window elements :)

I honestly don't see how people can stand using 8 spaces (not to be confused with an 8 space tabstop).

Many people who put in 8 spaces (not a literal \t) have their editor do it for them. Either the editor autoindents, or they press the tab key and 8 spaces are put in.

As for using tabs rather than spaces, I despise that all to hell.

The orginal reason for a \t is that memory used to be much smaller, so using one character instead of four or eight made a big difference. With 500 GB hard drives, this is no longer an issue.

The modern reason for using a literal \t is that when it's done right, you can get it to look right with most reasonable editor/terminal settings. See one of my other posts in this thread for tricks to do this.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

I   never   understood,

why   people   take   so   much   fun   in

filling   up   their   screens   with

whitepace.



Is   it   because   they   are   ashame   of

their   code?



Or   can   there   be   any   other   reason?



At   first   I   guessed   it   was   because

of   the   big   screens   that   give   you

160   lines   and   columns,   but   then   I

noticed   that   people   also   cared   about

these   old   72   column   devices

                (

                I   think   I   saw

                one   of   theese

                in   the   museum   once

                ),

so   this   cannot   be   the   reason,   too.



I'm   puzzled.

OK, i'll give you one example. Sometimes I include code in LaTeX documents, using the \verbatim macro, kinda like the <pre> HTML tag, where lines are not automatically wrapped. So if I want a document, where the lines fit, I need less that 80 character lines. Sometimes I open source code in terminal windows. Yes, terminal windows can be resized, but no, I don't like doing that.