Tabs
-
Taking off from the tabs vs spaces post few threads below, I was wondering why they were talking about tab = 8 spaces. Does it not make the code unreadable as it is too spaced out? When tab is set to 8 spaces: if (true) { // Indent of 1 tab = 8 spaces if (true) { // some thing here } } When tab is set to 4 spaces: if (true) { // Indent of 1 tab = 4 spaces if (true) { // some thing here } }
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
Yeah, but same as double spacing: it makes it look like you wrote more code!
if (true)
{
// Indent of 1 tab = 8 spaces if (true) { // some thing here }}
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Yeah, but same as double spacing: it makes it look like you wrote more code!
if (true)
{
// Indent of 1 tab = 8 spaces if (true) { // some thing here }}
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Taking off from the tabs vs spaces post few threads below, I was wondering why they were talking about tab = 8 spaces. Does it not make the code unreadable as it is too spaced out? When tab is set to 8 spaces: if (true) { // Indent of 1 tab = 8 spaces if (true) { // some thing here } } When tab is set to 4 spaces: if (true) { // Indent of 1 tab = 4 spaces if (true) { // some thing here } }
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
The 8 space idea was around from the early days of Unix, and the only the terminals were basic teletypes (electric typewriters). I Have never understood why anyone thought that was a good idea on a device that generally could only print 80 characters across the page.
-
Well, we get enough "articles" submitted with ten lines of code spread across two pages that it must be true! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
The 8 space idea was around from the early days of Unix, and the only the terminals were basic teletypes (electric typewriters). I Have never understood why anyone thought that was a good idea on a device that generally could only print 80 characters across the page.
Yes, it is waste of space, I feel. Or was it a mistake:
Australian Dev 1: Keep a tab on it, mate. I am going out for coffee. Non-Australian Dev 1: tab on what? (didn't hear term mate) Australian Dev 1: mate. Non-Australian Dev 1: (again misheard) ah, keep tab on 8. Sure, but it is weird though.
And that caused this mishap.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
-
Taking off from the tabs vs spaces post few threads below, I was wondering why they were talking about tab = 8 spaces. Does it not make the code unreadable as it is too spaced out? When tab is set to 8 spaces: if (true) { // Indent of 1 tab = 8 spaces if (true) { // some thing here } } When tab is set to 4 spaces: if (true) { // Indent of 1 tab = 4 spaces if (true) { // some thing here } }
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
the apparent width of 8 spaces will vary with font, display, screen resolution, app settings, programmer caffeine level, etc. to express typographic design in a device independent way, we have tab, and the relative-proportion glyphs 'em and 'en dashes and spaces, etc. in terms of the long evolution of type in the world of paper and print, typography in IDE's is a johnny-come-lately. before the "rise" of desktop publishing from 1960's onward, very few people had any idea of the aesthetics of type design, letterform/glyph anatomy, leading, kerning, etc. old conventions like paragraph first-line indentation go back to the days of illuminated manuscripts, where a scribe would insert a marker called a pilcrow that a special scribe, a rubucator, would insert an illustration in.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
-
Glad I dont get paid per line of code Years back, I worked with a product that had a limit of 32K lines of code We used a framework that used up 21K of them I spent so much time reducing the number of lines used so we could get all the functionality in Id have ended up paying my employer
-
Yes, it is waste of space, I feel. Or was it a mistake:
Australian Dev 1: Keep a tab on it, mate. I am going out for coffee. Non-Australian Dev 1: tab on what? (didn't hear term mate) Australian Dev 1: mate. Non-Australian Dev 1: (again misheard) ah, keep tab on 8. Sure, but it is weird though.
And that caused this mishap.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
-
Taking off from the tabs vs spaces post few threads below, I was wondering why they were talking about tab = 8 spaces. Does it not make the code unreadable as it is too spaced out? When tab is set to 8 spaces: if (true) { // Indent of 1 tab = 8 spaces if (true) { // some thing here } } When tab is set to 4 spaces: if (true) { // Indent of 1 tab = 4 spaces if (true) { // some thing here } }
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
-
Taking off from the tabs vs spaces post few threads below, I was wondering why they were talking about tab = 8 spaces. Does it not make the code unreadable as it is too spaced out? When tab is set to 8 spaces: if (true) { // Indent of 1 tab = 8 spaces if (true) { // some thing here } } When tab is set to 4 spaces: if (true) { // Indent of 1 tab = 4 spaces if (true) { // some thing here } }
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
lw@zi wrote:
I was wondering why they were talking about tab = 8 spaces.
What do you mean "we" ? For a coding application I set tab at four, or even two. It's a bit font-dependent. As for your code sample, all eyes are different, but for your 4-space tab I'd make it:
if (true) {
// Indent of 1 tab = 4 spaces
if (false) {
// some thing here
} // if(false)
} // if(true)I particularly draw your attention to two three conventions:
- Opening brace on same line as conditional
- Closing brace under begfinning of its conditional
- Comment containing matching conditional clearly identifies the end
The labling of the closing brace is invaluable when you look at the stuff some day further along in history and need to see what's what very quickly (or at least more quickly).
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
The 8 space idea was around from the early days of Unix, and the only the terminals were basic teletypes (electric typewriters). I Have never understood why anyone thought that was a good idea on a device that generally could only print 80 characters across the page.
I'd think that it is older than Unix. In Fortran, cols 1-5 were reserved for labels. Col 6 was for a line continuation marker. You could start your code in col 7, but then the continuation marker would be adjacent to the code, possibly disturbing the reading of the line (if, say, you use digits 1, 2, 3... to mark the order of continuation lines, and the code line starts with a numeric. So you set the tab stop at 8. In the Fortran days, indenting loops was not very common; code was written from pos 8 - the left margin labels were good enough marking of loops. The problem of rightward migration of the source code was not relevant. In those days, it was common to have arbitrary tab stops (like on most old mechanical typewriters). Often, a programming language recommended certain tab stops: If my memory is correct, Fortran (if you used tabs at all!) recommended stops at 8, 14, 20 and then for every 10. On a punched card, there was no way to tell if you had moved out to col 14 using the tab stop or the space bar - either left no hole! When evenly spaced tab stops were getting common, there were some fighting about what comes after 8 - is it 15 (the first tab brought you 7 positions out from the margin, 8 + 7 = 15)? Or is it 16, (counting starts at 0, so n tabs brings you to position 8*n)? Or 17, the first one 8 cols out from the margin, i.e. at pos 9? If Fortran had still been strong, I guess the third alternative (9, 17, 25...) would have been rejected, but it is the most consistent and easiest to handle, so it won. If there had never been any disagreemet about the positions/intervals, causing chaos in line/table layout when moving text files around, maybe tabs would have been popular today. More and more people are rejecting it, both because of the non-standardization and (among software developers) because they came to hate it through makefiles. In modern days the tab key has become common as a navigation key in GUIs, for moving to the next edit field, which further discourages its use as a text input key. Python is actively discouraging tabs. I am happy about it. As an input method, it is fine, as long as it has the semantics of "Space fill up to the next tab position" (rather than inserting a tab character code into the file). I hate it when some tab-loving co-worker edits "my" files, and garbles up some nicely lined up declarations, comments etc. Some garble not only the lines they edit, inserting tab characters, but their editors (don't ask me which one they are using) replace any r
-
I'd think that it is older than Unix. In Fortran, cols 1-5 were reserved for labels. Col 6 was for a line continuation marker. You could start your code in col 7, but then the continuation marker would be adjacent to the code, possibly disturbing the reading of the line (if, say, you use digits 1, 2, 3... to mark the order of continuation lines, and the code line starts with a numeric. So you set the tab stop at 8. In the Fortran days, indenting loops was not very common; code was written from pos 8 - the left margin labels were good enough marking of loops. The problem of rightward migration of the source code was not relevant. In those days, it was common to have arbitrary tab stops (like on most old mechanical typewriters). Often, a programming language recommended certain tab stops: If my memory is correct, Fortran (if you used tabs at all!) recommended stops at 8, 14, 20 and then for every 10. On a punched card, there was no way to tell if you had moved out to col 14 using the tab stop or the space bar - either left no hole! When evenly spaced tab stops were getting common, there were some fighting about what comes after 8 - is it 15 (the first tab brought you 7 positions out from the margin, 8 + 7 = 15)? Or is it 16, (counting starts at 0, so n tabs brings you to position 8*n)? Or 17, the first one 8 cols out from the margin, i.e. at pos 9? If Fortran had still been strong, I guess the third alternative (9, 17, 25...) would have been rejected, but it is the most consistent and easiest to handle, so it won. If there had never been any disagreemet about the positions/intervals, causing chaos in line/table layout when moving text files around, maybe tabs would have been popular today. More and more people are rejecting it, both because of the non-standardization and (among software developers) because they came to hate it through makefiles. In modern days the tab key has become common as a navigation key in GUIs, for moving to the next edit field, which further discourages its use as a text input key. Python is actively discouraging tabs. I am happy about it. As an input method, it is fine, as long as it has the semantics of "Space fill up to the next tab position" (rather than inserting a tab character code into the file). I hate it when some tab-loving co-worker edits "my" files, and garbles up some nicely lined up declarations, comments etc. Some garble not only the lines they edit, inserting tab characters, but their editors (don't ask me which one they are using) replace any r
Quite possibly, although when I was writing Fortran & Cobol, all input was hand written to coding forms and sent to the Data Preparation department, where it would be punched onto Hollerith cards by a team of pretty young girls. And since neither language was free form the issue of tabs never arose as far as I know. Assembler was similarly fixed although by convention the operator field was set at column 11, operands at 21, and comments at 39.
-
lw@zi wrote:
I was wondering why they were talking about tab = 8 spaces.
What do you mean "we" ? For a coding application I set tab at four, or even two. It's a bit font-dependent. As for your code sample, all eyes are different, but for your 4-space tab I'd make it:
if (true) {
// Indent of 1 tab = 4 spaces
if (false) {
// some thing here
} // if(false)
} // if(true)I particularly draw your attention to two three conventions:
- Opening brace on same line as conditional
- Closing brace under begfinning of its conditional
- Comment containing matching conditional clearly identifies the end
The labling of the closing brace is invaluable when you look at the stuff some day further along in history and need to see what's what very quickly (or at least more quickly).
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
I do not see why the inner "if" is indented 2*4 spaces. I think it should line up with the first comment. Small sidetrack: Your style of commenting the end brace to indicate what it terminates can be very helpful in complex code. But what I long back to is the CHILL style: Any block can be labeled (the label applies to the block, not to a point in the code). If you repeat the label after the closing brace, the compiler will check it, giving a compilation error if it doesn't match. You could also break out to any outer block level, referring to the block label. Like
Outerloop: if (true) {
Innerloop: while (moreToDo) {
// some thing here
if (reasonToTerminate) exit Outerloop;
} Innerloop;
} Outerloop;This is far more readable and far safer. Unfortunately, it isn't straightforward to introduce it into the syntax of C class of languages. But as an emergency solution, your comments is a great alternative. Not necessarily for 2-line innermost loops/ifs, but certainly when the loop/if spans a dozen lines or more.
-
lw@zi wrote:
I was wondering why they were talking about tab = 8 spaces.
What do you mean "we" ? For a coding application I set tab at four, or even two. It's a bit font-dependent. As for your code sample, all eyes are different, but for your 4-space tab I'd make it:
if (true) {
// Indent of 1 tab = 4 spaces
if (false) {
// some thing here
} // if(false)
} // if(true)I particularly draw your attention to two three conventions:
- Opening brace on same line as conditional
- Closing brace under begfinning of its conditional
- Comment containing matching conditional clearly identifies the end
The labling of the closing brace is invaluable when you look at the stuff some day further along in history and need to see what's what very quickly (or at least more quickly).
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
W∴ Balboos, GHB wrote:
Opening brace on same line as conditional
Only in Java. C,C++ and C# it goes on the next line under the "i" character. ;P And if you would like to see something truly horrible with braces, take a look at some of @OriginalGriff's code.
-
W∴ Balboos, GHB wrote:
Opening brace on same line as conditional
Only in Java. C,C++ and C# it goes on the next line under the "i" character. ;P And if you would like to see something truly horrible with braces, take a look at some of @OriginalGriff's code.
-
Quite possibly, although when I was writing Fortran & Cobol, all input was hand written to coding forms and sent to the Data Preparation department, where it would be punched onto Hollerith cards by a team of pretty young girls. And since neither language was free form the issue of tabs never arose as far as I know. Assembler was similarly fixed although by convention the operator field was set at column 11, operands at 21, and comments at 39.
I suffered the same problems for my first year at the U. The first run was always to identify they typos that the ladies had made. We had a couple of punches available for making corrections, but there was a sign telling that after punching 8 cards, you had to yield to the next one in line. During my 2nd year, we went from that huge Univac 1110 filling a big hall to three single-rack 16 bit minis, each handling 20 interactive terminals (and they did it well!). The great, expensive Univac had interactive terminals too, reserved for special (mostly post-graduate) projects, running at 300 bps. Although the mini could easily handle 9600 bps lines, we were ordered to reduce the speed to 1200 bps so that the proud Univac would not totally loose its face :-) We (that is, the TAs) had certain authorizations, so as soon as the professors went home for supper, and eager students would work through the night on the minis, we raised the line speed. As you point out, assembler is another language (class) where unevenly spaced tab stops were/are common.
-
I'd think that it is older than Unix. In Fortran, cols 1-5 were reserved for labels. Col 6 was for a line continuation marker. You could start your code in col 7, but then the continuation marker would be adjacent to the code, possibly disturbing the reading of the line (if, say, you use digits 1, 2, 3... to mark the order of continuation lines, and the code line starts with a numeric. So you set the tab stop at 8. In the Fortran days, indenting loops was not very common; code was written from pos 8 - the left margin labels were good enough marking of loops. The problem of rightward migration of the source code was not relevant. In those days, it was common to have arbitrary tab stops (like on most old mechanical typewriters). Often, a programming language recommended certain tab stops: If my memory is correct, Fortran (if you used tabs at all!) recommended stops at 8, 14, 20 and then for every 10. On a punched card, there was no way to tell if you had moved out to col 14 using the tab stop or the space bar - either left no hole! When evenly spaced tab stops were getting common, there were some fighting about what comes after 8 - is it 15 (the first tab brought you 7 positions out from the margin, 8 + 7 = 15)? Or is it 16, (counting starts at 0, so n tabs brings you to position 8*n)? Or 17, the first one 8 cols out from the margin, i.e. at pos 9? If Fortran had still been strong, I guess the third alternative (9, 17, 25...) would have been rejected, but it is the most consistent and easiest to handle, so it won. If there had never been any disagreemet about the positions/intervals, causing chaos in line/table layout when moving text files around, maybe tabs would have been popular today. More and more people are rejecting it, both because of the non-standardization and (among software developers) because they came to hate it through makefiles. In modern days the tab key has become common as a navigation key in GUIs, for moving to the next edit field, which further discourages its use as a text input key. Python is actively discouraging tabs. I am happy about it. As an input method, it is fine, as long as it has the semantics of "Space fill up to the next tab position" (rather than inserting a tab character code into the file). I hate it when some tab-loving co-worker edits "my" files, and garbles up some nicely lined up declarations, comments etc. Some garble not only the lines they edit, inserting tab characters, but their editors (don't ask me which one they are using) replace any r
Member 7989122 wrote:
We did have a pre-commit plugin rejecting commit of files with tab stops, but then there were projects still using classical makefiles, so we had to slack up on that.
Find a plugin that can be configured to have exceptions for makefiles and anything else that's tool generated?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
W∴ Balboos, GHB wrote:
Opening brace on same line as conditional
Only in Java. C,C++ and C# it goes on the next line under the "i" character. ;P And if you would like to see something truly horrible with braces, take a look at some of @OriginalGriff's code.
Richard MacCutchan wrote:
Only in Java.
Also javascript. Who the :elephant: thought magic semicolon insertion by the runtime was a good idea. X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| &
-
I suffered the same problems for my first year at the U. The first run was always to identify they typos that the ladies had made. We had a couple of punches available for making corrections, but there was a sign telling that after punching 8 cards, you had to yield to the next one in line. During my 2nd year, we went from that huge Univac 1110 filling a big hall to three single-rack 16 bit minis, each handling 20 interactive terminals (and they did it well!). The great, expensive Univac had interactive terminals too, reserved for special (mostly post-graduate) projects, running at 300 bps. Although the mini could easily handle 9600 bps lines, we were ordered to reduce the speed to 1200 bps so that the proud Univac would not totally loose its face :-) We (that is, the TAs) had certain authorizations, so as soon as the professors went home for supper, and eager students would work through the night on the minis, we raised the line speed. As you point out, assembler is another language (class) where unevenly spaced tab stops were/are common.
Member 7989122 wrote:
huge Univac 1110
I worked on a number of Univac systems from the 1108 to 2200/800 systems. Most of my time was spent poring over 500 page (printed) memory dumps trying to find bugs in the operating system. But at least it gave me job security. :-D
-
Richard MacCutchan wrote:
C,C++ and C# it goes on the next line under the "i" character.
At least for C++--the others are irrelevant dreck--you are correct, and people should harken to someone so venerable. :)
