Leave in tab form, then when you want to share it, detab it first.
That's backwards.
Or just always use tabs so you don't have to have extra steps every time you share code.
If your web-browser does not allow you to configure how to display tabs, maybe you'll want to change it.
Still, that would not be an issue if you didn't mix those evil spaces.
Also, I tend to use an editor to look at code.
By the way
1 2 3 4 5 6
case BPL:
Branch(
(mState.fNZ & mask)
== 0
);
break;
Why not make a jump table? It'd take up less space and it's probably faster (unless the compiler converts your switch into a jump table, which it probably does; in which case, save yourself (or your compiler) a step).
If your web-browser does not allow you to configure how to display tabs, maybe you'll want to change it.
Still, that would not be an issue if you didn't mix those evil spaces.
Also, I tend to use an editor to look at code.
What would suggest, that you share your code along with instructions about how to set up web browsers, and text editors to properly view it?
The extra step of detabing is as simple as two clicks of a mouse, and retabing is the same.
Why not make a jump table? It'd take up less space and it's probably faster (unless the compiler converts your switch into a jump table, which it probably does; in which case, save yourself (or your compiler) a step).
Because then I'd have to write 80 different functions and build a jump table out of them. That's like 2x the code. Much simpler/shorter/less confusing to put it all in a switch.
/* ADC */
case 0x69: AdRdIm(); ADC(); break;
case 0x65: AdRdZp(); ADC(); break;
case 0x75: AdRdZx(); ADC(); break;
case 0x6D: AdRdAb(); ADC(); break;
case 0x7D: AdRdAx(); ADC(); break;
case 0x79: AdRdAy(); ADC(); break;
case 0x61: AdRdIx(); ADC(); break;
case 0x71: AdRdIy(); ADC(); break;
/* AND */
case 0x29: AdRdIm(); AND(); break;
case 0x25: AdRdZp(); AND(); break;
case 0x35: AdRdZx(); AND(); break;
case 0x2D: AdRdAb(); AND(); break;
case 0x3D: AdRdAx(); AND(); break;
case 0x39: AdRdAy(); AND(); break;
case 0x21: AdRdIx(); AND(); break;
case 0x31: AdRdIy(); AND(); break;
/* ASL */
case 0x0A: Read(mState.PC); ASL(mState.A); break;
case 0x06: AdRWZp( ASL ); break;
case 0x16: AdRWZx( ASL ); break;
case 0x0E: AdRWAb( ASL ); break;
case 0x1E: AdRWAx( ASL ); break;
Keeping each entry on 1 line makes the most sense here.
¿? All the tabs have the same length = 1 tab.
If you have a file that consists of nothing but tabs, then yes that's fine. But since the width of other characters are not measured in "tabs", you're mixing two incompatible measurements which leads to inconsistencies in how it's displayed.
I don't like your spacing.
If it's really that big of a deal, run the code through an auto formatter. That'll change the indentation to whatever you want.
What it won't fix is pretty printing, which tabs permanently screw up.
It's not about me, it's about other people viewing code I wrote, including team mates. Why should I put the burden on them to try and fix how my code looks. And it's not guaranteed that everyone will only use spaces, or only use tabs.
My best bet, to not piss people off, and to keep everything neat and consistent, is to detab.
I kinda hate people that use spaces. You are trying to force me to read the code the way you like to read it. Maybe I like 2 space tabs, with nice condensed source code. It should be my choice. If you use tabs:
The point it, is leaves the choice to the current reader of the code, and if everyone on a project uses tabs, everyone gets the format they are most comfortable with. If, however, there's someone that insists on using '4 spaces', all of a sudden everyone that doesn't view a tab as 4 spaces is stuck with poorly formatted code. Also, it allows easy copy-pasting between projects. If I copy code from a 2-space environment into an 8-space environment, I have to reformat the whole thing, or accept the inconsistency (which is more likely in situations where you are in a hurry to complete something). It's akin to specifying the color of each line of code in the code itself - I don't care if you like bright pink comments, just don't force them on me!
The same argument could be made for brace styles, naming convensions and other coding styles. If you hate people for writing code in a different style than you, then you are not going to get along with very many people.
The difference beteen the tabs vs spaces debate is that spaces actually have a functional advantage: They're displayed consistently. Whereas tabs only have a stylistic advantage.
Actually, there really is no reason to not use tabs for indenting. There, the resizability is nice as it let's people use whatever spacing they feel like.
The real issue is when you start trying to use them to make stuff pretty which the resizability is an issue since you can't know how it will be display.
Maybe was a bit melodramatic :P What is the value of consistency with regard to how whitespace is viewed? If my text editor has a black background, and yours has a white, the code (spaces included) is not being viewed 'consistently'; does that make one of us wrong? Consistency is important in the code such that a single person looking at the code will see the same style no matter which section is being viewed. Consistency is /not/ important when referring to code appearance for different users.
On the other hand, being able to format code how you want (using spaces, I may be switching between one project that uses 4 spaces and another that uses 8, much to my annoyance), the ability to copy/paste from other projects without reformatting, and being able to move 4 spaces with a single right-arrow press (yes, you can use ctrl, but why when a single key press can do the work of 2) are real benefits of using tabs.
The real issue is when you start trying to use them to make stuff pretty which the resizability is an issue since you can't know how it will be display.
This. This is all I've been saying.
The issue with tabs is that they destroy pretty printing. So that's why I prefer spaces. I do a lot of pretty printing.
rollie wrote:
What is the value of consistency with regard to how whitespace is viewed?
Pretty print. I already posted some examples of how tabs screw it up. See my posts on the first page of this thread.
Can't say I'm familiar with pretty print - based on a quick google search, there seem to be a variety of options available to perform this operation. Do a majority of them fail on lines that contain tabs?
EDIT: to clarify, both spaces and tabs are shown identical if you have tabs set to 4 spaces. More or less and it shows up distorted. By default in my browser, tabs on this website look like they're set to 8 spaces.