All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

I understand your frustration. However, I'll suggest that you use 8-space indentation with *spaces* not *tabs*. That way, regardless of my editor settings for tab width, I'll see that your style is 8-space indentation and (as a good contributor) can follow that easily. Whereas if my tab-width is set to 4 or 2, then I'll never know that you want 8 spaces and you're more likely to get something inconsistent back (particularly if I'm trying to line things up across multiple lines at something that *isn't* a

I understand your frustration. However, I'll suggest that you use 8-space indentation with *spaces* not *tabs*. That way, regardless of my editor settings for tab width, I'll see that your style is 8-space indentation and (as a good contributor) can follow that easily. Whereas if my tab-width is set to 4 or 2, then I'll never know that you want 8 spaces and you're more likely to get something inconsistent back (particularly if I'm trying to line things up across multiple lines at something that *isn't* a 8-space tab multiple.)

But this is not a problem if you follow the simple rule that you use tabs only for the lefthand indenting. If you need to line things up over multiple lines somehow such that this would break, then do not use tabs, use spaces.

Yes, in an ideal world I would and so would everyone else. Unfortunately, it's not an ideal world and when multiple people contribute to something, it's possible that someone won't follow that guideline.

My point was that using only spaces will (a) be more apparent to contributors that 8-space indentation is desired and (b) be more robust to fix when someone intentionally or inadvertently mixes tabs and spaces.

Yes, in an ideal world I would and so would everyone else. Unfortunately, it's not an ideal world and when multiple people contribute to something, it's possible that someone won't follow that guideline.

How is that different from any other guidelines?

My point was that using only spaces will (a) be more apparent to contributors that 8-space indentation is desired

But I am saying it is NOT desired. TABBED indentation is desired, NOT 8-space indentation.

and (b) be more robust to fix when someone intentionally or inadvertently mixes tabs and spaces.

I've never had any problem converting tabs to spaces, it's pretty simple.

Why should they care? No one needs to know. As long as everyone sticks to the rule that tabs are for indentation and only tabs are for indentation, tab width is completely irrelevant. Which is the whole point of using tabs at all.

If they don’t stick to tabs-for-indentation-only, what makes you think they’ll stick to any other rule? And how are violations of this rule much harder to fix than violations of other rules?

If a contributor used the same formatting conventions as in the rest of the code, then it’s easy to fix their patch – mostly, down-convert everything to spaces first, then up-convert space runs at the start of the line**, then check whether that introduced any non-indentation tabs, which is easy

Use tabs only at the very left of the line, and only to bring the line into proper indentation depth. If you need to move something further to the right (past its indentation depth) to line it up with something on the previous line, use spaces. In short:

Tabs are for indentation. Spaces are for alignment.

Use this simple rule and it won’t matter whose tabs are set at how many columns; there will be no inconsistencies, regardless.

I agree with the principle. The code owner decides the formatting. Of course, the contributors are free people also and can decide if they like the terms or not. I've got no problem matching somebody else's formatting in order to contribute, nor most of their code style. However, I'm personally not willing to expend extra effort to maintain compatibility with old perls, so I'd be liable to send in a contribution and say "Here's some work; hope you can use it" and respond to "Can you make it work with pe

--J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

The problem with that approach is that if you check in a tidied file it wallops the diff. Yes you can argue that you should retidy it to group development standards, etc. but those are largely manual processes that get developers grumpy.

Subversion has great pre-commit hooks, but the core problem is that you can't actually have it tidy the file and then check it in. And then you have to have your editor retidy to your specs.

But hey, this can be done with wrappers around the svn binary right? Someone has

When Perl Best Practices came out I was annoyed that it did not recommend tabs.I had a chance to chat to Damian at some point and I asked him why go for spaces and not tabs.

He said that tabs WERE a better choice, but by encouraging tabs it emerged that it was just too tempting for developers in general to then use the tabs after the beginning of the line, which (obviously) breaks things.

So on the balance of the two factors (what is strictly better, and bad behaviours that it encourages) the spaces option wa

Indeed, and indeed. I learned some of my tabbing practice from a codebase where tabs were used after indentation, such as to line up (in C) variable declarations' types and names. Took me a little while, many years ago, to get out of that (and unfortunately we still have a bunch of that lying around).