Ia writer coupon. code#
It stops mattering whether you use tabs or spaces! The code will be just as readable in any font, monospaced or proportional, and it won't matter at all if one dev prefers to render tabs as two spaces and another likes four. > re-teach a generation or two of programmers that indenting with the tab character is good, actuallyīless you for that! This is another advantage of indentation-only formatting. (That may not be the exact rustfmt style, but it's pretty close, and it illustrates the benefit of simple indentation vs. Rewrite_chain_expr( e, total_span, context, max_width, indent ) The Rust team later saw the disadvantages of this kind of column alignment and switched to an indentation-based format fairly similar to Black: Here is a more extreme example from Rust, whose rustfmt tool used to rely heavily on the kind of column alignment you're talking about: Python code formatted with Black is just as readable in a proportional font as in monospaced. It's worth noting that Black, by far the most popular Python formatter, eschews column alignment in favor of a purely indentation-based format. > or any code following the indentation standard where you line up parameters in a multi-line function header with the character after the open parenthesis like you often see in Python. Once I stopped doing this, I realized that the code would look fine in any font, mono or proportional. Maybe it is because of the unnecessary commit diffs that this style produces. Maybe it is because I am getting older and all that sideways visual scanning is not as pleasant as it used to be. Sure, it looks nice to see the "= user.etc" lined up, but does it actually help the readability and maintainability of the code? I used to think so, but I don't any more. You end up doing stuff like this (making up a contrived example, and not in any particular programming language here):ĭriver_license_number = dl_database(user).dl_number I gave up that coding style many years ago, even before I switched to proportional fonts. > Now think of someone doing visual alignment of assignment operators in a block of code like you often see in Ruby Everything in the meat of the comment still lines up just fine in a proportional font, just as it does in monospace. So what if the asterisks in the first boilerplate line don't line up with the ones below? And which of those two asterisks should have lined up with the others? You quickly learn not to care about that. > Put that in a font, and the asterisks on the first line probably won't line up with the rest. We'd need (a) to have editors that support "elastic" or variable tabs to keep things aligned in a truly sane fashion, (b) to re-teach a generation or two of programmers that indenting with the tab character is good, actually, and (c) to develop a few new conventions for what makes code look neat and pretty. Proportional fonts in editors are a good idea whose time probably just hasn't yet come. Speaking of parentheses, can you imagine what will happen with proportional fonts and Lisp indentation? It'd drive the hardiest Emacs user to drink in short order. Now think of someone doing visual alignment of assignment operators in a block of code like you often see in Ruby, or any code following the indentation standard where you line up parameters in a multi-line function header with the character after the open parenthesis like you often see in Python. Put that in a non-proportional font, and the asterisks on the first line probably won't line up with the rest.
except that just about every time I've tried this, I've quickly run into places where trying to use a proportional font creates visual fails.
There was a whole "coding font" family designed around the idea that we should be using proportional fonts for this, and it makes a great case. But it begs the first-principals question- why code using a monospace font? Today, every major editor that isn't terminal-based supports proportional width fonts beautifully.
0 kommentar(er)
