3 ms·

Sure. Does it require a specific IDE then? Does it cleanly import, from scratch, with working tests and etc, regardless of whether they're using Eclipse, Intell

Sure. Does it require a specific IDE then? Does it cleanly import, from scratch, with working tests and etc, regardless of whether they're using Eclipse, IntelliJ, Netbeans, etc? Or is there One True IDE? Is that IDE available everywhere you have to touch code? Is it straightforward to integrate it with your CI/CD tools, despite conforming to that IDE convention? Will it continue to cleanly import after you've left the code to rot for a couple of years in production, and then have to come back in to maintain it? Etc. I've been bitten by all of these. Whereas I've gone to projects that were written without all of this, and even without getting the code to even compile locally (because of dependency hell that I didn't want to suffer through if I didn't have to), was able to diagnose and fix issues, because the code was written to be understood with only a text editor.

lotyrin 11y ago
The idea is that you still conform to the convention of the project (Rails, Spring, etc.), not the IDE, and the FOSS CLI tools etc. can still understand the project, but so does the IDE (because it is made to understand the convention, e.g. how the annotations/XML files work, how to get a list of all your Rake tasks). By not sharing IDE project files, not having any IDE-specific machinery in the project, but still expecting CI to be able to run it, being able to theoretically hack on the project and get results (build, test) even with just bash and grep and nano, you get the best of both worlds. Modern IDEs are better at this than they ever used to be. I was really anti-IDE for a long time, but JetBrains' products made it make sense finally.