Slashdot Mirror
Elastic Tabstops — An End to Tabs vs. Spaces?
An anonymous reader writes "Along with Vi versus Emacs, the tabs versus spaces argument must rank as one of the classic holy wars among coders. Here's an attempt to solve it by making tabstops expand or shrink to fit their contents. The concept's pretty cool to use, so be sure to have a play with the demo!"
both vim and emacs will do this. unless i misread the question...
Wave upon wave of demented avengers March cheerfully out of obscurity into the dream
Eclipse does that.
:set ts=4
I don't know what the big deal is, just
A dyslexic man walks into a bra.
I vote for TAB = 4(four) Spaces
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
in vim: ctrl+v and select your area, shift+i,tab,escape
You might as well tell the world "Earth's official language is now officially Esperanto, so fuck you". The effect would be about the same.
I don't care if it's 90,000 hectares. That lake was not my doing.
Use of the term "Holy War" implies that the root of the disagreement is a clash of values, and intractible of resolution except by agreeing to disagree.
My bible says it is morally wrong to use Vi.
I mean, the same could be said for, let's say, PageMaker. Or OpenOffice. Or a lot of text layout tools.
But code editors they are not.
We brough content folding and syntax highlighting to text editors. Now it's an appropriate time to bring them layout magic, I suppose.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
The way we got into this mess is that in early versions of UNIX, tab stops were set to 8 spaces in the TTY handler. This was not because tab stops were intended as indentation. It was because an ASR-33 teletype could tab that far in one character time. It was for optimizing output time. (Back in those days, TTY output processing had to have time delays to handle the mechanical lag in printers. "How many nulls were required after each carriage return" was an issue, and better systems kept track of the printing column position and adjusted the delay accordingly. Peripherals used to be really dumb.)
If some reasonable indentation value like 4 or 5 had been chosen, everything would have been fine.
nm...think i misinterpreted the question
Whether or not this solves the problem (I don't think it does), I get real nervous when source code starts being perceived as a document that lends itself to proportional fonts. Maybe I haven't been in the latest and greatest IDEs lately and am missing something here, but source code seems to scream for canonical form, and proportional font is not that.
I think vim has a reasonable approach (do the research: shiftwidth, tabstops, softtabstop, etc.), I assume there are other approaches in emacs.
Start talking about proportional font source code documents, and now everyone's going to want to have styles, and all the confusing garbage that is word processing. As difficult as source code and programming is, it doesn't need to be more nuanced in word processing.
Tabs have been and should continue to be what they are. If you need to format code within the 8 spaces, then use a tab. Otherwise use a space. In no other way can we get source code that looks consistant across editors and platforms. Especially in neat languages like python. Attempts to redefine tab stops are misguided. And don't even get me started on the use of proportional fonts in programming editors. Heresy.
In vi or vim, put the cursor on the opening brace and type '>%' (that's to indent; type '<%' to exdent).
Better to light a candle than to curse the darkness.
I move that we temporarily adjourn proceedings and reconvene on Thursday of next week, for the dupe.
They became interwoven into the computer-programming subset of society back in the 60's and 70's, if not earlier.
But even beside that, a lot of things are set semi-arbitrarily in the tech world. So why not the length of a tab?
Because the proposal isn't to define a new standard, it's to re-define a very well-entrenched (if crappy) existing standard. All 60 million people who are already happily accustomed to doing things the old way will simply ignore the new "standard", and a standard which nobody uses is worthless.
I don't care if it's 90,000 hectares. That lake was not my doing.
Actually, it is attempts to do that which have created the current confusion. Some were obviously too long, some obviously too short, and the end result is tabs which aren't useful.
I actually like this idea, because it actually you from using this seemingly-simple but in actuality horribly complicated idea that tab = x*space. Instead they have an actually simple idea: Each tab is a seperate column of text. Line up items in the same column with each other. (Of course, how simple this is in practice is yet to be deterimined, but it seems simpler to me.)
This idea is actually about seperateing sementic and content info. Programmers use tabs (those who do) to convey sementic info. If we can make the program understand that, then we can offer more flexiblity to the user on how to present the information.
'Sensible' is a curse word.
Indeed, screw this. I'll just stick with the PEAR standard of four spaces per indent, no tabs.
In command mode, == auto-indents the current line, << and >> indent to right and left respectively.
Back to the original article, I have the following in my
python>>> q="'";s='q="%c";s=%c%s%c;print s%%(q,q,s,q)';print s%(q,q,s,q)
Anyone know of an editor that has this?
If you want that from an IDE, eclipse does that, and pretty robustly at that. I wouldn't want to miss it.
For more simple editors for a quick text edit, my favorite is EditPlus. It lets you choose between classical tabs and whitespace tabs, as how long (in characters) a tab in either mode should be treated, it has the auto-indent you mentioned, reacting to freely definable characters (for example, auto-indent forward after '{' or '(', and back after '}' or ')', respectively). Best of all, it lets you define these parameters independently for plain text, c/c++, java, HTML, Perl, etc., etc., as well as any number of custom syntaxes you may wish to import or define yourself. A small selection of useful features of a great tool. Disclaimer: I am in no way affiliated with Editplus or the company behind it, just a happy user.
The grass is always greener on the other side of the light cone.
He's right that mandating "tabs must be N spaces" is stupid, though. Use tabs to indent blocks of code, use spaces for aligning code that isn't in blocks, and people should be able to set whatever tab size they want without ruining anything.Now, let's see if I can keep this from being mangled by Slashcode...
On preview: no, I can't. Well, imagine that the C in Class is directly under the i in int, and imagine that the a in arg2.is_valid() is directly under the a in arg1.
Of course, getting this right every time isn't easy when you're trying to think about your code and your editor has it's own ideas about indentation. I'd be very happy if anyone could tell me how to get Vim's autoindent to behave this way.
I think you're on to something. Some regulatory body or Linus should redefine the tab length permanently. It's silly to have system dependent or editor dependent definitions of tabs.
And things like this are standardized all of the time in committees to pretty good effect. For instance, whatever language you code in was probably standardized by a committee that just claimed authority over the language and was granted it de facto by the compiler writers.
You might as well tell the world "Earth's official language is now officially Esperanto, so fuck you". The effect would be about the same.
La lingvo oficiala da tero estas Esperanton, tial fiku vin!
www.wavefront-av.com
i was about to comment on how key combinations like that are why i use emacs, then i realize...
C-Space C-c } Tab
A mouse is a device used to point to the xterm you want to type in
oops, i meant C-\ not tab
A mouse is a device used to point to the xterm you want to type in
Then emacs will replace tabs with spaces. In the various programming language modes, tab indents to the right location (Which you can customize somewhere else.)
vim has a similar setting but I rather despise vim (I prefer nvi or old school vi when doing vi things.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Wrong. A TAB represents 1-N spaces, depending on the current column, where N is the tab setting. I've never seen a TAB interpreted as a fixed number of spaces, and I've seen a lot of output devices in the 40 or so years I've been playing with computers. TABs move the output position to the next tab stop, not some fixed number of spaces.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
What a great social engineering trick - get 30% of Slashdot readers to locally execute untrusted code with local thought. Cracker, my hat is off to you!
> Anyone know of an editor that has this?
I believe kwrite/kate is still missing from the already long list of editors which have that feature. Usage instructions: Ctrl+I indents the current line/selection. To extend to a full loop / section, either select the section manually, or use the code folding feature and select just that one line before pressing Ctrl+I. Ctrl+Shift+I to unindent.
Tabs versus Spaces: An Eternal Holy War.
Jamie Zawinski
A very clever solution indeed. Apparently some clever bastard sovled this issue six years ago. Return to your homes. Nothing left to see here.
So, uh. What the fuck does VS have to do with anything?
I've never used it so I can't comment. So it has variable-width fonts and logical indenting and spacing? Good for them.
If it appears in anything _besides_ Visual Studio I'll be a happy camper.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I too use 2 space indents but find the nice round wrap of 80 works better for me.
Tabs get strange when you edit in Vi and everything is nice because you set the tabs correctly and you send it to a cow-orker who uses, Lord have mercy on me for the unholiness I am about to utter, Dreamweaver, and decides to tab everything and then send it back after it has been "cleaned up" by Dreamweaver and it looks like a rat's nest. Then you are forced to LART them into next month for both using such an inane program and "cleaning up" your code with it.
No animals were harmed in the making of this sig.
Well, there was that one puppy, but he is all better now.
La lingvo oficiala de terglobo estas non oficiale esperanton, do fiku vin!
;-)
Are you happy? / Cxu vi estas felicxa?
Silly Slashdot and its lack of UTF-8 support
Colin Dean Go a year without DRM
I can grudgingly accept the arguments of the web site mentioned in the summary, but I am not convinced their solution is the answer. Certainly it will only work if *all* text editors work that way. And that is not likely to ever happen.
Mod grandparent funny and parent even funnier. :-)
Human being (n.): A genetically human, genetically distinct, functioning organism.
How can you tell whether nobody will use a new standard if it is significantly better than the old one? If you admit the old standard is crappy, why not even try for the better? Considering how tabs tend to break across platforms or even across applications, it already seems like everyone is doing what he wants anyway. Doing or not doing things because "that's the way it used to be and we don't want change because change is hard" just doesn't make sense, especially considering the fact that we're talking about computers. That's not exactly a field whose methods are carved into proverbial stone like, I don't know, metal smithing, pottery, or something ancient like that.
The grass is always greener on the other side of the light cone.
Mi pensas, cxu "fikugxi" ne estas pli tawga vorto? :P
Saluton, karaj esperantistoj!Score: i, Imaginary
If you play with the demonstration editor a bit, you can see that this has potential.
BUT, I think it would only be useful in editors with some syntactical idea of the code they're editing, like Netbeans/Eclipse/vim and so on. In the demo editor, for example, tabbing will properly indent code only if you put a brace on its own line. If you don't, you get this:
if (blah) {
foowayoverhere();
}
Because it indents the next code too far, treating it as a comment. This idea could be very useful to coders, but it's really not for normal documents and it should not be implemented in editors where the format of the file is not known or completely understood.
But for XML editing...
Tab is short for Tabulate - make into a table. Source code is not a table.
If you want to represent data in a tabular form then use tab stops and the tab character to separate the data items such that when it is displayed the data items form columns.
Source code for most languages is not like that. It happens to be convenient to use the 'tab' key as if it were an 'indent' key and space can be saved on disk by representing a number of spaces by a single character, but the 'tabbies' are confused.
It happens that _some_ languages are 'tabular'. Assemblers, for the most part, are best represented in columnar form. Perhaps the tabbies are locked into the 1960s when programs were written on 'card punch forms' and a format card was used to set the tabstops for the punch girls, but the cards had _spaces_ on them as Hollerith intended, the tab key did _NOT_ punch a tab character into the card.
I do use the tab key as a means of stepping along a number of spaces but the resulting files has exactly the number of space characters that are necessary and no tab characters at all.
Me too!(too)
My coding style is that a single function can go several levels/indents deep, too wide a tab space can really start eating up screen space.
The revolution will not be televised... but it will have a page on Wikipedia
The problem is depending on what source control system you are using you may get screwed over by diffs looking really bad depending on how it thinks of whitespace.
Otherwise I agree with you, and personally I would always opt for a version control system that would let people reformat code whitespace to their liking.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I think we need to decide what refreshments will be available on the thursday. I vote that we're at least allowed 3(three) sausages if we choose the sausages 'n mash option, 2(two) just isn't enough.
The revolution will not be televised... but it will have a page on Wikipedia
However, this type of formatting has been around for a while, in better language-sensitive editors, where you can adjust for formatting for the various coding contexts.
A better compromise would be to read any given code file for the given language, sense the coding style of the original document and interpret and display it on the editing widget in the manner you think the author wanted. Preserve the original document internally as a document tree and at save time, either save in exactly the same coding style as the original, or in the style the user wants. This would be similar to XML DOM readers that preserve an exact model of the original document in memory. And it is displayed according to its semantic meaning, not a tab or space count.
This would respect the coding style of the original author, while giving options to the user of the editor. A much better compromise, I think.
Mi pensas, cxu "fikugxi" ne estas pli tawga vorto? :P
Jes, sed "fikugxu"? Mi ne scias. Posible "fikugxegacxu"? :-)
That last one makes me want to say "Gesundheit" (try saying it out loud).
www.wavefront-av.com
It's so simple, it's quite embarassing for the whole of the computer-literate society that people still get their kickers in a twist about it.
Anybody who tries to lay down the law by saying that a tab must be 4, 8 or 2 characters' width has missed the point of the tab key completely.
As for your wish, I'm willing to bet money that either vim or emacs will do it for you.
NEVER use tabs in code - or if you do, use an editor like jEdit that can automatically change them to spaces.
Or when you edit code and just have to change someone else's layout, do a find-replace on tabs with however number of spaces you want instead?
So far as I know, "tab" has always meant "Advance the carriage to the next tab stop" and has never meant "advance a fixed number of spaces". The default tab stop setting varies from program to program. In Word its on 1/2" boundaries, and in most editors its on 8-character boundaries.
Intron: the portion of DNA which expresses nothing useful.
So, um, *what* better editor? jEdit doesn't seem to have features that vim or emacs lack, which is good, but it doesn't seem to have a console-only version, which makes it entirely useless to me and anyone else who programs on a remote machine over ssh. You're just insulting people without offering any reasonable alternative, and proving that you are nothing but a rabid fanboy. While you froth at the mouth, I'll be over here, doing some programming in an editor that will actually run on the machines I work with.
The subject of tabs vs spaces should be clear enough to everyone.
Let me quote the relevant standard:
Linux kernel coding style
[cut]
First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it. Burn them, it's a great symbolic gesture.
[cut]
Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.
Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.
In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.
[cut]
But even if you fail in getting emacs to do sane formatting, not
everything is lost: use "indent".
Now, again, GNU indent has the same brain dead settings that GNU emacs
has, which is why you need to give it a few command line options.
However, that's not too bad, because even the makers of GNU indent
recognize the authority of K&R (the GNU people aren't evil, they are
just severely misguided in this matter), so you just give indent the
options "-kr -i8" (stands for "K&R, 8 character indents").
"indent" has a lot of options, and especially when it comes to comment
re-formatting you may want to take a look at the manual page. But
remember: "indent" is not a fix for bad programming.
Linus Torvalds.
I vote for TAB = however many spaces you want it to be. If you meant "move to the right by the width of four characters", press the space bar four times.
Escher was the first MC and Giger invented the HR department.
Tab is already standardized. It means either "move onto the next record" in tabular data, or in programming languages "indent". If you have a preference for how much like code to be indented, then you get to set your editor in accordance. Indenting code with tabs is far more considerate than indenting with spaces. Indenting with tabs says "Indent a little. I trust you to set your editor accordingly". Indenting with 4 strikes of the space bar says "In my opinion, four spaces, not two, nor eight, nor six, is the only way to indent. If you want to read my code you shall accept my rules".
For several large projects I work with where there are lots of developers, consistency of the source code is considerably more important than any particular developer's opinion on what the correct behavior of tabs and spaces are. These are projects where it is pretty much expected that there are or will at least eventually be developers that use both vi and emacs with zealotry as well a myriad of IDE environments. For at least vi and emacs, all source files utilize a local variables block that is understood by both editors in order to encourage a project-defined convention with consistent indentation:
With that comment block at the very end of all source files (whether they be C, C++, Tcl, Perl, Sh, SGML, etc), we do quite well in maintaining order and minimizing the indentation dispute. For the IDE environments, it at least gives them clear documentation on how to configure their IDE indentation preferences to match in every file. Maintaining a tabwidth/tabstop of 8 ensures consistent source display in most environments, including text printing and console display, leaving projects to simply define what offset/shiftwidth level they want for indentation. It can similarly still be tweaked for the projects that seem to insist on no tabs or want to match some IDE default religion.
Cheers!
Sean
Not at all. At least vi's syntax for this is noun-verb setup: the > says to indent, and can be followed by any range specifier - % happens to jump matching brace pairs. You could as well have said %6j to indent the next 6 lines.
I'm sure a lot of things seem so simple when you're so ignorant of the actual issue.
Doesn't solve the problem at all. While his idea of lining up code that belongs together, e.g. code in an if-statement, is good, it doesn't address the fundamental problem of whether tabs or spaces should be used and how many characters/spaces should a tab/space use. One has to start indenting code before one can line up the rest of the code, so how does one start?
"Money is the barometer of a society's virtue." - Ayn Rand Atlas Shrugged
I honestly don't see this as a problem (though certainly recognize that some people view it as such). My personal belief is a TAB should be a TAB and a SPACE should be a SPACE. If your organization (which might be an OS foundation, corporation, class at school, yourself, whatever...) recommends/enforces style guidelines, let the group dictate.
Also, if it is a big concern, make use of sed to standardize the code (as best as possible) and then use it again to convert back and forth. It is available for win32 as well you know http://unxutils.sourceforge.net/
Oh, and one last note: A good editor will let you set the tab length in the display. I did like in the demo JAR how the comment lengths would stay (right) aligned (mostly) - which would be a very nice feature to toggle on/off in an editor as well.
Emacs can do all that. The only drawback is that you have to use Emacs :) ccmode and a abbrmode, I think.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
> I think this is the wrong kind of solution to the problem. A standard would be easier.
Clearly you are not familiar with the tabs-vs-spaces argument.
Advocates of tabs say that having everything indended by multiples of some standard
amount is a good thing. This is, of course, wrong for source code in many computer
languages, because it prevents things from being indented to the correct position
relative to the line above, as in the following example (in the Inform language)...
Object matchbox kitchen_cupboard
class cardboard,
with short_name "matchbox",
description "A standard cardboard matchbox.
It says ~Strike on Box~ on the side.",
name 'matchbox' 'box',
has openable container;
I suppose it doesn't matter for write-once applications, but if you're trying
to write _maintainable_ code, it's essential to have things line up properly,
and that means they often need to line up under specific characters on the line
above. That's possible with tabs if the character they need to line up under is
preceded by whitespace (as it generally is with e.g. SQL), but if that's not so,
tabs are useless. I don't see how these new "expanding" tabs change that.
Inform is the *best* example I know of a language that *cannot* be properly
indented with only tabs, i.e., spaces are *needed*. There are other languages
with which this is somewhat true, e.g. Lisp (wherein you often want to line up
under a specific open-parenthesis which may not be preceded by whitespace)
and Perl (although most Perl code is not indented as well as it could be,
partly because tools such as cperl-mode do not support it).
If you agree on a fixed width for tabs (e.g., 8 characters), you could use a
mixture of tabs and spaces, but that won't make tab-indentation advocates happy,
because they want to get *rid* of leading spaces and use tabs only, usually
because they want to use proportional fonts. If you're going to use spaces
for indentation, you might as well use all spaces and no tabs.
Cut that out, or I will ship you to Norilsk in a box.
I vote for this to be the next Slashdot poll.
Linus is already on record saying that tabs == 8 spaces. However (and sorry to burst your bubble) Linus isn't God. He isn't even Moses.
8 spaces makes very little sense for some environments, especially this newfangled web programming thingy all the cool kids are doing these days.
Go somewhere random
Wait. Doesn't this miss the entire purpose of tabs?
I like to see my code indented by the equivalent of two spaces. The other coders in my team like to see their code indented by the equivalent of four spaces. Do we engage in massive edit wars in cvs? Do we regulate a specific number of spaces so that some portion of the team is unhappy? No. I setup my editor to display tabs as the equivalent of two spaces, and the others setup theirs to look like 4 spaces. Everybody is happy.
Regulating a specific number of spaces is sub-optimal. It totally removes a coders flexibility to see the code how they prefer.
I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly. Anyone know of an editor that has this? both vim and emacs will do this. unless i misread the question... I think maybe he's asking for something that moves a whole block of text like (emacs example) Ctrl-Space at beginning, cursor to end, Ctrl-X-Tab... but does so without having to cursor all the way down to the end of the code block, instead just using the indent status of the current line to determine the scope of the requested block indent.
If a job's not worth doing, it's not worth doing right.
I really wonder what code you're writing. In *some* cases, excessive indentation is unavoidable, especially in web environments. But in most cases, excessive indentation is a sign of poor programming, and you should probably recheck your code to see if it can be improved.
Go somewhere random
I think maybe he's asking for something that moves a whole block of text like (emacs example) Ctrl-Space at beginning, cursor to end, Ctrl-X-Tab... but does so without having to cursor all the way down to the end of the code block, instead just using the indent status of the current
If a job's not worth doing, it's not worth doing right.
There is no bubble to burst. He's just a useful opinionated loudmouth to have on board. I mean, who could be bothered arguing with him?
Brief
I don't mind tabs. I don't mind spaces.
But God help you if you mix them together in the same program.
I've met editors that put four spaces for the first indent, then a tab for the second (removing the previous four spaces in the process). It was fine when you viewed the code in that particular editor, but open the same code in another editor with different tab stops, and it became practically unreadable. If they'd stuck with just tabs or just spaces it would have been fine, but nooooo.... some bright spark had to mix 'em together. Grrrrrrr.
(For what it's worth, the editor in question was LSE, on a VMS system. I don't know to this day whether that was the default setting or a setup made by someone at the company, but it caused a nightmare when we ported the system to Windows)
(Spudley Strikes Again!)
Y'know, there really ought to be a way to use rot13 on Slashdot so that innocent eyes wouldn't have to see things like that. Think of the chillllllllllldren!
Good, inexpensive web hosting
This is how I code, at least in C-like languages. You can set your tab length to whatever you want, and my sources still look pretty:
//Every line starts with tabs: //Tab can be any length, whole line moves in or out
int foo ()
{
if (
some_really_long_expression &&
some_other_really_long_expression
) {
DoSomethingClever(42);
DoSomethingComplex(
param1, //Tabs start the line, spaces between param and comment
param2, //Comments line up, thanks to spaces
param3
);
return -1;
} else {
return rand();
}
}
How do you say "Fuck you" in Esperanto, anyway? Bablefish doesn't have a translater for that...
You see? You see? Your stupid minds! Stupid! Stupid!
eg: (---> means 'tab', '.' means 'space')
void foo ()
{
--->if (something)
--->{
--->--->/* I like to format my comments so that
--->--->.* the stars make a vertical line,
--->--->.* but I don't care how much you like to
--->--->.* indent */
--->--->bool something = SomeLongFunction() &&
--->--->.................Another()
--->}
}
This code satisfies everybody with a good text editor. If you like 8 spaces, set your editor so. If I like 2, 7 or 3.14 I can set mine. Pressing space n times annoys everybody who likes 2n, n/2 or any other number of spaces.
That way they can get on with arguing over important issues like the placement of {
;)
Beautiful! :)
The following Normal mode command in Vim will reindent your whole file for you according to the indenting rules for that language (user-defined, or the Vim defaults): gg=G Want to get rid of that annoying, end-of-line whitespace that's been inserted all over the place? :%s/\s\+$//
I understand your point, but why do you consider "easy to use" and "powerful" to be incompatible?
This isn't the days of the PDP-11 -- there's more than enough cycles and megabytes to spare for running a nice, friendly text editor with a *sane* set of keybindings, *helpful* help text (none of the traditional *nix man nonsense, e.g., "the yank keystroke yanks text from the yank buffer") and easy customization (note: putting "SET SW=2" (crap, it's probably case-sensitive, so it should be "set sw=2", or is it "set sw = 2" ala bash scripting) is *not* easy customization, especially since that hack is probably only documented at the bottom of some completely inaccessible man page, if at all).
By the way, your analogy if flawed. If text editors are to be compared to heavy-duty industrial machinery, VI is a steam shovel. *Wood fired*.
Actually, this does sound superior to me over the first two (especially for something like Python where indentation is meaningful).
But if you thought we had holy wars now, just imagine the nightmare that a third option will introduce...
I am also of this camp, in that Tabs are only allowed at the beginning of the line. I do get complaints from others about this part:
// Comments line up, thanks to spaces
1.
param2,
if param2 changes (ie, imagine a more complicated line), you waste time re-aligning the comments. Of course, with tabs=3 or 4, you might also need to realign, just not as often.
The other complaint is similar - aligning #defines:
2.
#define Foo 17
#define BARBARBARBAR 18
people don't like aligning these by spaces - it just isn't as quick. Even I don't like using spaces here, but I do it because I believe in tabs-only-for-indenting as the best overall rule.
I'm tempted to either
A. find (or somehow customize) an editor that will change tabs to spaces ONLY in the middle of a line
or
B. make a hot-key that turns tabs=space on/off, so I can turn it on while doing #defines, then shut it off. So my #defines are aligned with spaces, but I used tabs to enter them.
Any other suggestions? 1. and 2. are the only arguments against tabs-only-for-indenting that I think are somewhat valid, and I'd like to get rid of them.
---
I type this every time.
Yet another application of the old adage saying that the good thing about standards is that there are so many to choose from, I guess...
> I understand your point, but why do you consider "easy to use" and "powerful" to be incompatible?
What's not "easy to use" about pressing one key to perform a complex operation. I'm no vi fan, but that sounds easy to me.
(emacs is M-x indent-region, or whatever you've bound that to.)
My other car is first.
Unfortunately, as has already been pointed out many times, tabs break alignment when the tab width is changed.
E.g.
^---void myFunction(int a,
^---^---^---^---^---int b);
becomes
^-void myFunction(int a,
^-^-^-^-^-int b);
when the tab width is changed from 4 to 2.
The only way to fix this with ordinary tabs and spaces is to insist that the number of tabs in a particular block is kept constant and spaces are added for alignment, e.g. (with . representing space)
^---void myFunction(int a,
^---................int b);
The trouble is that the difference between tabs and spaces is invisible and it is completely unrealistic to expect a team of programmers to stick to such an error-prone scheme.
My point is that it is no more considerate to insist on tabs than it is to insist on spaces. Both schemes have disadvantages as has already been stated. My personal view is that it is easier to tolerate an indentation width that differs from your preferred, than broken alignment, so I insist on spaces. Of course that is a value judgement, but it is no less valid than yours.
One of the key things about vi(m)'s keybindings and commands is that they are extremely concise. I defy you to come up with a sane UI which allows the user to say "capitalize all a's, z's and t's that start words but are not followed by a digit, in the following thirteen lines".
Please note that I am not saying that it is easy to learn how to do that.
The point is that usually tabs are used to 'group' lines of code or comments together so they can be understood to be a group. That grouping is semantic, about both the code and the comment. And you are right, at the moment the fact that this done with tabs or spaces or anything else is irrelevant, to both the machine and to the human.
However, it is often done in one specific way, which is easy to use. Hijacking that, and making it both easier to use for the human and more meaningful to the editor would provide an opportunity to solve an argument, and at the same time provide a better coding experience. (Done correctly, of course.) If we can do that, then it might well be worthwhile to do so.
The semantic info is currently in the appearance of the code, when viewed with certain fonts in editors with certain settings. Semi-formalizing the meaning could provide a more robust way to maintain that information, and might have other benefits down the line. (Once it becomes accepted, then editors can use it to do more interesting things with it.)
'Sensible' is a curse word.
Is to do with a couple of things. Partly, my programming roots (low level assembly etc), I see function calling as a cost, so often inline what other people would ship out to functions. With an optimising, a function can be inlined by the compiler, saving on the call/ret overhead, but there are still sometimes other costs to do with passing values, moving stack frame etc, that can be avoided if you don't program in a way that requires it.
If a chunk of code is to be used in various places, then you have other things to way up when deciding whether you want to inline it or not, such as whether caching benefits of having it as a function outway the overhead of having it as a function.
Everything else comes down to code manageability. Functions having their own context is useful for debugging, but if you're on top of your system (esp if you don't have to worry about recursive/reentrant code), you don't need this layer of abstraction. There's also the layout issues of the source code itself; splitting stuff off into functions can make things neater and easier to follow, which is more important when working in a team.
So yes it can be a bad sign, but it can also just be a sign that the programmer thinks in a different way, structures problems/solutions in their mind in a different way, thus expresses it in a different way. Whether this is good or bad depends (relatively) on the outcome, not what's been taught as "correct".
The revolution will not be televised... but it will have a page on Wikipedia
As far as I've come into contact with developers there never has been the slightest doupt what the right thing is. Tabs where introduced as the solution to this very problem. The only problem is that ancient vi and emacs aparently can't deal with them properly. Or their users sometimes are to lazy to set them up properly. The big problem is when experienced professionals follow suit with some blockheads and a few years later themselves insist on everybody using spaces at any time.
Why should everybody degrade the sourcecode because some dick on the team insists on using a 25 year old editor? Why should we be forced to use spaces in interpreted webapp languages because some webserver is to crappy to deal with tabs in the right manner? Unless there's some exotic situation - which I can't think of right now - that requires spaces to be used the stored source should be tabs. Then everyone can decide by himself how wide his indents are without bugging anybody else with his habbits. And if you're to fucking lazy to set up your vi or emacs properly to deal with the problem (either by back and forth conversion of tabs2spaces/spaces2tabs or by altering the display of code) and thus insist on the team following your whim you're nothing but a fucking assh*le. Get with the 3 millenium allready and get yourself a proper editor. There are enough around allready.
This whole discussion reminds me of 5 Million mindless dumb and stubborn outlook idiots establishing fullquote bloat and degrading email to something worse than AOL chat for everybody else, just because their mailer is so crappy.
Bottom line: The solution linked is a solution to a problem that doesn't exist because in a professional enviroment everyone can decide for themselves how their code is displayed, how large tabs are and if they're automatically converted into spaces if I want to use edlin.
P.S.: In the recent years, so I've heard, we even got a new problem popping up: People mixing spaces and tabs in the same sourcefile. Now there's a bunch that deserves to be shot at sight.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
I don't know if this fits the bill, but KATE (KDE Advanced Text Editor) will indent blocks. Actually, it's the embedded editor in the KDE suite (for which KATE is the front end); I use the simpler KWrite and it does the same.
You can highlight a group of lines, and then indent or outdent using Tab or Shift-Tab.
If you want to indent an entire programming structure (such as a if-else structure) without having to specify the start and end of the block, you can use KATE's code-folding feature. It recognizes about sixty types of programming/markup languages based on the filename, and maps out the program structure in the margin (if you turn the feature on). For example, it marks the lines starting with "if {" and ending with "}" as a unit. You can collapse the unit into a single line, much like the outline feature of some editors, and you can highlight and indent the line as described above.
If it seems too protracted, you can always assign the operation to some macro key.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Which old way would that be? Hard tabs or soft tabs? 2, 4, 8 or X spaces wide. How about a mix of hard tabs and spaces?
Yes, that's the old way.
It's official. Most of you are morons.
Correct. By convention, almost all character editors make tab stops by default to be every 8 characters. Therefore any indenting in your code should automatically use tab stops and then use spaces to fill in the white space that doesn't lie on a 8-character boundary. This is what I meant. Thus the whole idea of fudging with the tab stops and using code formatters to replace tabs with spaces is a poor idea, as you imply.
Mmm, I don't think you can reformat brainfuck at will.
Were that I say, pancakes?
I read the article and played his demo. I'm not excited by this at all for 2 reasons: it invents yet another model of tab spacing and it encourages use of tabs.
Tabs just need to go away so we can get back to real debates, like CR vs. CR/LF vs. LF.
The idea is neat, but it does not work so well in practice. He argues tabs have a single semantic meaning, but they'd actually have at least two distinct meanings:
Problem is: it's not always that easy to guess which behavior is the desired without either forcing the programmer to adhere to some new rules involving extra whitespace, or dropping the desired indenting completely.
For instance, the following examples don't work on his editor: (there's a "<TAB>" in there because I couldn't manage to make more than one consecutive space appear in that place)
Would that be some kind of reproduction through whitespace?
Dude, get the net. Spaces already won.
pip??
What does TAB sizes have to do with anything, and especially modern programming?
You might be thinking of indentation, and while there was a time where tabs was used to indent because text-editors couldn't redefine the tab key to indentation width; this time has passed, and there is no reason left to use TABs in programming at all.
Wrong on three counts: make(1), source code management systems and tools like diff and patch, and python source. Make requires a tab to begin a command line. diff will show you and your coworkers all the silly changes you just committed to the repository because you set your editor to convert tabs to spaces. And Python is easily confused when tabs and spaces are mixed.
Slashdot's name? When my compiler sees
I recall somebody here mentioning once that he worked at a place where CVS was setup to automaticly run indent on checkin and checkout. This seemed ideal to me--each coder would get to work in their own preferred style. Then I realized the problems it would cause with certain things. In most of my code, when I return an integer error, I use a macro that munges in a number for the file, a semantic error code (e.g., file not found) and--here's the problem--the __LINE__ directive. The beauty of this system is that since all the integers are compile-time constants, I get a lot of information in my error codes for no more runtime expense than returning something less informative (e.g., -1, or a simple EFOOBAR define).
The downside would be that if such errors were generated by sources compiled by different checkouts, with different styles, then reported errors won't match up on the same __LINE__. This could be resolved by eliminating the __LINE__ from the macro, but then you'd have to come up with a unique ID for each error, manually. That's tedious, miserable work. We could chose to have a single style for *compiling* the source as opposed to editing, but then you are right back to the same problem: there can be only one compiling/debugging style.
I guess, in lieu of __LINE__ I could use a manually enterred "random" number, and use a pre-processing stage to make sure that the number was unique--use the same number in the same file, and CPP fails, but this requires a hack to CPP.
FWIW, I use tabs becaues I figure that "presentation" is the editor's problem. I meant to tab in. If your editor is set to 8 spaces, that's your editor's problem, not mine. What's nasty is when stuff like MSVC converts tabs to spaces during copy-paste operations. My text has tabs in it. COPY-PASTE MY TEXT. DON'T CONVERT IT!!!
Of course then I end up with a "mixed" source code, and I can't tell what's happened unless I actually cursor back. Now, I know all you space guys are saying that if I just used 4 spaces I'd be fine, but then if my source is loaded by somebody who preferrs 2 spaces, or 8 spaces, they are SOL. They are slaved to my editor preference, and that's plainly wrong. In the long run, tabs are the only workable way to solve that problem, because they are, in a sense, "source" whereas spaces are the result you get when the text is "compiled" by the editor.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
That's the editor's problem. Well, the editor and the writer.
I use exclusively tabs for indentation. Then, you can choose to view it in your preferred format. Most people seem to like the equivalent of four spaces for indentation. I prefer two. We can both be happy!
If you're using tabs just for indentation to indicate code blocks then it doesn't really matter if the editor changes it, the code is still perfectly readable. Plus, if you're using a decent editor, you can set the space a tab indicates to whatever you prefer.
Ughhh. If it were so simple everyone could just pipe everything through GNU indent and get everything in the format they want. It isn't so simple.
--
WHO ATE MY BREAKFAST PANTS?
That would totally look like barf in my editor where tabs are 0 spaces.
--
WHO ATE MY BREAKFAST PANTS?
s/shift+i,tab,escape/shift+>/g
"How can you tell whether nobody will use a new standard if it is significantly better than the old one?"
Because it _cant't_ be significantly better no matter what.
Why do you thing there's still a "tab war" (or a "vim vs. emacs war", for that matter)?
It's because there's no "significantly better" alternative (at least not _within_ then proposed choices).
What (maybe) would be significantly better would be the "standardization by itself". But then, each party will insist on standardize on *his* side, not the other, and this is a sure path for no standardization at all.
Hell, even when there is a really obviously better choice (metric vs. imperial) still there is a terribly strong resistance to standardization against customs.
"All tabs and spaces do is make it more pleasant to see the code."
Unless you program Python, of course...
If you use a revision control system, you'll tend to find yourself pursued by mobs of programmers (with scythes, pitchforks and burning torches) for mucking up their diffs.
"It doesn't cost enough, and it makes too much sense."
Yeah, except in the printing industry, where fixed-width fonts are nearly unknown. If you open random printed books, you'll find indents that range from 2 to 6 ens, depending entirely on the whims of the publisher.
The computer industry is a bit weird in its use of fixed-width fonts, which publishers usually find unaesthetic, but which are very useful to us computer geeks. But we do have word processor software that also default to variable-width fonts and indent by distance rather than chars. And CSS lets you define indentation by points or cm or other distance measures.
We should probably face a future in which most software also uses variable-width fonts, and the debate over how many characters to indent will be baffling to most users, because it sounds so nonsensical.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
"herefore any indenting in your code should automatically use tab stops and then use spaces to fill in the white space that doesn't lie on a 8-character boundary"
...will always align properly, no matter how width your tab stop is.
Utterly false!
I defy you to find probes of such an abomination!
Any sensible text editor (and to this point almost *all* text editors seem to be sensible enough) won't use spaces on a tab chain *ever*. A tab means "go to the next tab-stop" and only that. So if tab stops are every 8 chars and you are at column #23 a tab won't add a space, but will move you to column #24. If you are at column #25 it won't add 7 spaces, it just will move to column #32. If you change tab length, due to the fact that tabbing DOESN'T ADD SPACES, your editor will do the correct thing (where spaces added, your editor simply wouldn't know what to do, since it can't know it previous spaces were tab-paddind added or hand-added): it'll just go to "the next tab stop", wherever it currently is (and, by the way, that's the whole problem with spaces vs. tabs: the "inner tabbing", because changing the tab width will "jump" some inner tab stops from one point to the previous/next. All-lefty tabs are never a problem, only inner tabs are, and they can be resolved by using lefty tabs and inner spaces).
So...
(tab)function()
(tab)(tab)sentence(tab)//here a comment
(tab)(tab)longsentece(tab)//another comment
will deal to problems.
But...
(tab)function()
(tab)(tab)sentence()//here a comment
(tab)(tab)longsentece()//another comment
is 1.
I just think we should all use whatever we want. Any IDE worth it's salt can reformat the entire file with a single key combo. Just set up the format you're comfortable with, and when you open a file, have it reformat the file to the way you want to view it.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Now, just imaging a language without braces, and without requisite tabs.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Emacs does this. C-X R K deletes the rectangle between the point and the mark (outdents) C-X R I Inserts a rectangle.
-- Ecks
Before veiwing any text documents, editors should have a optional transformation on startup, ripping away anything that doesn't conform to a users preference. For example, on c source files, the editor could run the text through a source formatter, presenting it to the user exactly the way he/she likes it to be set.
Then, who cares how things really are, we have our preference automatically assured!
This could perhaps be extended to changing between different spellings, I.e. Americanish => English.
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
Think again. Of course you have to enforce a consistant environment for releases; but then you are back to having "one indent to rule them all". I guess you could say that's an incentive for developers to not produce bugs, because if they produce a bug they have to debug it with the release settings, and if they don't like those settings it's more of a hassle. Generally though, we don't want to hassle people.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
> Bottom line: The solution linked is a solution to a problem that doesn't exist because in a professional enviroment everyone can decide for themselves how their code is displayed, how large tabs are and if they're automatically converted into spaces if I want to use edlin.
Really? In almost all professional environments I've known, such things as this are included in the coding standards for the company. IIRC, the width of an indentation has never been the same at any two companies...I always use VIM, and have it replace my tabs with spaces, so it's never been a problem - for me or anyone else (who's following the standards).
Max.
I hope I never have to maintain your code.
-insert a witty something-
Well there has to be some way for slashdotters to reproduce - otherwise they would have evolved out.
On the windows side of things, Visual Studio, by default, has tabs set to a column width of 4 characters. Indent/Unindent multiple lines using standard select+Tab/Shift+Tab. As always, you can go into options and change tabs to whatever you want (8 char column width, 4 spaces, etc.) Quite a non issue. For the record, I use tabs. Column coding is so much easier. Anyone wanna use spaces on my code just do a replace all for to and.. ta da.
I don't want to see the code 'how I prefer'; I want to see all the information that the author of the code was trying to communicate to me. This includes the positioning of text.
http://outcampaign.org/
Source code is a language that allows programmers to communicate both amongst themselves and to the computer. Consistency is desirable for the same reasons that non-lossy communications channels are desirable over lossy ones. If I can see the exact source code that the author of the code saw, then I have a lower probability of making an error in understanding the source code.
http://outcampaign.org/
No it won't. The relative horizontal position of 'myFunction' and 'int' changes with the tab width.
At a company I worked for, the convention was to have "whitespace only" commits, and use those for fixing indentation problems (this was usually done by the QA guys). As for mucking up diffs, depending on the environment, it's not too difficult to get a whitespace-insensitive diff these days. (This is what was done at the aforementioned company.)
http://outcampaign.org/
That's why you want a good text editor. XCode is smart enough to backspace to the previous indent, deleting as many spaces as needed. I don't know about other text editors, I've tryed a bunch of them and always go back to XCode.
By the way anyone knows something better than XCode to edit Jam files ?
Although putting the semantics in the whitespace sounds like a good idea there is a subtle problem - you can see the whitespace. If the tab setting between your editor and the interpreter is different then it can really screw you up. I found this whilst learning Haskell for the first time - made the language a real bitch to learn...
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
I'm totally not seeing the problem that is presented on that PEAR page. Use tabs for identation and spaces for allignment and everyone is happy. The problem is probably editors that automatically change tabs into spaces and vica versa. Which is just as annoying as editors automatically capitalizing words (imagine how annoying that would be in a case sensitive language).
In the examples on the page, everybody can use their own tabsize and everything lines up perfectly.
printf("%s",[tab] is a tab rendered as 5 spaces,
[t] is a tab rendered als 3 spaces,
_ is a space
_______$arg);
[tab]if ($foo &&
[tab]____$bar) {
[tab]}
[t]if ($foo &&
[t]____$bar) {
[t]}
About consistency: If I set my tabsize to 5, then I want all my identation to be, well guess, 5. If pear fixes theirs to 4 it is inconsistent.
I don't think the AC was suggesting that the 'myFunction' and 'int's were ever lined up, but that the 'int's would always line up, regardless of the chosen tab length.
The wonderfully lean and functional editor ConText uses "smart tabs" - the relevant option is active by default.
Note two things:
- it works like Word (i.e. with tabstops defined at certain positions, not with tabs defined as expanding to a certain number of spaces)
- only fixed-width-fonts are available (which is good, since it's a programmer's editor)
Hm, methinks that this was already implemented in typewriters.
Just because Jamie is a famous guy who used to work at netscape, it doesn't mean he's right :D
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
[History lesson]
Typewriters - very early typewriters - had tab stops equivalent to 8 spaces. That was it; no ifs, no buts, no negotiation. Later models had the first tab stop equivalent to 8 spaces, then 2 or 3 adjustable tab stops inside that. Even later ones had the first stop adjustable was well.
Y'see, the TAB key is short for "table" - it was designed to make it easy to print tabulated data.
Notice I was very careful to say "equivalent" above - a TAB is not equal to 8 spaces! Nor is it equal to 2, or 4, or 6, or anything else you want to dream up. It's a character in its own right; one whose most common representation is as a gap the same size as 8 spaces.
Somewhere along the line, people involved with computers decided that TAB was actually a macro that meant "print 8 spaces". This was a departure from accepted philosophy and, like most such schisms, led to the Holy War that is still going on. And, like most Holy Wars, people come up with brain-dead attempts at reconciliation that ignore the cause of the problem.
Ever wonder why a config file like
In short: there are 2 whitespace characters in ASCII - the space, being the equivalent of 1 (average) character wide; and the TAB, being nominally 8 characters, but able to be represented (not replaced!) by whatever you want. Don't confuse them.
What part of "a well regulated militia" do you not understand?
How many characters wide is CowboyNeal, anyway?
Never mind Spamassassin. When's Spammerassassin coming out?
Escher was the first MC and Giger invented the HR department.
Maybe your fear of function calling is related to the fear of global variables prevelent in many languages. Usually because some self-appointed authority said they were "bad".
Like that "Go To Statement Considered Harmful" by Dijkstra, what a prat, what damaged programming he caused.
need a free COBOL editor for Windows?
Me too
The revolution will not be televised... but it will have a page on Wikipedia
It's not a fear, but a cost I avoid unless there are savings that outway that cost. I don't understand this "functions are always the right thing to do, just to save some tab spaces" mentality that goes on here.
As for globals, no I use them a lot... I'm used to the flat, unprotected model, where you make code that doesn't need to be kept in seperate contexts to stop it overwriting what it's not meant to. You make up for it by writing code in a way that it doesn't need that.
In fact, if you look at early intel papers describing protected mode, it's actually described as a debugging tool, as a system without bugs doesn't need hardware protection, and not using the protection mechanisms results in faster code. This is true of many constructs used in code, such as stack frames. If you can write good enough code, you simply don't need them.
The revolution will not be televised... but it will have a page on Wikipedia
My rule of thumb is to try always to break on bracketing delimiters like braces and parens. This means that almost all start-of-line whitespace boils down to indenting:
This generally works best if you're writing in a language that doesn't mind spurious separators on the last element, like the comma on the last parameter in my example. If your language doesn't allow this, you need to make sure to keep the commas/semicolons/whatever right when you add/remove items in the list.
Of course, I don't normally do this for parameter declarations, since unless you've got some really crazy functions they are generally quite short, and it doesn't look so hot when two brackety things end up together:
Some people (or editors) think that tab = a certain number of spaces (which varies)
Some people (or editors) think that tab = skip to the next tab stop (which are spaced every X characters, and X varies).
So we have two issues to address - 1. Does Tab mean a certain number of spaces, or does tab mean to skip to a tab stop? 2. What is the value of X, (which may mean the number of spaces or distance between tab stops, depending on the answer to question 1.)?
Once the editor's managing the tabs cleverly like that, I start to want crazy things like automatic wrapping in comments that respect the comment syntax. Imagine if the comment in ETNotepad's example was considered to be one long string of text and wrapped automatically to however many lines are necessary to avoid the comment running off the screen. This could also be extended to code if people are happy to make some consistent rules about how they wrap. I have some rules of thumb for line-wrapping which I think could be expressed in code, but I've seen some developers that just seem to make it up as they go along.
Whether a makefile is correct depends upon hidden state: whether the rule-indentation is a tab or a sequence of spaces. It took Stu Feldman (the inventor of make) about three months to realize that this was a bad mistake, but at that point he had an active community of eight users, and didn't want to break backwards compatibility.
"My opinions are my own, and I've got *lots* of them!"
Your history lesson is correct - that tab meant to skip to a tab stop. So if you type XYZ{tab}, the tab is equivalent to 5 spaces, where as XY{tab}, it's equivalent to six (assuming a tabstop setting of 8).
My point is that there are two issues: 1. tab stops vs. fixed space insertion are two DIFFERENT approaches (of which various people and editors have certain preferences and implementations), and 2. the length of the space insertion or distance between tab stops varies as well.
You are correct, in my opinion, in saying that tabs are their own character, and it may make sense to preserve that character in the code. Some people use the tab as a shortcut in typing (a navigation shortcut, similar to navigating with the mouse), which is fine, but if they mean spaces, they should either type spaces, or set their editor to convert automatically to spaces (once the line can be decyphered and determined how many spaces the tab is equivalent to, in THIS case.
The good thing about the web, is that 6 year old fuel is just as good as today's, and sometimes it even matures with age...
Here is jwz's not so recent, but totally relevant take on the issue: tabs-vs-spaces> In Vim: Press shift+v to highlight the current line, go to the opening brace, press % to go to the closing brace (highlighting the whole block in turn), then press = to auto-indent.
alternatively: go to opening brace (f{ or $) then =% will indent all lines up to matching brace.
As usual, tabbers emptily claim their behavior is considerate, when it is not.
I can definitely reindent (spaces or tabs), your entire document if I wish to review it differently, but alignment and subtleties will be broken. However, if I receive a tab-indented document I will have no idea how to displaying to view the intended alignment.
Hard tabs in source are wrong.
-josh
IF has THEN ELSE and ENDIF;
SUB has END;
FOR has TO DO and NEXT...
braces are not only {} () []
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Use an editor that increases and decreases indents then - like jEdit.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Usually because some self-appointed authority said they were "bad".
Globals are bad, says me. When you have to debug some 10,000 line piece of garbage where all variables are global (and that generally means 6 letters or less), you'll say so too.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Except it's brain-damaged, and defeats the purpose of tabs.
No, it sidesteps the issue - code will always have the same indenting, no matter what your editor, and you can enforce consistent indenting with the source control.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Declaring something to be simple doesn't make it so. The reality is that tabs/spaces end up being used for horizontal alignment, as well as block indentation. You haven't addressed that at all.
Also, your example of font size is irrelevant, since changing the size of a monospaced font is not a lossy operation.
http://outcampaign.org/
It's not too tough once you learn the basics of substitution and ranges.
--
Promoting critical thinking since 1994.
Heh. I knew that. What I wanted was, rather, that the parent poster show me how that would be doable with "sane" key-bindings and "sane" UI.
I think you meant one of these languages: http://en.wikipedia.org/wiki/Haskell_programming_l anguage, http://en.wikipedia.org/wiki/Forth, http://en.wikipedia.org/wiki/HQ9%2B
Why not fork?
I'm also of the opinion that gotos are mostly bad. Most of the time, there is a better way to rephrase what you would like to say using a conditional or looping construct. Furthermore, proving program correctness (which is done sometimes) is next to impossible using gotos.
I think over the last five years of coding or so, I have used gotos twice in committed code.
What if I don't *WANT* the same level of code indenting? Personal preference is 4 space tabs, linus for example likes 8 spaces. I know some who like only 2 spaces.
Either I
- go through the file and delete all the spaces and replace them with the "Correct" number of spaces (brain damaged) OR
- I set the "tab spacing" in my editor to a sane value and bingo, it's done
It's not a religous issue, it's a fucking "non-issue"....If your code is that fucked that it's not readable/understandable when you change the tab spacing, you've got more serious problems to worry about.
As far as source control goes - all CVS/whatever sees is a tab character. It's expanded when viewed. Non-issue.
Unless you've got a broken text editor that replaces the TAB character with X spaces...
my 2c... (curse words not intended to cause offense, it's simply to illustrate the strength of my feelings on the matter :D)
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Ten. Duh.
R David Francis
In my first job out of college, no one ever argued about tabs vs. spaces because we all just stuck with Visual Studio's default settings.
Personally, I think code intenting is so obvious that I don't understand why we're still arguing about style. Just give me an IDE that indents automatically! I'd rather spend my time getting used to it then counting spaces.
No, I will not work for your startup
Why should I have to hit space 4 or 8 times instead of hitting tab once
Because you're not using Emacs.
What if I don't *WANT* the same level of code indenting?
You either change the tag at the top of the file that says what sort of indents you have or leave them alone. Anything else leaves you open to the BPFH and his many sharp toys.
go through the file and delete all the spaces and replace them with the "Correct" number of spaces (brain damaged) OR
Tell emacs to auto indent with the new settings, duh.
If your code is that fucked that it's not readable/understandable when you change the tab spacing, you've got more serious problems to worry about.
If it varies from fil to file, it's a pain in the ass. This is called living with coworkers.
Unless you've got a broken text editor that replaces the TAB character with X spaces...
With EMACS, all things are possible.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
I want to see all the information that the author of the code was trying to communicate to me. This includes the positioning of text.
Which side of the argument are you coming down on then? Sometimes in my code I'm trying to communicate, "this should be indented to the fifth tab stop," and sometimes I'm trying to communicate, "this number should be over three spaces so the rightmost columns line up." So I have to use both whitespace types in different places.
I suppose the way to convey author presentation is to have him encode his editor settings in the source file. Somebody else here posted a de-facto standard for doing so. Anybody in either "camp" wishing the other one away isn't actually making any progress.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Also, your example of font size is irrelevant, since changing the size of a monospaced font is not a lossy operation.
How about syntax highlighting? I find sometimes that with highlighting a piece of code is easy to understand but with black-on-white text it's hard to tease out the logic or data structures.
So, isn't viewing code written in a highlighting editor in a non-highlighting editor or with other highlighting rules in effect a lossy operation? Do we start embedding highlighting rules in source code then?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The problem with this coding style is:
1. In your really_long_exp you wrap and continue at the beginning. When reading your code it look like the second line is a statement on it's own.
2. In DoSomethingComlex you continue with 1 extra tab for wrapping. This is inconsistent with 1. Also a tab is used to indicate a new 'block' of code.
For 1 & 2 some people prefer to use 2 tabs or some other rules. It is in these cases that using different definitions of TAB can render the code not so readable.
You have it completely backward. Tabs are meant to make things line up. That is their purpose in life.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I am in no way affiliated with Editplus or the company behind it, just a happy user.
I was a editplus happy user, until I found SciTE :)
Works very similar to Editplus, it has per-language configuration, sintax coloring, auto-ident, and a lot more. And the best of all, it's open source.
drmad