Tabs
-
Greg Utas wrote:
dreck
That was a common term when I lived in Manchester, but I have not heard it for years. Is it common in your city/province?
-
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.
Quote:
a team of pretty young girls
You had pretty young girls? Back when I was doing coding sheets they were a team of middle-aged angry women! Try telling that to the kids of today!
- I would love to change the world, but they won’t give me the source code.
-
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
Dan Neely wrote:
Find a plugin that can be configured to have exceptions for makefiles and anything else that's tool generated?
We didn't have to find another tool, just to reconfigure the one we had. But the first decision, to deny tabs from anything that consisted of plain text, has to be revised.
-
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
Then you may know the one-operand infinite loop of 1108 - it didn't even take the whole of an instruction to create an infinite loop. I don't remember all the details of Univac addressing formats, so this description may not be a 100% exact: You could set a bit in the address field for one extra level of indirection - in the location given, you won't find the data, but the address of the data. There you might find another address with the indirection bit set. Any levels of indirection was allowed, all executed as part of the operand value decoding. If you set up one such indirection pointing to itself, you had a single operand version of an unconditional jump to itself. Only that while decoding that indirection, the CPU didn't respond to interrupts. A single-instruction loop could be broken, e.g. by the system operator. The single-operand loop totally locked up the entire CPU; it had to be rebooted - which, for a Univac 1100 system was something more than Ctrl-Alt-Del :-). Most graduate, "responsible" students were aware of this quick way of taking the system down, but everyone tried to keep it secret to the younger, and potentially less responsible, student who might want to "try it out for fun". The U had an old 1108 and a new 1110. I don't think the 1110 went down many times (if at all) from one-operand infinite loops. It could be that Univac had made it interruptible on the 1110, or it could be that my generation of students never did assembly programming on the Univac; we were on our way into the OO world (beliving that Simula would forever be The superhero of OO languages...). Very few of my fellow students ever saw the U1100 instruction set and addressing modes at all.
-
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. C,C++ and C# it goes on the next line under the "i" character
I was speaking in terms of coding professionals and should have made that clearer!
"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.
I think I fixed the (accidental) double indent. As for the use of labels - no compiler differences to worry about if you keep it all in comment form. Maybe it's just me, but have a consistent convention across all of the coding languages is rather helpful at my age.
"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
-
Then you may know the one-operand infinite loop of 1108 - it didn't even take the whole of an instruction to create an infinite loop. I don't remember all the details of Univac addressing formats, so this description may not be a 100% exact: You could set a bit in the address field for one extra level of indirection - in the location given, you won't find the data, but the address of the data. There you might find another address with the indirection bit set. Any levels of indirection was allowed, all executed as part of the operand value decoding. If you set up one such indirection pointing to itself, you had a single operand version of an unconditional jump to itself. Only that while decoding that indirection, the CPU didn't respond to interrupts. A single-instruction loop could be broken, e.g. by the system operator. The single-operand loop totally locked up the entire CPU; it had to be rebooted - which, for a Univac 1100 system was something more than Ctrl-Alt-Del :-). Most graduate, "responsible" students were aware of this quick way of taking the system down, but everyone tried to keep it secret to the younger, and potentially less responsible, student who might want to "try it out for fun". The U had an old 1108 and a new 1110. I don't think the 1110 went down many times (if at all) from one-operand infinite loops. It could be that Univac had made it interruptible on the 1110, or it could be that my generation of students never did assembly programming on the Univac; we were on our way into the OO world (beliving that Simula would forever be The superhero of OO languages...). Very few of my fellow students ever saw the U1100 instruction set and addressing modes at all.
-
Richard MacCutchan wrote:
Only in Java. C,C++ and C# it goes on the next line under the "i" character
I was speaking in terms of coding professionals and should have made that clearer!
"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 think I fixed the (accidental) double indent. As for the use of labels - no compiler differences to worry about if you keep it all in comment form. Maybe it's just me, but have a consistent convention across all of the coding languages is rather helpful at my age.
"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
Certainly a valid argument - in particular when that is your only choice (but of course: Comment syntax varies across languages, and some languages don't even have an explicit block terminator to which you can affix your comment; you have to create a separate comment line, and must explain it by eg. "// end of if (condition)" so that it doesn't look as a commented-out if-statement. And you don't get the compiler check. But if you can't get that, anyway, you certainly haven't lost anything. I fully support you commenting style here. Yet I keep wishing that we had compiler support for it, and a simpler and cleaner syntax. ... Bemoaning what you can't get, begets nothing. Yet, moaning is a sort of self-comforting in hard times.
-
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!
We get paid for article length? :omg:
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
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.
That at least explains why in FORTRAN names were limited to 6 chars (initally): not much room left when you have 8 chars per indentation level! :doh:
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
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
Quote:
Opening brace on same line as conditional
I used to prefer that style, but as I keep introducing more and more self-explanatory variable names, conditions tend to get long, and multiline conditions are not uncommon in my code. And then this happens:
if (my_condition && my_other_condition ||
use_other_condition_flag && other_condition) {
do_something();
}and suddenly the egyptian style didn't seem to be so great anymore! Compare to this:
if (my_condition && my_other_condition ||
use_other_condition_flag && other_condition)
{
do_something();
}Here the actual if code block is much easier to recognize!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Quote:
Opening brace on same line as conditional
I used to prefer that style, but as I keep introducing more and more self-explanatory variable names, conditions tend to get long, and multiline conditions are not uncommon in my code. And then this happens:
if (my_condition && my_other_condition ||
use_other_condition_flag && other_condition) {
do_something();
}and suddenly the egyptian style didn't seem to be so great anymore! Compare to this:
if (my_condition && my_other_condition ||
use_other_condition_flag && other_condition)
{
do_something();
}Here the actual if code block is much easier to recognize!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Except I would have indented the do_something(); It's really all personal eye-candy - I really don't like all of (almost) empty lines breaking things ups - just indented blocks do adequately. For really long conditionals (sometimes it happens) I actually will "format" them, themselves, so as to create a more visually orderly condition - somewhat as you did although possibly more than one per line if they're not complex. Most important of all: consistency to aid in updates, help track bugs, and avoid bugs in the first place. The last seems to always somehow be theoretical.
"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
-
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[^]
-
Dan Neely wrote:
Find a plugin that can be configured to have exceptions for makefiles and anything else that's tool generated?
We didn't have to find another tool, just to reconfigure the one we had. But the first decision, to deny tabs from anything that consisted of plain text, has to be revised.
-
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.
The 8 space tab was around long before UNIX. Manual typewriters had a tab key. It was a means to quickly jump across the page and to line up columns. So for a manual typewriter, the 8 space tab made more sense than a 4 space one. Today, it is like using the floppy icon for the save function. Historically it makes sense, but it is rather obsolete.
-
No, count semicolons.
-
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[^]
Since "way back", I have always used a 4 spaces tab setting on all C (and Perl, C++, etc) languages, 8 spaces tabs or no tabs on everything else. And so did pretty much everyone else in those days.
-
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[^]
I believe the convention goes back typewriters, which may have picked it up from typesetting. Approximately 80 characters per typewritten line on a standard sheet of paper. If you break that into 10 columns (so you can make tables), you start a new column every 8 characters. So when typing a table, you would enter something, hit the tab key which would take you over the "remaining" amount of the 8 characters, then type your next column. If you just hit the tab key, you went over 8 characters to leave that entry in the column blank. Come on people - I'm not the only "old fart" around here. Surely I'm not the only one that learned to type on a typewriter rather than a teletype or PC keyboard!
