I also have no autocomplete. I don't want the distractions/popups when writing code and getting into deep focus. When I want to autocomplete a long name, I trigger it by hand using Ctrl+p.
Autocomplete is right on the verge of being a net drain on my productivity and I've turned it off out of pique more than once. It will "randomly"† replace words, and the box obscures text, which greatly pisses me off if I happen to be reading that text.
[†]: Obviously this isn't actually random, it's just hitting a key which tab-completes when I don't expect it to. But it feels random and takes me out of flow.
Syntax highlighting, on the other hand, I was memed into trying to code without it, and I hated it. I suspect, like many things, there are a minority of neurotypes for whom turning it off is better, and a majority who prefer it for good reason.
Oh, I imagine you are using some editor created by the kind of genius that invented autocompletion on space or on enter. Those are at their best when they decide that what you write is just a hint, to be match by proximity instead of literally.
Autocompletion doesn't need to be braindead. Unix terminals have had it for decades, and I have never seen anybody complain.
> Unix terminals have had it for decades, and I have never seen anybody complain.
Probably because you don't see the autocomplete there unless you specifically ask for it. This is a world apart from editors that automatically pop up autocomplete options. Those are an unwelcome distraction.
If Unix shells behaved like that, I'd strenuously object.
I wouldn't go so far as "brain-dead", but it is an annoyance, because I am looking at the screen when I am typing, and the lines below and lines above are context that I can easily retriever without needing to store them in my head.
When the autocomplete window pops up it obscures the context above and below the line I am on, and in turn my context switches instantly from (for example) "Use the results of the previous operation as a parameter to this function" to "what was the name of the variable that I used for 'results' on the previous line? I can no longer see the previous line".
For me, I think, an autocomplete would be best if displayed off to the side, in a consistent spot that never changes. Maybe reserve a small box on the right hand side of the editing window for things that constantly change on every keystroke.
This has the advantage of being able to ignore it, and only switch my gaze (and hence my context) when I actually want to read what it is displaying.
I used more or less a bare vim (not minimal, not neovim) config with no plugins and < 100 lines in my vimrc for about 5 years. Minimal syntax highlighting, zero popups or autocomplete, no jump to definition, etc.
It wasn't intentionally by choice, I remember getting frustrated with some interaction between a couple of plugins and resolved to start from a clean slate and carefully configure and curate my config. The clean slate happened but the subsequent configuration never did. I got used to it pretty quickly and it forced me to keep more of the code base in my mental RAM at any point in time.
That still resulted in quite a bit of hunting around, slower refactors but I was thinking about the code quite a bit more. I finally started using a much more feature rich environment and while I'm glad I did the long stretch without it, I even feel I benefited from it, I don't think I could go back.
For autocompletes specifically I do find the immediate suggestions annoying even when I can type right through them. I have no idea how people work when they have to pause their coding to actively dismiss suggestions either via the mouse or through a keyboard shortcut.
For the time being my autocomplete suggestion window is a key combination to even display for a single instance and no additional actions need to be taken unless I want to accept the suggestion (I can still type right through it). I'm sure everyone's mileage will vary but autocomplete feels significantly more intrusive to me than syntax highlighting.
I disable autocomplete, brace matching, suggestions, hints, and every other feature which pops something up or moves the highlights or causes a flash in the editing pane, because I can't stand the distraction. Opening up a factory-configured installation of VSCode, with all of its automatic helpers turned on, feels about as disorienting and off-putting as browsing the web without an adblocker.
1. I appreciate having instant feedback if I've mistyped the number of closing quotes, brackets, or parenthesis. If everything below line 100 is displayed in the color for strings, I know what mistake I made there.
2. The color is visually appealing to me. I stare at my screen for 8+ hours a day, or more if I'm working on a hobby project. I like it to look pretty. It makes reading code more enjoyable for me.
Both points resonate with me, but I'd push back againt the idea that colored syntax highlighting is neccessary for either. I'm thinking of the Pygments 'bw' theme[1], which denotes strings in italics, and nano-emacs[2], which also manages to do.. a lot with a little (at least aesthetically, ie. idk about code volume or corner cases).
Fair points. Those both highlight syntax with type choices instead of color, so you're still getting a lot of the benefit but in black-and-white.
I think I'm personally more likely to quickly suss the difference between black text and yellow text than between regular and italics, so I wouldn't personally use that approach. I appreciate that there are choices, though!
This is the joy of uniqueness. For me, colour is beyond annoying on text. I loath it, yet would never want your colours removed!
I worked for a guy who thought he was "helping" by barging in and distracting me, whenever he saw me in deep thought. I finally confronted him on it, and he thought this helped the creative process!
OK great! I think through a mega-complex problem, anticipating possible issues with furture use of my code, security issues, or if people use the API wrong, and in barges the guy 70% of the way through a thought process and starts blathering on about something irrelevant.
Sure, I guess ot helps HIM become creative, but it just wastes my time and is highly annoying, and does nothing for me. Except perhaps engender mistakes.
Letting others work as they do best, is pivotal to success.
So please all people who have read this far, colour is great, but also no colour is too.
Except, if we hope for jury nullification in the case of obviously ok crimes like murdering distraction-causers, we should not want to be tried by really hardcore programmer. They know the possibility of null is a bad smell.
This is the answer to so many supposedly objective arguments here. Mistaking innate preferences for an objective benefit. This often comes up regarding different styles of programming languages.
I've come to realize that I like certain programming languages, not entirely because of any objective superiority, but because my brain works a certain way and those languages compliment it. There are languages that I just can't stand that others heartily enjoy. I could make objective arguments with evidence but someone whos brain works entirely different from mine is going to remain unconvinced.
> I worked for a guy who thought he was "helping" by barging in and distracting me, whenever he saw me in deep thought. I finally confronted him on it, and he thought this helped the creative process!
My wife used to do a similar thing.
Since the "deep thought" look is very similar to the "annoyed" look, she thought she'd lighten the mood by sending me funny things to look at and then demand I go look at them, and then she'd get annoyed that I didn't react.
Sorry, honey, I'm juggling a mental model of multiple functions and classes. The Humor module is currently disabled.
Like you, I finally had to set the boundary. When I'm in hyperfocus mode, DO NOT DISTURB unless it's important and can't wait. Don't even ask me if I want something to drink. Your assistance is not needed.
> 1. I appreciate having instant feedback if I've mistyped the number of closing quotes, brackets, or parenthesis. If everything below line 100 is displayed in the color for strings, I know what mistake I made there.
It doesn't have to be all or nothing. There's a spectrum, with darcula on one extreme, and no highlighting at all on the other. You don't have be on either extreme of the spectrum, you can always settle for something in between.
Some of the most enjoyable coding I ever did was 2001-2003, when I wrote C using vim in a black-on-white xterm, with keywords underlined, string literals and comments in gray, number literals in bold ... and nothing else!
Even now, today, I remember more of that code that I wrote then, than anything in the almost 1-million lines since.
Vim can now be configured to use italic for comments, green for string literal, magenta for known format-strings within string literals, red for unknown format-strings within string literals, blue for function calls, etc ad nauseum.
Now I pattern match the colors without even reading the code in detail. I think it's time I tried a mono scheme again.
> I appreciate having instant feedback if I've mistyped the number of closing quotes, brackets, or parenthesis.
This is a syntax error and ought to be highlighted with a red squiggly line or something.
The only essential syntax highlighting is syntax highlighting for (certain types of) comments because otherwise you might easily run into situations where they are impossible to distinguish from actual code.
That is what I am doing. Highlight comments. All else no highlighting. Looks extremely aesthetically pleasing to me
Really interesting and this inspired me to build my own color scheme that focuses on the control flow and is much less of a rainbow than traditional color schemes. For example, function calls, ifs, returns, ... are all white and bold. The rest of the code is less prominent.
Often colour schemes can be there "just" to reaffirm the structure of the code. If I ask one of my friend devs "what does green mean in your editor?" they won't know the answer until they look at the code. In my colour scheme you know that white and bold changes the flow of the code and requires more attention.
Type checking, linters and formatters take care of semantics. Ie. I don't need a string and number colored differently, because type checker will tell me it's not right.
IIRC elvis' hilighting works similarly, I remember that being pretty much the only synhi I've encountered in an editor that I didn't end up turning off with extreme prejudice.
(I find I can skim code more easily when I can think about the structure at different levels - block, function, statement, expression etc. - and I find that for me, syntax hilighting often makes that harder and slower ... but "for me" is definitely load bearing in that statement)
I use "print mode" syntax highlighting which is just bold, italics, and (rarely) underline, or some combination of those. It's a habit I picked up when I had one PI who was severely red-green color blind, and another who had mild yellow-blue issues.
I could never turn it off completely but I do sometimes use the Acme theme during the day (it's too bright in the evening), which highlights just comments, strings, and errors.
You're still asking for "evidence" for something that's purely a personal preference.
I mean, I suppose you could argue that the article states that disabling syntax highlighting made him a better programmer, but asking for evidence that it actually did is silly. It's difficult, if not impossible, to truly measure how good a programmer is.
> I was structuring my source better; I was applying recurring visual patterns
This doesn't actually seem optimal. You lost a source of information so you are changing your coding style to compensate. The other changes mentioned seem positive in isolation, but this one just seems to be compensating.
Agree. You can definitely tell which parts our code base was written in vim, as compared to a full bells-and-whistles editor. I’m sure they can achieve the same in theory, but in practice it turns out the IDE solves a need that the terminal doesn’t quite.
I will prefer to stick with syntax highlighting, thank you. It's to most people's taste, but not everyone's, probably worth trying it both ways to see which category you actually belong to.
I do wish an editor (heh) had added Gary Bernhardt's ideas[†] about multiple sorts of syntax highlighting for different purposes. Specifically, highlighting only variables as to the scope they belong to, another nice one could be highlighting pure and effectful function calls differently. Or highlighting the names of modules/packages/whateverthelanguageuses in distinct colors at the top of the file, then using the same color for every name which came from that package, underlining imports which aren't being used.
I would cycle through such a collection rather frequently, I suspect.
you should set up semantic token highlighting together with highlight on cursor hold for your language of use, former is usually a feature of language server, latter should be out of box behavior in modern ides
not quite what you desire, but certainly better than plain syntax highlight
Syntax highlighting is nice, but it’s gone way overboard with 31 different categories. I’m not as minimalist as the OP, but I leave on just enough to tell if my strings are delimited, notice if variables are misspelled, and make sure I don’t miss a comment. I don’t need the editor to tell me that “if” is a keyword by lighting it up! If I have a philosophy, it’s to put the language in the background and the significance in the foreground.
It is putting the significance in the foreground. An if statement is a semantic part of the language. Highlighting that is calling out that there is a higher level of programming going on there than a sequential list of instructions. No programmer needs the keyword “if” to be highlighted to know what it means.
Also, how does having strings highlighted put significance in the foreground? The only thing it will show you is if you missed a delimiter. It doesn’t call out parts of the program that do something noteworthy.
I don’t “highlight” strings by making them fluorescent green or something. I do put them in a couple of different, same-valued colors so it’s obvious when they aren’t lexing the way I expect (like the variable substitutions aren’t actually substitutions because I forgot to use ` or f”).
I do actually highlight some things; for example, method declarations to make them easier to scan for.
Immediately this sounds wrong to me, because even talking of "re-arranging my code" is something that should be avoided.
Let auto-formatters format. This is especially important in team situations where formatting enforced via editorconfig will keep merge conflicts to a minimum. Even working solo having a forced style will keep code consistent and remove distracting unimportant changes from refactors.
> ...even talking of "re-arranging my code" is something that should be avoided.
Why? I find a well organized code file to be easier to read, e.g. grouped together constants, related declarations, class methods, instance methods etc. And to display those groups in some common order so it's easy to find them. An auto-formatter would have to have deep knowledge of intents to do that automatically.
Sometimes there are situational choices that autoformatters cannot comprehend. I also failed to make formatters follow the style choices I use, they were just not configurable enough.
> Sometimes there are situational choices that autoformatters cannot comprehend.
I haven't stumbled across that. Could you give an example?
> I also failed to make formatters follow the style choices I use, they were just not configurable enough.
That's kind of the whole point. I love, love, love Python's Black formatter. In my opinion, it chose the wrong default for quoting strings (i.e. it re-writes single quotes as double quotes), which irked me until I gave up and accepted it. In return, I no longer have to put up with my coworkers' insane style choices, just as they no longer have to tolerate mine. With a single addition to our CI pipeline, the days of dumb arguments about the "right" way to format our code came to an end.
Some people also said "just accept it" and that's part of why I ditched it. If it can be helped I do not accept it. This is not limited to code formatters, I want to have control over the things I personally use. I want to be comfortable doing my stuff.
You've gotta choose your battles. In all the ways I might want to express myself with a computer, the exact formatting of my code is almost never one of them.
In our code base every “fmt: off” is compensating for a lack of scopes, smaller functions, variables, etc. Instead of cutting down on repetition we have dozens of consecutive lines of repetition. But nicely formatted repetition. Until that inevitable day where you have to change something, and everything breaks because you’re only supposed to change 90 of the 100 almost identical lines.
In 99% of settings I am a big fan of auto-formatting as well, though there are definitely cases where I feel you're better off on your own-- the big example that comes to mind is assembly coding, I think the standard formatting there is very restrictive (since it dates back to the early days of more limited editors) and customized formatting can aid understanding significantly.
An auto-formatter that is designed to work for someone who doesn’t have syntax on seems like it should work for everybody else, too, though, right? The :syntax off coder becomes the canary.
Formatting is only a (small) part of coding style. Out of the given examples, only the first one is something an auto-formatter would solve, and even then only in a limited sense:
Good for you, glad you found some value in it. However, that's a no from me dawg. I'm waaaaay too accustomed to all of the niceties that modern syntax highlighting and LSP provide. I'm so certain that it's a huge step back for me that I won't even try it.
Quite a few people think that until they -do- try it and then find it has its advantages.
I know of a number of people who made the deal with themselves "I'll try it for a week/month and then see what I think" - I think over half went "well, that was interesting" and turned it back on, but a surprising (to me, a no-synhi preferring person who thought I was rarer than that) number switched to either "hilighting only for languages I'm unfamiliar with" or "no hilighting at all."
I don't recall anybody regretting trying the experiment.
(that's not to say you -should- try it, but I do think your certainty that you'd get nothing at all out of doing so may be misplaced)
Wouldn't linters help get the benefits (simpler code) without the drawbacks (of making the code harder to read), and also somewhat enforce the rules you like?
I used to dislike syntax coloring while coding. It's fine for reading/reviewing. Now with great improvements in displays, fonts, and IDE themes, I quite like it. It's subtle enough to be visible if you care and not loud when you don't.
I still don't like color in my command-line terminals though. The only place I regularly use it is for `git log` with a custom formatter.
Maybe it's because I like my terminal font small (lots of reading logs) and colored text isn't as good very small. I also find differing vibrant colors to focus in different perceptual planes adding to eyestrain.
When you have to read a lot of software (staff engineer, architect, etc), code coloring helps immensely with getting a “feel” for a block of code quickly. It’s an indispensable time saver and if you don’t use it, you’ll be outcompeted.
I love coding with syntax highlighting off. The signal from linters or other code analyzers ends up jumping out more when other things aren't highlighted.
I do something similar but with a monochrome theme. Comments are faded, values are highlighted and everything else is in normal color. Makes it very easy to quickly scan the code and understand what's going on, I think the context is less important but easy to see when needed, if it's an int or float is usually obvious simply by looking at the value.
As an old-school guy who can touch type quickly, I absolutely hate autoindent, automatic closing curlies, syntax highlighting, and even particularly the temporary jump to a partly typed search string, highlighted and all, until you cancel the search and zap, you're no longer there.
It is possible to work without all that stuff, and once the habit is formed, it is sticky. I fully understand that most people now are habituated the other way, and plain editing would feel strange.
Of all the features that you have listed, I use only the syntax highlighting. I have never tried to turn it off for longer than a few minutes when it worked.
When it is broken (e.g. wrongly coloring stuff) I sometimes turn it off, but this is usually not long enough to find out if I am really better without the colors.
Turning off the syntax highlighting is still one of the things that I would like to try out some day...
Why do you hate autoindent? Have you seen issues with autoindent while developing? Vim `set autoindent` works well when configured with how you do tabs for a given language (ie `set sw=2 sts=2` for JavaScript)
Habit! My original point, once you're habituated, it's much more natural to type an indent than to delete an automatically generated one because you want to go back one indent level, say for a closing curly brace. This just interferes with the "flow".
I always turn syntax highlighting off, because I find it very distracting and it often makes code harder for me to read, without giving me any meaningful benefit.
81 comments
[ 3.5 ms ] story [ 162 ms ] threadI still highlight trailing spaces in bright red, but otherwise it's (nearly) white text on a black background.
[†]: Obviously this isn't actually random, it's just hitting a key which tab-completes when I don't expect it to. But it feels random and takes me out of flow.
Syntax highlighting, on the other hand, I was memed into trying to code without it, and I hated it. I suspect, like many things, there are a minority of neurotypes for whom turning it off is better, and a majority who prefer it for good reason.
Autocompletion doesn't need to be braindead. Unix terminals have had it for decades, and I have never seen anybody complain.
Probably because you don't see the autocomplete there unless you specifically ask for it. This is a world apart from editors that automatically pop up autocomplete options. Those are an unwelcome distraction.
If Unix shells behaved like that, I'd strenuously object.
I wouldn't go so far as "brain-dead", but it is an annoyance, because I am looking at the screen when I am typing, and the lines below and lines above are context that I can easily retriever without needing to store them in my head.
When the autocomplete window pops up it obscures the context above and below the line I am on, and in turn my context switches instantly from (for example) "Use the results of the previous operation as a parameter to this function" to "what was the name of the variable that I used for 'results' on the previous line? I can no longer see the previous line".
For me, I think, an autocomplete would be best if displayed off to the side, in a consistent spot that never changes. Maybe reserve a small box on the right hand side of the editing window for things that constantly change on every keystroke.
This has the advantage of being able to ignore it, and only switch my gaze (and hence my context) when I actually want to read what it is displaying.
It wasn't intentionally by choice, I remember getting frustrated with some interaction between a couple of plugins and resolved to start from a clean slate and carefully configure and curate my config. The clean slate happened but the subsequent configuration never did. I got used to it pretty quickly and it forced me to keep more of the code base in my mental RAM at any point in time.
That still resulted in quite a bit of hunting around, slower refactors but I was thinking about the code quite a bit more. I finally started using a much more feature rich environment and while I'm glad I did the long stretch without it, I even feel I benefited from it, I don't think I could go back.
For autocompletes specifically I do find the immediate suggestions annoying even when I can type right through them. I have no idea how people work when they have to pause their coding to actively dismiss suggestions either via the mouse or through a keyboard shortcut.
For the time being my autocomplete suggestion window is a key combination to even display for a single instance and no additional actions need to be taken unless I want to accept the suggestion (I can still type right through it). I'm sure everyone's mileage will vary but autocomplete feels significantly more intrusive to me than syntax highlighting.
1. I appreciate having instant feedback if I've mistyped the number of closing quotes, brackets, or parenthesis. If everything below line 100 is displayed in the color for strings, I know what mistake I made there.
2. The color is visually appealing to me. I stare at my screen for 8+ hours a day, or more if I'm working on a hobby project. I like it to look pretty. It makes reading code more enjoyable for me.
1: https://pygments.org/styles/
2: https://github.com/rougier/nano-emacs
I think I'm personally more likely to quickly suss the difference between black text and yellow text than between regular and italics, so I wouldn't personally use that approach. I appreciate that there are choices, though!
This is the joy of uniqueness. For me, colour is beyond annoying on text. I loath it, yet would never want your colours removed!
I worked for a guy who thought he was "helping" by barging in and distracting me, whenever he saw me in deep thought. I finally confronted him on it, and he thought this helped the creative process!
OK great! I think through a mega-complex problem, anticipating possible issues with furture use of my code, security issues, or if people use the API wrong, and in barges the guy 70% of the way through a thought process and starts blathering on about something irrelevant.
Sure, I guess ot helps HIM become creative, but it just wastes my time and is highly annoying, and does nothing for me. Except perhaps engender mistakes.
Letting others work as they do best, is pivotal to success.
So please all people who have read this far, colour is great, but also no colour is too.
And yep. I like color. You don't. I'm glad we both have the options we like!
I've come to realize that I like certain programming languages, not entirely because of any objective superiority, but because my brain works a certain way and those languages compliment it. There are languages that I just can't stand that others heartily enjoy. I could make objective arguments with evidence but someone whos brain works entirely different from mine is going to remain unconvinced.
My wife used to do a similar thing.
Since the "deep thought" look is very similar to the "annoyed" look, she thought she'd lighten the mood by sending me funny things to look at and then demand I go look at them, and then she'd get annoyed that I didn't react.
Sorry, honey, I'm juggling a mental model of multiple functions and classes. The Humor module is currently disabled.
Like you, I finally had to set the boundary. When I'm in hyperfocus mode, DO NOT DISTURB unless it's important and can't wait. Don't even ask me if I want something to drink. Your assistance is not needed.
It doesn't have to be all or nothing. There's a spectrum, with darcula on one extreme, and no highlighting at all on the other. You don't have be on either extreme of the spectrum, you can always settle for something in between.
Some of the most enjoyable coding I ever did was 2001-2003, when I wrote C using vim in a black-on-white xterm, with keywords underlined, string literals and comments in gray, number literals in bold ... and nothing else!
Even now, today, I remember more of that code that I wrote then, than anything in the almost 1-million lines since.
Vim can now be configured to use italic for comments, green for string literal, magenta for known format-strings within string literals, red for unknown format-strings within string literals, blue for function calls, etc ad nauseum.
Now I pattern match the colors without even reading the code in detail. I think it's time I tried a mono scheme again.
This is a syntax error and ought to be highlighted with a red squiggly line or something.
The only essential syntax highlighting is syntax highlighting for (certain types of) comments because otherwise you might easily run into situations where they are impossible to distinguish from actual code.
That is what I am doing. Highlight comments. All else no highlighting. Looks extremely aesthetically pleasing to me
I've heard this argument before and I just can't say that I share the experience.
Often colour schemes can be there "just" to reaffirm the structure of the code. If I ask one of my friend devs "what does green mean in your editor?" they won't know the answer until they look at the code. In my colour scheme you know that white and bold changes the flow of the code and requires more attention.
Type checking, linters and formatters take care of semantics. Ie. I don't need a string and number colored differently, because type checker will tell me it's not right.
I already open sourced the treesitter queries that enable the control flow color schemes in neovim: https://github.com/meznaric/nvim-controlflow-queries
If anyone is interested let me know and I will focus on open sourcing the color scheme this weekend.
(I find I can skim code more easily when I can think about the structure at different levels - block, function, statement, expression etc. - and I find that for me, syntax hilighting often makes that harder and slower ... but "for me" is definitely load bearing in that statement)
https://github.com/helix-editor/helix/wiki/Themes#acme
I really like Alabaster BG, but sadly VS Code lacks support to implement it.
[1]: https://github.com/tonsky/sublime-scheme-alabaster
I mean, I suppose you could argue that the article states that disabling syntax highlighting made him a better programmer, but asking for evidence that it actually did is silly. It's difficult, if not impossible, to truly measure how good a programmer is.
If there was any research on the matter, it wouldn't be "purely a personal preference".
If the author had data about their personal productivity, they would probably have mentioned it in their blog post, no?
This doesn't actually seem optimal. You lost a source of information so you are changing your coding style to compensate. The other changes mentioned seem positive in isolation, but this one just seems to be compensating.
I do wish an editor (heh) had added Gary Bernhardt's ideas[†] about multiple sorts of syntax highlighting for different purposes. Specifically, highlighting only variables as to the scope they belong to, another nice one could be highlighting pure and effectful function calls differently. Or highlighting the names of modules/packages/whateverthelanguageuses in distinct colors at the top of the file, then using the same color for every name which came from that package, underlining imports which aren't being used.
I would cycle through such a collection rather frequently, I suspect.
[†]: https://www.destroyallsoftware.com/talks/a-whole-new-world
not quite what you desire, but certainly better than plain syntax highlight
Also, how does having strings highlighted put significance in the foreground? The only thing it will show you is if you missed a delimiter. It doesn’t call out parts of the program that do something noteworthy.
I do actually highlight some things; for example, method declarations to make them easier to scan for.
Let auto-formatters format. This is especially important in team situations where formatting enforced via editorconfig will keep merge conflicts to a minimum. Even working solo having a forced style will keep code consistent and remove distracting unimportant changes from refactors.
Define a style, have tooling enforce it.
Why? I find a well organized code file to be easier to read, e.g. grouped together constants, related declarations, class methods, instance methods etc. And to display those groups in some common order so it's easy to find them. An auto-formatter would have to have deep knowledge of intents to do that automatically.
I haven't stumbled across that. Could you give an example?
> I also failed to make formatters follow the style choices I use, they were just not configurable enough.
That's kind of the whole point. I love, love, love Python's Black formatter. In my opinion, it chose the wrong default for quoting strings (i.e. it re-writes single quotes as double quotes), which irked me until I gave up and accepted it. In return, I no longer have to put up with my coworkers' insane style choices, just as they no longer have to tolerate mine. With a single addition to our CI pipeline, the days of dumb arguments about the "right" way to format our code came to an end.
I apply zero customization to it.
If rustfmt thinks the code should be formatted some way, so be it.
I have other things to spend my energy on, unrelated to any particular formatting choices.
One thing clang-format ruined for me is when I laid code out in the same indentation as the JSON it was generating.
E.g.
becameSome people also said "just accept it" and that's part of why I ditched it. If it can be helped I do not accept it. This is not limited to code formatters, I want to have control over the things I personally use. I want to be comfortable doing my stuff.
* applying recurring visual patterns
* writing less convoluted statements
* keeping my files short and concise
I agree, but I can't stand it when the formatting is applied while I'm typing. I prefer to run it through a prettifier afterwards as a separate step.
I know of a number of people who made the deal with themselves "I'll try it for a week/month and then see what I think" - I think over half went "well, that was interesting" and turned it back on, but a surprising (to me, a no-synhi preferring person who thought I was rarer than that) number switched to either "hilighting only for languages I'm unfamiliar with" or "no hilighting at all."
I don't recall anybody regretting trying the experiment.
(that's not to say you -should- try it, but I do think your certainty that you'd get nothing at all out of doing so may be misplaced)
Wouldn't linters help get the benefits (simpler code) without the drawbacks (of making the code harder to read), and also somewhat enforce the rules you like?
Comments are probably an obvious choice, the reason for literals are mostly for strings and format strings.
I still don't like color in my command-line terminals though. The only place I regularly use it is for `git log` with a custom formatter.
Maybe it's because I like my terminal font small (lots of reading logs) and colored text isn't as good very small. I also find differing vibrant colors to focus in different perceptual planes adding to eyestrain.
I really can't stand things like italics in my code.
It is possible to work without all that stuff, and once the habit is formed, it is sticky. I fully understand that most people now are habituated the other way, and plain editing would feel strange.
When it is broken (e.g. wrongly coloring stuff) I sometimes turn it off, but this is usually not long enough to find out if I am really better without the colors.
Turning off the syntax highlighting is still one of the things that I would like to try out some day...