I'm not arguing that a modern IDE is superior to vim + ctags, I'm arguing that working with strings rather than symbols is only done by either the naive or the stubborn. I basically have a checklist that I work with new people on:
1. do you have the application working locally (for some context-specific meaning of locally, as this heavily depends on what you're doing);
2. can you run the tests, or at least some meaningful subset of tests;
3. does the source code not report errors (it is INSANE how many juniors will ignore big red squiggly lines from imported libraries which haven't been set up properly);
4. can you attach a debugger;
5. can you navigate the source code (i.e. symbols, go to definition, find usages).
If you can do all this, it doesn't matter if you're using vim or VSCode or JetBrains. The OP of the article failed at least number 5 and probably others as well because they haven't set up their development environment properly and are resorting to string-based tooling to get around that. Trying to enforce nonstandard naming conventions to get around this (per the JavaScript example) shows lack of experience.
I read the original article differently. Writing code in a way that makes it easier to search doesn’t mean not using an IDE, tests, etc. It doesn’t mean not using an LSP or ctags to find symbols. It just adds to the overall consistency and ease of reading and searching the code.
I work with legacy code that very often doesn’t have a development environment or unit tests, often not even version control. Searching the code for strings and symbols (a subset of strings) gets more important in an unfamiliar code base. So does jumping to symbols and debugging, but nothing the OP wrote implies they only use grep
> I read the original article differently. Writing code in a way that makes it easier to search doesn’t mean not using an IDE, tests, etc. It doesn’t mean not using an LSP or ctags to find symbols. It just adds to the overall consistency and ease of reading and searching the code.
Consistent and searchable code is great, but the article author picked awful ways to achieve that. Adding verbosity and nonstandard field names (which will require a bunch of custom linter rules...) to support someone who doesn't have a proper development environment set up is silly. It reminds me of the arguments from 00s Java developers who insisted that having to type out class names on the left, i.e. `EnterpriseBeanFactoryServerImpl foo = new EnterpriseBeanFactoryServerImpl()` made code more readable, but it's really because they didn't have a dev environment with working type inspection set up. It's a real problem, but other than their point about not using dynamically generated identifiers, the author presents totally the wrong solution.
> I work with legacy code that very often doesn’t have a development environment or unit tests, often not even version control. Searching the code for strings and symbols (a subset of strings) gets more important in an unfamiliar code base. So does jumping to symbols and debugging, but nothing the OP wrote implies they only use grep
Very true, but IMO if you're working with legacy code where tests don't run, there's no source control, and you can't get a LSP working, worrying about whether a class is called `SpecificAttributeAlertDialog` or just `Dialog` is plugging holes in the Titanic at that point.
We can agree that some code bases and developer environments seem better than others. We don’t always have control over that.
The OP described naming things consistently so you don’t have Invoice and customer_inv etc. scattered around referring to the same thing. I think most programmers understand that as a good practice. And the OP mentioned the problem with constructing symbols dynamically. I agree with that. Your examples address different problems.
I took issue with your statement about “experienced engineers who are stubborn and refuse to use tools made after 1990 for some reason.” If the tools made after 1990 have clear and measurable advantages, then I would agree that not using them might come from stubbornness. But you didn’t offer any examples of that, or metrics and experiments, just your opinions and preferences. I’m skeptical of such opinions and prescriptions —. the “clean code” type rules presented as scripture without supporting evidence. OP wrote about some practical considerations that make sense to me.
1. do you have the application working locally (for some context-specific meaning of locally, as this heavily depends on what you're doing);
2. can you run the tests, or at least some meaningful subset of tests;
3. does the source code not report errors (it is INSANE how many juniors will ignore big red squiggly lines from imported libraries which haven't been set up properly);
4. can you attach a debugger;
5. can you navigate the source code (i.e. symbols, go to definition, find usages).
If you can do all this, it doesn't matter if you're using vim or VSCode or JetBrains. The OP of the article failed at least number 5 and probably others as well because they haven't set up their development environment properly and are resorting to string-based tooling to get around that. Trying to enforce nonstandard naming conventions to get around this (per the JavaScript example) shows lack of experience.