While reading arguments against the use of Tabs, I came across this (source):
...it can be a good idea to avoid tabs alltogether, because the semantics of tabs are not very well-defined in the computer world, and they can be displayed completely differently on different types of systems and editors.
I am relatively new to programming, and have never experienced any issues with tabs in my code, and I've used a number of editors including Notepad++, Programmer's Nodepad, Gedit, Kate, Sublime Text, etc. I may not have done enough coding to get to that point, hence the question:
Can someone please explain, in simple terms, what the quote states? And is the problem with tabs still relevant?
Please note that I am not asking you whether I should use tabs or spaces in my code. I am only after a rational explanation for a specific argument against tabs that I've come across.
I assume you want to see some examples so bellow I've listed some of the most common.
Problem #1: Tab width is not consistent
This is for "displayed completely differently on different types of systems and editors" part.
Even assuming all systems and editors (that your code will be displayed on) agrees on same tab semantics: "move to the right until the current column is a multiple of N", the N is arbitrary.
Historically "standard" for this N is 8 but now most people configure their editors it to be 4 or 2 to "look better".
This is where tab width inconsistency problems come from.
I will use tab widths 2 and 8 in my examples to make differences more visual but same applies to other widths as well.
Indent
Lets say someone is using tab width: 2 in their editor. They see the code like this:
class Foo:
def doSomething(a):
if test(a):
// some nice comment
// about this
bar(a)
Now someone else reads this code in say terminal that uses tab width 8. They see the code like this:
class Foo:
def doSomething(a):
if test(a):
// some nice comment
// about this
bar(a)
That someone may see this as not very pleasant.
Align
So far we have seen inconsistency in indent. But some people like to also align code e.g. assignments, comments.
Again with tab width 2:
class Foo:
def do_something(a):
if test(a):
foo = a.foo // some nice comment
foo_bar = bar(foo) // about this
bar(a)
Again someone else reads this in environment where tab width is 8. Lets say they need to post this snippet to the web and uses <pre> tag. Browsers by default use "standard" tab width 8 and the code looks like this:
class Foo:
def do_something(a):
if test(a):
foo = a.foo // some nice comment
foo_bar = bar(foo) // about this
bar(a)
They can't post it as is. They have to modify the code to replace tabs to spaces.
Line length
Most coding standards define maximum line width.
Lets take max line width 80 for example.
Someone using tab width 2 may see this code completely standard conforming. For them the longest line width is 74 (visible width as opposed to line length in bytes which is 72).
class Foo:
def do_something(a):
// Some very nice comment about code bellow using more then few words.
Someone else using tab width 8 (in a terminal for example) will see the same line as non-conforming because now longest line width is 86:
class Foo:
def do_something(a):
// Some very nice comment about code bellow using more then few words.
Since tab width is inconsistent, line with is now inconsistent too.
Problem #2: Tab is not same thing everywhere
This is for the "semantics of tabs are not very well-defined" part.
So far we assumed that everyone uses tab character as "move to the right until the current column is a multiple of N".
But in some contexts tab character may be used for something a bit different. For example in word processors tab means "move to the the next tab stop", where tab stops are completely arbitrary (and most likely not event the same width).
For example lets say someone is writing a document that uses tab stops:
Now lets say they need to paste some code snippet in it. If code is using tabs, following happens:
They can't leave it as is. They have to modify the code to replace tabs to spaces.
Conclusion
As you can see tabs in different contexts may render code from slightly to completely unreadable.
Spaces have none of the above problems.
I like #Giedrius’ answer (+1), and am going to toss in some vastly over-simplified history just because.
What is a space? It is a blank stretch between letters used to identify words.
How big is a space? It depends on the letters—specifically, on the font. There are thousands of fonts, and they can all be tagged as either proportional or non-proportional. In proportional fonts, character width varies (compare i and M); in non-proportional fonts, character width is always the same (compare i and M). How big is a space? It’s as big as whoever designed the font determined it should be. (Typesetting has been around since Guttenberg, which means the typesetting industry has had a few centuries to figure what works and what doesn’t.)
Skipping a few hundred hears, probably relevant stuff happened that I don’t know about.
Along comes the typewriter (hey kids, ever actually seen one?) These allowed you to type out anything you want to. However, to make it work (totally mechanical, all gears and pulleys, no electricity required, but not cool enough for Steampunk) every character has to be the same width, including the spaces.
Free-form words are all nice and well, but quite frequently people wanted to type up numbers in nicely formatted columns—such as for invoices, where you list items followed by their costs lined up by decimal point with a total at the bottom. (Can you imagine doing that by hand? Congratulations, you just imagined my summer job waaay back when. << Insert Liquid Paper reference here.>>) To make this feasible, someone came up with the TAB key. If you do X on the typewriter, it would remember that “hey, there’s a tab stop here”, and if you hit tab and had not yet reached that column on the row you were typing the print head would jump to that point. How big was it? You guessed it, it depended on what the user needed. (What "X" was totally depended on the typewriter manufacturer.)
Thus and so: no real-world correlation between tabs and spaces, unless there's something obscure from the linotype industry. On typewriters a tab stop would line up with a “regular” character position, whereas on computers there’s no such limitation.
When I wirte the following example code (in VBscript) in Notepad++
dim X
X = Array( "string1", _
"string2", _
"string3" )
Wscript.Echo X(1)
it looks as follows:
As you can see, the three blank lines are inside the code block which one can collapse and uncollapse, which is an annoying behavior. I'd rather have these three lines outside the array group like here, but without REM:
Is there a setting of Notepad++ I am missing to get the desired behaviour?
You can utilized custom language defined settings to make custom fold begin and end objects. This will allow you to insert start and end paramaters within your code so folding done by your configuration.
Here, the language is set to VB and includes the blank spaced lines.
Click on the User Defined Languages Icon(sorry for bad drawing....).
Here, i've saved the user language as Custvbs and applied '{ and '} as my start/end blocks for folding. There is an additional field for secondary folding labelled Folding in code 2 style (seperators needed)
And here is the resulting custom fold:
How about removing the surplus blank lines. You can do this by selecting TextFX -> TextFX Edit -> Delete Surplus Blank Lines
I am parsing a csv file and the file has "\t" characters after every column. Why is it that when I print out the individual lines in terminal or open the file in my text editor that the tab spacing between each of the columns is different?
When you use tab, you're essentially moving to the next tab location, not moving over a specific distance. To see the difference, try using 4 spaces instead of tab. Or, alternatively, run the following code, and I think it may become clear to you.
puts "Hel\tlo world!"
puts "H\tello world!"
puts "Hell\to world!"
Hope that helps.
Do you mean something like
1 1
12345678 1
as a result of
puts "1\t1"
puts "12345678\t1"
A tab jumps to the next position in 8-space steps (8 spaces is a common distance, but it depends on settings of your editor. For ruby often is 2-space distance is used).
If the previous text is longer then 8 characters, then you jump to the next position and you have the impression of different tab spacing.
In Mathematica editor (i.e. notebook), one of the hardest things I always found is when I want to edit some long expression, and go and remove the left end "[" of some expression then before I get the chance to remove the right "]", the code in the cell will get all messed up, since it is no longer balanced, making it really hard to go chase the, now hanging, right end "]" since it is no longer in its original place!
Here is a simple example, suppose we have this
Text[Row[{PaddedForm[currentTime, {6, 3}, NumberSigns -> {"", ""}, NumberPadding -> {"0", "0"}]}]]
now say I wanted to remove the outside Text[] call. So I delete "Text[" and before I get a chance to delete the other side "]", the notebook will now juggle things all over the place, making it hard to find the right "]". For long cell (which is the case for demonestrations work), the code can shift by large amount, and the right "]" can go out of view as well, has to scroll down and up looking for it.
Is there a way to set it, via an option or such, so that when I delete the left "[", Mathematica will automatically delete the matching right "]"? This applies for "(" and ")" as well.
This is really a big problem with the use of the notebook editor for me. Can't tell you how much time I spend just looking the hanging "]".
thanks
--Nasser
I shall think about an automatic method, but I currently handle this with:
place the cursor on the first token inside the function you want to delete (in this case Row)
press Ctrl+. until everything inside is selected (twice, in this case)
Copy
press Ctrl+. once to include the function to delete in the selection
Paste
It is really quite fast once you do it a few times.
Andrew Moylan suggests this mouse variation:
Here is the variant I use for this common operation:
Triple-click "Row", Ctrl+C, Triple-click "Text", Ctrl+V, done
I just registered here and I do not have MMA with me now, so this is just an outline of the proposed solution.
This is my first answer here, so bear with me please.
By the way...nice to see many mathgroupers here too. :-)
Nasser's question/problem is very common.
I personally use the same technique described by Andrew.
It is not difficult however solve this problem more elegantly with a button.
Create a small button palette with an action button.
It would work like this:
you double-click the outermost
function (the one you want to
delete). Since you double-click it
you will select everything up to the
rightmost ].
you click on the action button. The
code in the button will simply get
the selection and extract the
argument within the [] pair, then it
will paste the argument onto the
selection in the notebook. Without
evaluating the argument of course.
That's it. Couple of lines of code.
Since you are at it, you might add a few more buttons to the palette.
For example:
a button to comment/uncommnent a
selection
a button to wrap {} or () to a
selection
a button to wrap fun[] to a
selection (fun can be left selected
so it can later be overwritten with
an appropriate function)
So you end up creating your own programming palette.
If you are deleting a function with only one argument, you can
delete the function name
use (Ctrl + ., Ctrl + .) on the inside function to select its extents
go to the end of that extent and delete the ]
This website also has more information about balancing brackets in Mathematica:
http://reference.wolfram.com/mathematica/howto/BalanceBracketsAndBraces.html
(If you are deleting a function with more than one argument, auto balancing probably doesn't help anyway since you still have to chase the extra arguments.)
I don't know how to do it automatically, but here's a suggestion that can help you keep track of the brackets/parentheses visually and aid you in deleting them manually.
Break up your code into multiple lines, so that each function block opens and closes on a separate line (kinda like C, C++). For e.g., your above code will look like
Text[
Row[{
PaddedForm[
currentTime, {6, 3},
NumberSigns -> {"", ""},
NumberPadding -> {"0", "0"}
]
}]
]
I use this in blocks of code that are longer than a line or so, and especially in plotting, where it's real easy to keep track of the options you supply.
I am answering my own question here.
Using CODE as cell type instead of INPUT solved this issue for me.
closing.
The following will add the keyboard shortcut Shift+Backspace to remove the closest enclosing brackets of the current cursor position. It also adds a menu item to the edit menu.
This function takes the current clipboard content and removes the first and last "word".
cutClipboardBrackets:=Module[{nb},
nb=CreateDocument[{},Visible->False,WindowSelected->False];
NotebookWrite[nb,NotebookGet#ClipboardNotebook[]]
SelectionMove[nb,All,CellContents];
FrontEndExecute[FrontEndToken[nb,"MoveCellBeginning"]]
SelectionMove[nb,All,Word,1];
NotebookDelete[nb];
FrontEndExecute[FrontEndToken[nb,"MoveCellEnd"]];
SelectionMove[nb,All,Word,1];
NotebookDelete[nb];
SelectionMove[nb,All,CellContents];
FrontEndExecute[FrontEndToken[nb,"Copy"]];
];
This can be used to remove brackets, since they are the first and last word when copying FrontEndExecute[FrontEndToken[nb,"Balance"]]. The function that selects, cuts, removes the additional brackets and pastes is:
RemoveBrackets[nb_]:= (
FrontEndExecute[FrontEndToken[nb,"Balance"]];
FrontEndExecute[FrontEndToken[nb,"Cut"]];
cutClipboardBrackets;
FrontEndExecute[FrontEndToken[nb,"Paste"]];
);
Finally we can protect the functions and add a keyboard shortcut (like here):
Protect[cutClipboardBrackets,ClipboardBrackets];
FrontEndExecute[
FrontEnd`AddMenuCommands[
"SelectAll",{Delimiter,MenuItem["Delete Outer Brackets",
FrontEnd`KernelExecute[nb=CreateDocument[Null,Visible->False,WindowSelected->True];
NotebookWrite[nb,Cell[BoxData[RowBox[{"RemoveBrackets[SelectedNotebook[]]"}]],"Input"]];
SelectionMove[nb,Previous,Cell];
SelectionEvaluate[nb];
NotebookClose[nb]],
MenuKey["Backspace",Modifiers->{"Shift"}],System`MenuEvaluator->Automatic]}]]
When I want just one piece of code printed, I can select it, and press the "print" menu command; what follows is a printout of the correct piece of code, but with a highlighted background.
Any tip on how to get a selected piece of code printed as I would see it, unselected?
You can print selection.
Works good on VS2008, without the Background.
My suggestion, if it's only a small fragment (say within a screen size), perform a screencapture and print that.
PS: Print on recycled paper if possible. We need the trees. :P