I'm somewhere between "don't mind" and "avoid". Using tabs in my free software causes me to get a steady trickle of confused mail from people who have loaded it into an editor which interprets a physical tab differently from the standard (notably Visual Studio, which AIUI can be configured into sensible mode but not per-project), and also I sometimes find it actually inconvenient during editing because tabs make complicated editor macros less predictable. So I quite like no-tabs as a policy. But I haven't adopted it yet, mostly because detabbing all my existing source would be a tedious and annoying job with plenty of scope for messing things up and would also have unhelpful effects on things like "svn blame".
Work enforces a no-tabs policy by automatic detabbing at checkin time (and you have to specially mark each makefile as exempt from this when you create it). This is surprisingly infrequently a problem, and generally seems to work well for everybody. (Though I don't think I'd go that far myself, although I might be tempted by refusing a checkin that contained an unsanctioned tab.)
IWBNI annotate commands had an option to skip whitespace-only changes. Maybe some do. It'd also be useful for the case where you change the indentation on some bit code because it's become conditional or repeated or something.
Not to be mixed, at all costs? Otherwise, I don't mind so much. I'm sure one is better, but I have generally been constrained, so haven't found out which.
I tended to use four spaces, but at work we settled on tabs (since different people have different shiftwidth preferences, and tabs seemed to alleviate this a little) and that works fine.
As long as they're not mixed, in which case things will only look right at one shiftwidth setting.
And what is really bad is if code that uses mixed spaces and tabs gets edited by someone who has a different tabstop setting and automatically converts tabs to spaces on saving. I once had to work on such code, and it was a mess; I wish the original tabs had remained since then I could have fiddled with my tabstop setting to get it to look proper.
Well, we were taught that tabs in your code, when used correctly, make your code clearer (and certainly, in Java I found it useful to mark out where different methods were in the flow of things). On the other hand, having tabs but no curly braces (like in Python) confuses rather than helps me for some reason. :/
The trouble with tab characters is that they don't, by themselves, specify enough information to display them. You need to know where the tab stops are; in the absence of this information then there's no reason to expect text to come out looking the same way in different environments.
I think I urgently want something like this; I've yet to think about what's actually possible (but for the moment, it would have to be backwards compatible with turning-into-spaces at work).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Or even: prefer spaces to tabs where practical, and always use spaces in Python
so I chose the combination of options that best expressed this.
no subject
no subject
Work enforces a no-tabs policy by automatic detabbing at checkin time (and you have to specially mark each makefile as exempt from this when you create it). This is surprisingly infrequently a problem, and generally seems to work well for everybody. (Though I don't think I'd go that far myself, although I might be tempted by refusing a checkin that contained an unsanctioned tab.)
no subject
no subject
no subject
I tended to use four spaces, but at work we settled on tabs (since different people have different shiftwidth preferences, and tabs seemed to alleviate this a little) and that works fine.
As long as they're not mixed, in which case things will only look right at one shiftwidth setting.
And what is really bad is if code that uses mixed spaces and tabs gets edited by someone who has a different tabstop setting and automatically converts tabs to spaces on saving. I once had to work on such code, and it was a mess; I wish the original tabs had remained since then I could have fiddled with my tabstop setting to get it to look proper.
no subject
Now for the hard question: do you do tabs in SQL?
no subject
no subject
no subject
Well, we were taught that tabs in your code, when used correctly, make your code clearer (and certainly, in Java I found it useful to mark out where different methods were in the flow of things). On the other hand, having tabs but no curly braces (like in Python) confuses rather than helps me for some reason. :/
no subject
no subject
no subject
no subject
(http://search.cpan.org/~dconway/Acme-Bleach-1.12/lib/Acme/Bleach.pm)
no subject
no subject
no subject
no subject
no subject
no subject