When I see code like this:
# Locale-ize the parser
my $ampm_list = join('|', @{$self->{_locale}->am_pms});
$ampm_list .= '|' . lc $ampm_list;
Vim:
set expandtab
And your troubles are over
... until you have to edit a friggin' Makefile
(expandtab converts tabs to their equivalent spaces. There are many similar commands to get fine-grained control over this)
Of course, if you just want to show unwanted whitespace, we have plenty of builtin ways of doing that.
Major modes are major useful.
schwern on 2009-02-23T03:24:24
You mean vim isn't smart enough to know you need leading tabs in Makefiles? Hmm, too bad.
Re:Major modes are major useful.
Aristotle on 2009-02-23T03:49:53
No, Ovid just isn’t smart enough yet to tell it.
:-) From my
.vimrc:autocmd FileType python setlocal expandtab
Re:Major modes are major useful.
Aristotle on 2009-02-23T03:57:41
Oh, and the
makefiletype plugin could easily set this automatically. I don’t know why it doesn’t, but it doesn’t bother me that it does not, either.Re:Major modes are major useful.
Ovid on 2009-02-23T08:10:52
It's configurable on a "per filetype" basis. I just don't edit makesfiles often enough to care and I set it manually then.
Re:vi? What about vim?
Aristotle on 2009-02-23T03:56:14
The real equivalent to what Michael is doing is called
:set list, which will render tabs as ^I. In vim but not vi you can also use thelistcharsvariable to control how tabs are rendered, as well as various other invisible things like end of line, trailing whitespace, line cut-off at screen edges, etc.
Tab users like to tout that it allows you to use whatever indentation level you like when in reality you just wind up with mixed up tabs and spaces.
I’ve been programming with tabs for indentation and spaces for alignment for the better part of a decade.
I’ve never had a single problem keeping things straight in my own code.
Re:What is this reality you speak of?
schwern on 2009-02-23T04:24:06
I've never had a single problem keeping things straight in my own code.
Its your code and your style, of course it makes sense to you! You could write in rot13'd Swahili and it would still make sense, but only to you.
Here is the best advice I can give about writing maintainable code: It's not about you. It's about everyone else. Each personal style quirk that others have to puzzle out or adjust to or in any way hampers and frustrates their ability to quickly skim and patch your code loses you patches. This means more work for you.
Same reason I don't like quirky bracing styles. All the arguments about their superiority in the world won't change that they make everyone else's brain strip a gear trying to read them.
Re:What is this reality you speak of?
hdp on 2009-02-23T04:29:24
Schwern
, I think you underestimate the productivity gains
; your quirky style is my well-tuned machine!Re:What is this reality you speak of?
Aristotle on 2009-02-23T04:52:37
You could write in rot13’d Swahili and it would still make sense
Oh please. Your argument might hold water if you weren’t talking to someone who is about 17× more obsessed with clarity than the average programmer – and has gotten the compliments to prove that it makes sense to others. (I hate boasting, but for the sake of this argument I need to point out the evidence that it’s not just in my head.)
It’s not about you. It’s about everyone else.
When in Rome, I do as the Romans do. When I’m just a contributor I don’t go on crusades to enforce any particular style on someone else’s code, I follow the one I find, even if I shake my head at it.
When the code is mine, I equally expect others to adhere to the style I use.
Re:What is this reality you speak of?
schwern on 2009-02-23T05:42:19
Oh please. Your argument might hold water if you weren’t talking to someone who is about 17× more obsessed with clarity than the average programmer – and has gotten the compliments to prove that it makes sense to others. (I hate boasting, but for the sake of this argument I need to point out the evidence that it’s not just in my head.)
Don't get so excited, I do silly things too.
Unfortunately, this is an ad hominem argument essentially saying that because one does A, B and C good things that D must be good as well. While it may improve the probability that D will be a good thing, it does not itself constitute a valid argument. It would be just as wrong of me to try and defend a bad test by pointing at my years of testing experience.
When the code is mine, I equally expect others to adhere to the style I use.
Herein lies the problem. While it is good as a contributor to follow the project style and avoid clashing with the rest of the contributors, it is not good as a project to use an odd style. Why? Consider the worst case where each contributor works on N projects. If N projects each have their own style each contributor must learn N styles. They have to rejigger their editor and their brain when switching projects. This, simply put, is drag on the contributors.
Worse, if your style is in the minority then few contributors will be comfortable with it adding yet more drag. Each new contributor has a higher probability of never having encountered this style before, and it doesn't take much annoyances for a new contributor to decide it's not worth it.
This doesn't even get into which style is "better". It trumps it, doesn't even let it get started. The coordination concerns are so much more important than any possible benefit either the tab or the whitespace indentation camps could put forward. That's something good project managers learn quickly.
Consider this. Let's say I finally got around to being comfortable with the Colemak keyboard layout. Now let's say I want to pair program with others using my machine. Do I leave the keyboard in Colemak? Will this help getting work done with my pair? Will people be more likely to pair with me if I do? No. Even if Colemak is clearly better than QWERTY, it's still awkward and annoying for everyone but me.
Re:What is this reality you speak of?
Aristotle on 2009-02-23T06:00:43
If N projects each have their own style each contributor must learn N styles.
Ah, the Python school of thought. I like Perl better.
Re:What is this reality you speak of?
schwern on 2009-02-23T07:25:54
[Hmm, is invoking Python the Perl variation on Godwin's Law?]
Although the Perl Slogan is There's More Than One Way to Do It, I hesitate
to make 10 ways to do something.:-)
--Larry Wall inThere is merit in the Python view on style. Like anything else, the key is knowing when to apply a rule and when not to. You don't want to over do it and pave the community flat. You don't want to under do it and wind up with style Balkanization. I think it's perfectly fine to have lots of different styles, IF they have enough advantages to offset having to retrain.
Neither tabs nor whitespace as indentation have a clear advantage over one another. The programming community argues endlessly over which is "better" to no conclusion. Like the mule who stands equidistant between two equally delicious bales of hay, we kill ourselves because we can't just PICK ONE AND STICK WITH IT!
Re:What is this reality you speak of?
grantm on 2009-02-23T07:21:19
I'm 100% with Schwern on this one. Tabs for indentation are just evil. Sure it works OK for you because you have your tools set up a certain way. But when you collaborate with others their tools will be set up differently and what they see will be different to what you see. For example I picked one of your CPAN modules at random and scrolled down looking for messed up indents. Sure enough in XML/Atom/SimpleFeed.pm starting line 334 you have a group of lines that are indented with space rather than tabs. You can't see that because as Schwern says, tabs are invisible.
The reason I could zero in on the example so quickly is I have this handy little setting in my vimrc:
match Error
/\t\|\s\+$/ That causes trailing whitespace of any type and tab characters in any position to be displayed with a red background. Of course I also have a handy key mapping to turn that off when I'm working in a tab-infected project.
Re:What is this reality you speak of?
Aristotle on 2009-02-23T08:05:55
Figures. From looking at what part of the file it happened in, I know exactly what went wrong, too. Vim and me, we let each other down, there…
:-( I’ve added
set listto my.vimrcto ensure it won’t happen again.(The apparently-empty lines that this exercise revealed further down the file (in the POD section, l.427 ff.) bug me even more.)
So you expected the vim users to flog you with comments. I'm a vim user, but here's for something different:
With *Padre*, you can configure your favourite indentation setting, then check the little box that says "automatic indentation finding" or somesuch and it'll use your own style for new files, but it will automatically adapt to the indentation style of existing files as you open them! It also honours the vim and emacs style magic comments that are used here or there for setting the indentation style.
It's not perfect (yet), but works so well that I wonder why vim doesn't do it out of the box. I don't know about emacs, but I don't think it does that either.
Re:How about this?
schwern on 2009-02-23T10:23:23
Ok, that's damn hot. Now I will give Padre another look.
Re:How about this?
tsee on 2009-02-23T13:15:21
The really strange thing is that it's such a basic convenience feature that could and should be implemented anywhere.
The current implementation of the indentation finding in Padre is actually pretty horrible. It's in the Text::FindIndent module on CPAN. (I hacked it up so I can bash it, too.) The one thing that breaks it occasionally is POD. If you have a lot of POD with verbatim blocks in it (where most people use spaces regardless of how they indent their code), they aren't ignored. That would be a rather modest change, but nobody has felt the itch yet.
While I'm at it: There's another reeeaaally nice feature: The online syntax checking. It requires that you make sure all modules in your project can be compiled in arbitrary order, but in my experience developing Padre itself, that's *usually* not too hard. This has saved me a lot of silly mistakes in the past.