3 ms·

> I've changed the names of things across huge codebases using sed, I've found all instances of things using grep, etc. You're able to change the name of a var

> I've changed the names of things across huge codebases using sed, I've found all instances of things using grep, etc. You're able to change the name of a variable named 'user' without affecting comments or descriptive text about 'the user'? Props to you if you can do all that with grep/sed across, say, a combined PHP/JS project; I wasn't able to do that as easily as I can in IDE-land.

camgunz 3y ago
It's generally a combination of sed, grep, and vim. I don't think I'd be changing 'user'; more like 'user.email' to 'user.email_address'. My steps there generally are: - grep to see how bad the problem is - sed what you can - vim the rest Oftentimes the compiler or tests will bail you out; like just change the field name and fix the errors clang finds. If I don't have that kind of thing I consider adding it. Also while it might take a little longer (though I've used IDE refactoring wizards and it's close), I almost never do it. Could be the kind of thing where like, "changing this would take 10 minutes and be really irritating, so let's take 5 minutes here and nail the name, or establish a convention", which I think leads to better codebases and probably trains you better as an engineer.
- mgkimsal 3y ago
  This seems to ignore situations where you're coming in to any codebase you didn't write from scratch. Naming and conventions are already established - they're bad. Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools. I've had a few interactions with folks who were staunchly "anti IDE" (not saying you are), but was watching a 'director of engineering' give a walk through of their codebase via vim, and was bashing on IDEs. "If you need an IDE, you probably shouldn't work here. You should always be able to know everything about your code, where stuff is, etc. I wrote most of this and it's not that hard". When I brought up that he had a multi-year 'lead' on people new to the codebase, and that IDEs often make it pretty quick to explore and familiarize oneself with new-to-me code... he just 'pffft'-ed that away as 'sounds like more of a you problem' comment. They were also trying to hire, and having a hard time (this was... 10 years ago... so no idea how they're doing now on hiring front).
  - camgunz 3y ago
    (Sorry, just now reading this because I'm bored haha) I guess my first thought here is that Vim has stuff like "go to definition", and depending on your language has had it for quite some time. I do agree there's a kind of toxic "in my day we wrote programs directly on spinning hard disk platters by being very careful with a magnet and tweezers" attitude in places, but I'll bet that for every one of those there's an equal, "I use actual good IDEs and anyone who doesn't leverage them can't possibly be as productive as me", so I think it probably washes out. I don't think you should know everything about your code, the opposite actually. I think you should be able to entirely forget everything about your code when the day ends. I think you should be able to walk onto any codebase and quickly understand how things work having no foreknowledge, as though you'd forgotten everything over night. I don't think this has anything to do with IDEs or editors, but has everything to do with coherent mental models and documentation. Without that stuff, you're just Ctrl-P'ing around, just like w/ IDEs. My manager uses VS Code and whizzes around pretty well. I use Vim and whizz around just as well (arguably better as I don't use go to definition so I'm grepping and guessing where stuff is with... idk very good accuracy). I don't really see a point in arguing about it. > Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools. I hear so much about refactoring and this kind of thing, and it conjures up this image of some sorcerer extracting a pervasive, cancerous hydra from a code's corpus and transmogrifying it into a new, tamed organ. I think a few things about this, but mostly "I frequently have to rename and restructure countless structures/classes and functions/methods across a multi-million line codebase and I need a tool to facilitate that" sounds bonkers to me. It's also hard for me to square that with any kind of testing infrastructure, code review process, or design process. Having to do that kind of thing even once is pretty wild; I can't imagine having to do it so often that I require tooling for it. I can't imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, but I used IntelliJ so don't worry" in the description. I wouldn't even look at it, honestly. Which is to say, I actually think it is rare and generally unsuccessful. I've used refactoring tools and wizards in IDEs. They'll rename fields, change types, update type signatures, generate new getters/setters, etc. That's cool (I don't need it though, because I have Vim and macros)! But that's not really refactoring, that's changing names and types. Refactoring is changing the fundamental representation of the problem space, which means you're changing what different classes/modules are responsible for and how they meet those responsibilities. IDEs won't help you with that, but testing can and it's independent of IDEs or editors. I can imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, took forever to get tests to pass, but now they do" in the description. Not only would I look at it, I would dig in and help refine the approach (or whatever). So again, I think IDEs are fine. I'm sure there are benefits to either side and I'm not super interested in them. I think it's largely an issue of aesthetics. But, again I think you're right that smart people try to make their aesthetic choices "correct" as though they're above irrational personal preferences, but the best thing I can say about that is it's just no fun haha.

camgunz 3y ago

It's generally a combination of sed, grep, and vim. I don't think I'd be changing 'user'; more like 'user.email' to 'user.email_address'. My steps there generally are: - grep to see how bad the problem is - sed what you can - vim the rest Oftentimes the compiler or tests will bail you out; like just change the field name and fix the errors clang finds. If I don't have that kind of thing I consider adding it. Also while it might take a little longer (though I've used IDE refactoring wizards and it's close), I almost never do it. Could be the kind of thing where like, "changing this would take 10 minutes and be really irritating, so let's take 5 minutes here and nail the name, or establish a convention", which I think leads to better codebases and probably trains you better as an engineer.

mgkimsal 3y ago
This seems to ignore situations where you're coming in to any codebase you didn't write from scratch. Naming and conventions are already established - they're bad. Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools. I've had a few interactions with folks who were staunchly "anti IDE" (not saying you are), but was watching a 'director of engineering' give a walk through of their codebase via vim, and was bashing on IDEs. "If you need an IDE, you probably shouldn't work here. You should always be able to know everything about your code, where stuff is, etc. I wrote most of this and it's not that hard". When I brought up that he had a multi-year 'lead' on people new to the codebase, and that IDEs often make it pretty quick to explore and familiarize oneself with new-to-me code... he just 'pffft'-ed that away as 'sounds like more of a you problem' comment. They were also trying to hire, and having a hard time (this was... 10 years ago... so no idea how they're doing now on hiring front).
- camgunz 3y ago
  (Sorry, just now reading this because I'm bored haha) I guess my first thought here is that Vim has stuff like "go to definition", and depending on your language has had it for quite some time. I do agree there's a kind of toxic "in my day we wrote programs directly on spinning hard disk platters by being very careful with a magnet and tweezers" attitude in places, but I'll bet that for every one of those there's an equal, "I use actual good IDEs and anyone who doesn't leverage them can't possibly be as productive as me", so I think it probably washes out. I don't think you should know everything about your code, the opposite actually. I think you should be able to entirely forget everything about your code when the day ends. I think you should be able to walk onto any codebase and quickly understand how things work having no foreknowledge, as though you'd forgotten everything over night. I don't think this has anything to do with IDEs or editors, but has everything to do with coherent mental models and documentation. Without that stuff, you're just Ctrl-P'ing around, just like w/ IDEs. My manager uses VS Code and whizzes around pretty well. I use Vim and whizz around just as well (arguably better as I don't use go to definition so I'm grepping and guessing where stuff is with... idk very good accuracy). I don't really see a point in arguing about it. > Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools. I hear so much about refactoring and this kind of thing, and it conjures up this image of some sorcerer extracting a pervasive, cancerous hydra from a code's corpus and transmogrifying it into a new, tamed organ. I think a few things about this, but mostly "I frequently have to rename and restructure countless structures/classes and functions/methods across a multi-million line codebase and I need a tool to facilitate that" sounds bonkers to me. It's also hard for me to square that with any kind of testing infrastructure, code review process, or design process. Having to do that kind of thing even once is pretty wild; I can't imagine having to do it so often that I require tooling for it. I can't imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, but I used IntelliJ so don't worry" in the description. I wouldn't even look at it, honestly. Which is to say, I actually think it is rare and generally unsuccessful. I've used refactoring tools and wizards in IDEs. They'll rename fields, change types, update type signatures, generate new getters/setters, etc. That's cool (I don't need it though, because I have Vim and macros)! But that's not really refactoring, that's changing names and types. Refactoring is changing the fundamental representation of the problem space, which means you're changing what different classes/modules are responsible for and how they meet those responsibilities. IDEs won't help you with that, but testing can and it's independent of IDEs or editors. I can imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, took forever to get tests to pass, but now they do" in the description. Not only would I look at it, I would dig in and help refine the approach (or whatever). So again, I think IDEs are fine. I'm sure there are benefits to either side and I'm not super interested in them. I think it's largely an issue of aesthetics. But, again I think you're right that smart people try to make their aesthetic choices "correct" as though they're above irrational personal preferences, but the best thing I can say about that is it's just no fun haha.