How can I prevent the VBA editor from removing internal whitespace?

Question

I find that aligning identifiers, operators, etc, in my code vastly improves readability. Mistakes just jump off the screen before I ever compile or run the code. However, the VBA editor deletes the extra spaces, destroying my alignment. For example, I try to type a few lines like this:

something         = "a" & CStr(iRow1)  'Colm A = Something useful
somethingElse     = "b" & CStr(iRow1)  'Colm B = Something else
dunno             = "c" & CStr(iRow1)  'Colm C = Don't know what this is
whatEver          = "d" & CStr(iRow1)  'Colm D = whatever you want
aVar              = "e" & CStr(iRow1)  'Colm E = A variable
xOrY              = "f" & CStr(iRow1)  'Colm F = Might be X or Y
aLongVariableName = "g" & CStr(iRow1)  'Colm G = Long variable name

but what I get is this:

something = "a" & CStr(iRow1)                      'Colm A = Something useful
somethingElse = "b" & CStr(iRow1)          'Colm B = Something else
dunno = "c" & CStr(iRow1)                                  'Colm C = Don't know what this is
whatEver = "d" & CStr(iRow1)                         'Colm D = whatever you want
aVar = "e" & CStr(iRow1)                            'Colm E = A variable
xOrY = "f" & CStr(iRow1)                            'Colm F = Might be X or Y
aLongVariableName = "f" & CStr(iRow1)  'Colm G = Long variable name

It is much less readable. Not even the comments are aligned. Note how easy it would be to spot a jRow among the iRow's in the first block compared to the second. And did you notice the error in the last row of the non-aligned code ("f" instead of "g")? Not that easy to spot without the alignment.

So how can I prevent the VBA editor from screwing up my alignment by eating the extra spaces?

Answer 1

The VBE (VBA's IDE) has a soul.

And it eats extraneous whitespace for breakfast.

_{In other words: you can't do that. Whatever you do, extraneous whitespace will get removed automatically.}

---

Fine. Now what?

Change your style!

Naming

If it's hard to tell iRow from jRow, then name your row counters for what they are used for: it shouldn't be too hard to tell playerRow from teamRow.

Comments

If every single variable in your code needs a descriptive comment, perhaps your variable names aren't descriptive enough? Are the comments really useful, or do they merely state the obvious? Do they tell the what more than the why?

Declarations

When a method starts with half a page of local variable declarations, it's a sign that the method might be doing more work than its name says it should be doing; you need to raise the abstraction level and extract functions/procedures. Declaring variables closer to their usage is another way to make code easier to read and to maintain.

Assignments

The same rule as declarations applies here: the assigned value is used somewhere else, perhaps two screens below if you're unlucky.

The point about declaring/assigning closer to usage, is that when you're actually using the variable, it's much easier to spot an error if the assigned value is in your face, rather than having to look it up in an "assignment block" somewhere else - even if that block is all aligned & pretty.

Dim aLongVariableName As String                'declaration
aLongVariableName = "f" & CStr(iRow1)          'assignment
DoSomethingInvolvingColumnG aLongVariableName  'usage