An example from some lua code I'm working on at the moment:
local hi = buffer:bitfield(4, 4)
local lo = buffer:bitfield(12, 4)
return bit32.bor(bit32.lshift(hi, 4), lo)
local hi = buffer:bitfield(4, 4)
local lo = buffer:bitfield(12, 4)
return bit32.bor(bit32.lshift(hi, 4), lo)
It's not a deal breaker (and the offset is small in this case) but I much prefer the monospaced version. Obviously it might also be "Stockholm syndrome" after decades of coding with a monospaced font, I can't say I've really given proportional fonts their chance.
Also many proportional fonts make it hard to distinguish between Il1 or O0, but I guess you could design a proportional font that doesn't have this issue. What font do you use yourself?
The inability to do vertical alignment outside of the left edge of the line is a bit annoying, but honestly I don't miss it that much. If you have enough code that you really, really need to do that, I find it's a code smell indicating that something likely needs to be broken into smaller pieces anyways.
Another thing I'm considering to adopt from ST is dropping syntax highlighting. If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension. The only thing I'd keep is a slightly lighter colour for comments, as these don't have quite the same status as code. Ideally, I think I'd like to have them deemphasised by moving them off to the margin or something like that, but that requires rather more work than rendering them a lighter colour than the rest of the code.
Interesting. Could you share some of that research and its conclusions?
Of course, there are several possible error sources (unfamiliarity with the colouring scheme for example), and whether this can be transferred to reading code is an open question. But I still think it's important to keep the existence of this kind of research in mind when discussing this kind of question (and also the similar question of mouse-driven interfaces vs. keyboard shortcuts), as it easily devolves into strongly held opinions and arguments along the lines of "it stands to reason that $opinion-held-is-true"
In code, I'm frequently tracing back and forth through a block, looking for specific information in different lines. I think that the coloration helps to provide "landmarks" for non-linear traversal of the code. I'd consider color-free code to be more similar to un-punctuated text, than I would consider colored text to be to colored code.
I've tried to look at code without highlighting and I can't read it because the color gives me additional context (metadata?) about the code.
This is one reason I'm a fan of Douglas Crockford's slightly unorthodox style of always beginning comments in column 0, rather than indenting them along with the code. This helps, to a small extent, in differentiating comments from code. Example: https://github.com/douglascrockford/JSLint/blob/master/jslin...
Ideally, I'd prefer to float them to the right margin (suggesting the Lisp style of line comments starting at column 78 or thereabouts, I guess), but this is an acceptable compromise. At first blush it seems to break the flow of the code a bit too much, but I'd probably get used to it reasonably quickly, especially in conjunction with grey comments and black text.
[1]: https://wiki.haskell.org/Literate_programming [2]: https://ghc.haskell.org/trac/ghc/wiki/LiterateMarkdown
I've dabbled with it and enjoyed it, but I really feel like it needs editor support to feel truly fluent (i.e. being able to preview the formatted version on the fly, being able to collapse the text blocks, etc.).
There's a good-sized category of things that have a bit of an adoption cost that I'm assured is worthwhile, but that I don't see a really solid reason to commit to. Proportional fonts is one of those (for me).
What I would like is a language-aware editor that can visually align assignments, parameters, etc. without touching the actual whitespace characters. You get 1 tab for indentation (if the language allows tabs) and 1 space for alignment, and the editor takes care of the rest. The raw text would still be readable enough and use fewer bytes for people who prefer to code in a monospace terminal over SSH over an acoustic coupler from a phone booth in rural Texas.
I really, really wish this was available in the editor I fight with every day.
When I write code that reads more like long-prose, then I do prefer proportionally-spaced fonts myself. This is generally characterized as code with a low density of variables and constants, and lots of control and data structure manipulation. However, when I write code with lots of objects, I tend to prefer monospaced fonts. This is because my personal aesthetic style is to line up groups of related entities and logic; an IDE that gives a modern example of doing this is Eclipse [1].
For IDEs I have to use for a specific project that don't support such formatting, Emacs makes this easy to re-flow so adding a new variable, shortening or lengthening an existing one is still quick. The impact upon version control is still annoying, though; AST-sensitive merge/diff/version-control can't arrive soon enough for me. Fortunately, my code is not regularly inflicted upon others within a team; when I do have to work within a team, I put up with not carrying out my personal preference and use the code formatter that comes closest to the team's formatting standards before checking in.
I do this because it helps me read my own source code quicker. Blocks of entities and logic related by domain and not intrinsically related through the language itself happen to be easier for me to read when I line up like this.
This all goes back to a phase I went through a long time ago when I tried to figure out how to adopt literate programming in all my own work, within the context of an integrated single-source publishing, version control, testing, training, and problem management environment. In my mind's eye, I imagined all the media and activities surrounding a software product related back to the code in some manner, with the code displayable in different contexts based upon the AST and domain-specific hints, and when I made a change in either, I could see and manage the change in the network of related nodes. So if I change how a GUI behaved, then the parts of the User Guide that reference the old GUI, list of users who logged problems documenting confusion about that part of the GUI, etc. would all be automatically flagged. The User Guide would automatically get updated graphics content available from the GUI testing as soon as the testing data was built, the training material as well, and the users would get a note from the support team when the next version was released, detailing the change. I eventually decided that mountain was one I wasn't going to grind down myself anytime soon, so my code formatting is one of the many small ways I preserve that ideal.
[1] https://stackoverflow.com/questions/13936569/eclipse-auto-al...