Hacker News Reader

Comment by nusl | Hacker News Reader

OP isn't saying to do all of your work in the terminal; they're saying they prefer CLI-based LLM interfaces. You can have your IDE running alongside it just fine, and the CLIs can often present the changes as diffs in the IDEs too.

View on HN

This is how some folks on my team work. Ran into this when I saved a file manually and the editor ran formatting on it. Turns out that the dev that wrote it only codes via CLI though reviews the files in an IDE so he never manually saved it and ran the formatter.

I expect the formatter/linter to be run as part of presubmit and/or committing the code so it doesn't matter how it's edited and saved by the developer. It's strange to hear of a specific IDE being mandated to work around that, and making quick edits with tools like vi unsupported.

This was with Rider which had its own rules for which we hadn't set up an override in .editorconfig.

allow me to introduce you to the lord and savior, https://pre-commit.com/

Agreed. Also Lefthook: https://github.com/evilmartians/lefthook

and if your pre-commit runs fast (thank you, ruff), you can set this up as a post-edit hook in claude code

I would not recommend this. A hook that modifies files causes Claude to have to re-read the file before modifying it again, which can build up your context window fast

Part of a healthy codebase is ensuring that anyone can hack on it, regardless of their editor setup. Relying on something in .vscode and just assuming people are using that editor is what leads to this kind of situation.

Bake that into the workflow some other way.

Or just enforce that the team all uses the same tools, and you save quite a lot in productivity between making things work on different tools, more so than whatever productivity gains individual devs on the team get from using their own preferred tools. Many teams I know issue everyone MacBooks and enforce VSCode usage, for example, and that has saved so much time compared to other teams I've seen where devs can choose between macOS or Windows for example.

Saves so much time??? Really? You set up a dev env once, how much time is it even possible to save?

No, it's saving time because some things might work on one OS but not another, and then dealing with updates to each OS that might break something, or we need a new piece of software but it doesn't work on Windows for local development, et cetera, et cetera, et cetera. There are so many ways it goes wrong, I speak from personal experience.

Reply on news.ycombinator.com