Sorry to reply so slowly, I read your comment already quite a bit earlier...
So you have these two points, right?
1. Each character is important
2. Lining up things
As a disclaimer, I must say that naturally this is really up to personal taste more than anything.
About 1), I'd say that you are correct, but that depends on the type of thing one is working on. I guess working on some obscure Perl code (that's where I have seen most examples with lots of code that looks like !%&[$tes]) you need to focus much more on single characters than working on for example C++ code with long named variables/function names and mostly calls to them. I am working on the latter, and have found that code like this is easier to read with variable width:
---
TFileName refName;
TXxxYyyInfo* info = iXxx->info->GetPathAndName(refName);
refName.ZeroTerminate();
---
Ok, not too good examples, but maybe you get my point?
2) is something I totally do not care about. I am way too lazy to start lining up anything by hand -- I want my editor to line up my code automatically. And it does a nice job, and I use external tools if I have to work in an environment where I can't select my editor. I don't thins my time should be spent adding spaces.
So to summarize: 1) doesn't seem to matter for me, and if code tends to have many special characters after each other it is probably better to rewrite it for readability anyway. And I don't want to do any lining up by hand anyway.
And descriptive (i.e. quite long) variable names are easier to read with variable width font.
So you have these two points, right?
1. Each character is important
2. Lining up things
As a disclaimer, I must say that naturally this is really up to personal taste more than anything.
About 1), I'd say that you are correct, but that depends on the type of thing one is working on. I guess working on some obscure Perl code (that's where I have seen most examples with lots of code that looks like !%&[$tes]) you need to focus much more on single characters than working on for example C++ code with long named variables/function names and mostly calls to them. I am working on the latter, and have found that code like this is easier to read with variable width:
---
TFileName refName;
TXxxYyyInfo* info = iXxx->info->GetPathAndName(refName);
refName.ZeroTerminate();
---
Ok, not too good examples, but maybe you get my point?
2) is something I totally do not care about. I am way too lazy to start lining up anything by hand -- I want my editor to line up my code automatically. And it does a nice job, and I use external tools if I have to work in an environment where I can't select my editor. I don't thins my time should be spent adding spaces.
So to summarize: 1) doesn't seem to matter for me, and if code tends to have many special characters after each other it is probably better to rewrite it for readability anyway. And I don't want to do any lining up by hand anyway.
And descriptive (i.e. quite long) variable names are easier to read with variable width font.
YMMV.