That “solution” won't help at all. 78 limit is about the client UI and its inability to wrap[1] and the lines still will be longer than 78 chars after decoding. (How and why exactly this matters in 2014 is another story.)
I'm quite familiar with the 78 line break as a Unix user for the last 15 years, but Section 2.1.1 is RFC 2822 should never have been carried forward from RFC 822, where it was originally written decades ago:
- There are many displays less than 78 characters wide.
- There are many displays more than 78 characters wide.
- Most apps that run on displays that are 78 characters wide can happily display paragraphs in their available width.
The IETF is wrong. For that matter, I even wrote a Chrome extension to specifically fix reading IETF papers: https://github.com/mikemaccana/deneckbeard
Ultimately, email should be content only, and display handled on the display device.
Configurable pattern heuristics to help me, as a recipient, optimally render text would be much more welcome than any capability that could be provided to me as a sender.
// Do a thing. This a pretty boring example, but it's here to
// illustrate a point. I've hard wrapped it to fit at some
// arbitrary length
var foo = 'bar'Just accept the other people have different preferences, and tabs and soft word-wrapping enables them to use their preference. If you don't then you're being selfish really.
I completely agree with the soft wrapping of emails though.
Unfortunately, the world is full of people who don't understand this, so when tabs are used, they are used incorrectly (for alignment). Therefore, the one truerest way is (unfortunately) spaces for both indentation and for alignment. I've come to accept this non-ideal solution as a consequence of the wonderful but imperfect nature of Humanity.
That method is broken unless we also agree on a tab width, in which case we may as well use spaces anyway.
[2] http://i5.minus.com/iu14dVi9QRTri.png [3] http://i4.minus.com/itno9LlgJobQD.png
function declaration (most people would accidentally use too many tabs here):
public void severalParameters(String one, int two, String three,
StringObject four, AnotherObject five) {
...
}
String text = "text";
int a = -1;
History.Entry entry = new History.Entry(text);
public void severalParameters(String one, int two, String three,
StringObject four, AnotherObject five) {
// No problems here. It's just like my example.
// We're two levels of indentation in for these comments.
// The argument list continuation was at 1-level indentation with spaces for alignment
}
String text = "text";
int a = -1;
History.Entry entry = new History.Entry(text);As with any coding standard, the point of the rule is to eliminate such sources of lost productivity.
Don't do that. It looks ugly on my tab-indented, proportional font display.
I personally hate aligned assignments. I find it very sloppy. But yes, that is what you would do if you so wanted aligned assignments.
Using only tabs, you cannot do aligned assignments unless you are able to set specific tab stops per line. If you disagree, I can provide an assignment example that breaks tabs. While per-line tab stops might be possible, the overhead of maintaining tab stops vs not using aligned assignments is not worth it.