Inspired by Ovid, would people please shut about about the way I lay out Perl code?
Yes dammit, I use tabs for indenting. I've copped repeated grief about this.
I use 8 space tabs, because I have slight "figure-ground" problem, I find it a little harder than you do to pick out features from a background. So I don't see indents properly at 2 spaces, and I find 4 spaces a little annoying as well, whereas 8 is comfortable for me.
But I don't impose my indenting on you, I use tabs so you can see them any way you want, at any depth you want.
And no, no I don't use them anywhere other than left-hand indenting, because obviously it breaks. Tabs that aren't at the left of the screen are BAD, so I don't use them
My code looks like how I prefer it, and it ALSO looks whatever depth YOU want it to be. So when you have your editor set up to arbitrarily take my tabs and "clean it up" replacing the tabs with spaces, it's breaking my layout by making it conform with YOUR layout, and nobody elses.
On a related note, to gripe in the other direction, can I just say something about contributing to other people's code.
The maintainer of a CPAN module is the one that decides the structure and layout and rules. If you are contributing to somebody else's project, please try to follow their layout. If they use space indenting and 2 space, do the same.
If they use Perl::Critic and scatter # no critic entries through the code, try to follow the same if you can.
Now, god knows I totally appreciate people contributing to my modules.
But if you do PLEASE don't use Perl 5.8 expressions when the module is clearly labelled with "use 5.005 or use 5.006", "upgrade" my code to conform with Perl::Critic (apparending the rule set to the bottom of my POD) or run my code through a Perl pretty-printer with Perl Best Practices recommended settings.
Because I'm probably going to have to revert your changes, or waste a bunch of time going through and "fixing" all the changes you made.
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.)
And if someone should happen to insert tabs (at width 8) in matching your code style, it will be trivial to convert those back to spaces and everything will still line up. It won't be as easy to go the other way, I suspect.
Re:spaces and tabs
pudge on 2007-07-11T19:31:43
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.Re:spaces and tabs
dagolden on 2007-07-12T13:09:00
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.
Re:spaces and tabs
pudge on 2007-07-12T15:29:06
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 desiredBut 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.
Re:spaces and tabs
Aristotle on 2007-07-14T08:10:57
be more apparent to contributors that 8-space indentation is desired
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.
Re:spaces and tabs
dagolden on 2007-07-14T12:02:16
First, to clarify -- I mean that 8-character wide indentation is desired (by Alias in this case).
As long as everyone sticks to the ruleBut they don't (or Alias wouldn't be so annoyed).
My point about using spaces over tabs is that it will be more immediately obvious to anyone opening a file what the author's desired indention width is.
You may not like it -- you may think "what an idiot, using 8-space indentation instead of tabs!" but at least you'll notice. Or, if you should happen to use tabs at width 8, you might not notice and you might send in patches with tabs, but they'll line up fine and just have to be converted to 8 spaces again.
Re:spaces and tabs
Aristotle on 2007-07-14T15:55:43
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 if you break all the alignments by setting the tab width to something weird, eg. 5.
If they don’t follow the desired formatting conventions, then you have to re-layout their entire code anyway.
** Vim-speak:
s!^\v(( {8})+)!\=repeat("\t",strlen(submatch(1))/8)!Re:spaces and tabs
Alias on 2007-07-15T04:34:33
> My point about using spaces over tabs is that it will be more immediately obvious to anyone opening a file what the author's desired indention width is.
Only if every author does it!
If you use 8-spaces, and I use 8-character tabs, and I open up your code, I probably won't notice and just use tabs anyway.
So know you'll still have spaces and tabs mixed...
Re:spaces and tabs
dagolden on 2007-07-15T23:34:06
And then when I get the patch or sync from subversion, I can
s/\t/and I'm done./g Re:spaces and tabs
dagolden on 2007-07-15T23:35:22
That should have been 8 spaces, but the HTML rendering compressed it, of course.
Re:spaces and tabs
Aristotle on 2007-07-16T04:34:04
(Here’s an
just for you.;-) ) Re:spaces and tabs
dagolden on 2007-07-16T11:17:57
Thanks. I'm spoiled by <code> on Perlmonks where it DWIW whereas here it just changes the font. <ecode> works here, but forces a new block instead of doing it inline.
Re:spaces and tabs
Aristotle on 2007-07-12T05:26:15
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.
(This rule does break if you try to line things up verrtically across indentation levels. But that is terrible style when it’s code and just silly when it’s a “floating” comment block. If you don’t try ill-conceived things, the rule never breaks.)
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 perl 5.005?" with "I'm sorry; I don't have time. I hope you or somebody else can make use of what I sent you and adapt it or adopt it in some way."
Re:My god man!
Phred on 2007-07-11T18:36:25
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 to have done this...
Re:YES
Alias on 2007-07-12T00:27:02
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 was chosen.
So, as far as I'm concerned, the Perl Best Practice is "If you have discipline, use tabs":) Re:YES
pudge on 2007-07-12T02:01:01
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).
Re:YES
jdavidb on 2007-07-12T05:38:44
Hmm; I'm almost persuaded. I may start using tabs.
New pragma: use tabs = '4 spaces';
Ron Savage on 2007-07-13T06:08:38
Heh, heh, heh.
… is have tabstops expand or shrink to fit their contents. In fact this would also make proportional fonts palatable for coding. Now if only editors actually supported all that…
