That’s nice, but it just highlights that the coding style isn’t sufficiently intelligible by itself. We can’t and shouldn’t rely on a static analyzer to be active to make code intelligible everywhere code is displayed (pull requests, diffs, ...).

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.

> That’s nice, but it just highlights that the coding style isn’t sufficiently intelligible by itself. We can’t and shouldn’t rely on a static analyzer to be active to make code intelligible everywhere code is displayed (pull requests, diffs, ...).

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.

I’m all for IDEs for writing software, but not as a prerequisite for reading source code, because the latter happens in all kinds of different contexts. E.g. a software like GitLab shouldn’t require an integrated static analyzer for any or all programming languages. That would only increase the barrier to entry for all software that happens to display source code. If source code can’t be read and understood as-is anymore, that just impedes interoperability and universality of tooling.

Surely you must understand that the functionality provided by the tools will impact how the code is written, tested, reviewed, and deployed.

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?

I disagree, because it reduces the freedom of choice and variety of tools available for software development, and increases the dependency on bespoke tooling. Using a more sophisticated word processor shouldn’t reduce the readability of the text produced. If anything, IDE features should be helping to increase the readability of the resulting source code, instead of promoting a coding style that decreases it.

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.

We should reject tools that only help us understand code that we are writing.

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.

> editor support should not become a prerequisite for existing code to be comprehensible.

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.

One way I try to solve that problem in Rust: use repeated `let thing = simple.invocation();`. No need to rename the variable `thing` if not neccessary. Rust allows redefining a variable with the same name. Additionally I sometimes give the thing a type which makes it even more explicit.

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);

Just to give an idea how to make a complicated ritual explicit and simple.

This simplifies debugging too. You can set a breakpoint and view the variables or you can use println!.

oof

This does nothing for when it's a map of string to array of map of string to string. Shape is not meaning, and naming things helps communicate meaning.