4 ms·
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 fin
by nusl 10mo ago
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.
- CharlieDigital 10mo agoThis 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.
- atomicUpdate 10mo agoI 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.
- CharlieDigital 10mo agoThis was with Rider which had its own rules for which we hadn't set up an override in .editorconfig.
- tyre 10mo agoallow me to introduce you to the lord and savior, https://pre-commit.com/ https://pre-commit.com/
- adamcharnock 10mo agoAgreed. Also Lefthook: https://github.com/evilmartians/lefthook https://github.com/evilmartians/lefthook
- robertfw 10mo agoand if your pre-commit runs fast (thank you, ruff), you can set this up as a post-edit hook in claude code
- jswny 10mo agoI 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
- whalesalad 10mo agoPart 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.
- satvikpendem 10mo agoOr 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.
- deleted 10mo ago[deleted]
- wredcoll 10mo agoSaves so much time??? Really? You set up a dev env once, how much time is it even possible to save?
- satvikpendem 10mo agoNo, 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.