Yes, we absolutely should rely on that.
Why would programmers, who are basically tool-builders, reject tools that help us write and analyze our programs? This is not the 1970s, and bare-bones text editors are not the only option. Why should we, who build tools for others, restrict ourselves to a self-imposed unreasonable simplicity?
You are free to use Vi or whatever, but don't complain when everyone else uses better tools to improve their productivity, and if the code they write is better suited for those tools that is perfectly fine.
There is no ideal world where we can use tools to write code and it would be perfectly readable for people who don't use those tools.
Embrace the modern ecosystem, or build something better, or take a time machine back to the 1970s where there were no IDEs, source control, or CI/CD. Do you really think that would be better?
This is about decoupling. The same way one should be able to freely pick a VCS and CI/CD system of choice, one should also be free to pick the IDE, or any other system concerned with source code, of choice. Those should remain loosely coupled, and should each be easy to replace. The more requirements you impose on how source code has to be marked up for intelligible display, the more you restrict the choice of tools it can usefully work with, and the more laborious it becomes to create new adequate tools in that field.
Put differently, we should avoid relying on functionality that isn't present in most places where we need to understand code.
Hence, static analysis should be present in many more places than just the IDE. Merge requests, commit diffs, and perhaps code blocks in discussions are prime targets.
I think this might be one case where the CLI is truly limiting us. No opportunity for contexts menus or pop-ups makes presenting the results of static analysis much harder.
I don't know... i'm frequently torn deciding between whether i think this is true or not.
On another note, readability of code is less about coding style and more about familiarity.
Something like this:
let thing: Thing = source.prepare();
let thing = thing.make_iterator();
let (first, second) = thing.split();
let first = first.filter();
let second = second.reverse();
let items: Vec<Item> = first.join(second);
This simplifies debugging too. You can set a breakpoint and view the variables or you can use println!.
Doing so favors writing code over reading code, which is generally the wrong bias. Editor support is appropriate and useful to help writing readable code, but it’s bad for editor support to become a prerequisite for existing code to be comprehensible.