Bringing over the markup for monospacing would actually be really nice, yeah. It is irritating that code can't be inlined and requires an unusual input like leading spaces to mark out.
But that's basically hardcoded tabular data, and should really be solved by an editor with proper tab-stops. Not by abusing the monospaceivity and spaces for alignment.
That’s the crux of the issue for me.
I can think of many ways I’d like to present code in my idealised programming language(s) that would use significantly more advanced layout and typography than today’s typical environments.
However, I wouldn’t actually want to use any of them unless my programming tools all supported them properly. That means the editor, but also the source control and diff tools, the code review and bug tracking systems, and so on.
In the absence of any standard conventions for how to represent that extra metadata in an underlying format as robust and flexible as plain text, it’s hard to see this ever happening, though I imagine it would be fun to try.
Indeed, the code formatting style used by Mono (eg spaces before argument parens like "SomeMethod ()") is one of the biggest reasons I'll probably never contribute to it. I can't change the existing style, but it makes my eyes bleed to read, so I avoid it.
I would probably want to hit you with a baseball bat if I had to spend any time reading your code with my monospaced font. At least for the type of code that I work in that lends itself to code alignment.
Given that we can't get developers to agree on where to place { I highly doubt we'd ever be able to settle on more esoteric formatting issues.
I'm also not sure that I want a developer spending much of his brain space or time prettying up the code beyond what is currently considered well formatted code. While it might be nice, there's also probably better things she could be working on.
Ah, that's interesting. In general, yes my proposal does benefit from and assume some IDE/tooling support for quality of life.
Edit: To be specific, the IDE could handle formatting when pasting into a line beginning with """. Or offer a "paste as cool new multiline string syntax" feature.
>Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to.
Because alignment.
>The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really.
Most programmers I know would argue otherwise, including me. Wanna try a poll?
>Variable width text is generally considered easier to read, so why couldn't this also apply to code?
Because it's only considered "easier to read" for general text (books, articles, etc) where you don't need to quickly see anything standing out of the ordinary, and alignment doesn't matter.
Even for traditional uses like accounting, "variable width" is not considered easier to read.
I prefer the middle ground taken by Go and others—have a standard formatter that is part of the language that everyone agrees to use, but don't make that syntactically relevant. That way you get readable code without individual coders ever having to manually fiddle with indentation levels, which is a source of endless problems when copy/pasting.
Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to.
The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really. Variable width text is generally considered easier to read, so why couldn't this also apply to code?
I wish IDEs/text editors enabled code to be rendered and edited in different ways: braces, do/end, whitespace. That could very well be a good way to resolve these disagreements.
I don't know if this is hard in their codebase (although I have a guess), but I have worked on a code formatter before and easy-sounding things were often an unimaginable nightmare.
Most text editors have this understanding anyway. That's how they autoindent code or colour keywords and variables. Yeah I guess I'm just proposing a different common format but in the end I believe it to be slightly better since it solves a few problems.
No, I don't think this will ever happen and it would cause a lot of pain to transition to it. But I just think it's an interesting idea which could have worked had it been done like this from the beginning.
I do find properly aligned code easier to read in general, I'm not willing to give that up.
The crux of the issue is poor tooling. Aligning correctly is a pain because most editors suck terribly at it. For instance neither emacs nor vim align correctly when using tabs by default (they use as many tabs as they can and then pad using spaces, instead of indenting only with tabs and aligning only with spaces). If they did it would be painless to indent and re-indent.
When some of the most venerable code editors out there can't even seem to get it right I think there's no point in fighting it. Learn to stop worrying and love the space, I know I did. Or alternatively use a language like go which provides a standard tool to indent everything, make it mandatory pre-commit and never look back.
This is a good point. Maybe at some distant point in the future we will softly decouple formatting from code by delegating it all to finely tuned autoformatters, or totally decouple it by storing code in a slightly more abstract form such that whitespace rendering becomes largely a presentation preference.
In circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".
> why programmers and code editing software they normally use stuck to the typewriter/punchcard mindset as far as code formatting and the choice of fonts are concerned...
Because computers used to display exclusively in monospaced fonts and coding adapted to that, including use of character position in lines for visual alignment. There've been more recent moves away from that (both elastic tabstops and indent-only-and-never-align are approaches) but they haven't become universal so if you ever deal with code that isn't from a tightly controlled group with practices against position-based-alignment, you are going to run into code that uses it.
reply