3 ms·
Both points aren't possible to do with large codebases. It will take months merely to tidy the code with the effect of making the rest of the team hate you for
by jeremiep 11y ago
Both points aren't possible to do with large codebases.
It will take months merely to tidy the code with the effect of making the rest of the team hate you for committing thousands of files for superficial changes. Its much more productive for everyone to simply adapt to the existing style guidelines.
Reading all of the code is only an option for the smallest of codebases. Reading code will only get you so far before you get lost in the complexity of how all the parts interact with each other.
A better approach would be to limit yourself to a subset of the codebase and start poking around with a debugger while the system is running. Then you can gradually work your way through the codebase starting from the core functionality.
- Mithaldu 11y agoIf i take longer than a week to do it, then other measures are called for, like, as you mention, subsets. However you seem to underestimate just how much functionality can be implemented in how little code with Perl.
- jeremiep 11y agoOh I wasn't talking about Perl specifically but about languages in general. I agree that Perl projects tend to stay small enough to be quickly understood and refactored. In fact I don't remember seeing a Perl script more than a few thousands line long. However, don't underestimate how hard it can be to understand your own Perl code when you've been away from it for 6 months :)
- Mithaldu 11y ago> However, don't underestimate how hard it can be to understand your own Perl code when you've been away from it for 6 months :) For anyone who cares about their craft and has a certain amount of experience with Perl this is entirely untrue. I'd rather people not repeat this tired old meme. :( Thank you! :) vvvv
- jeremiep 11y agoSorry, you're absolutely right, I've seen modern perl and it was actually quite clean. I didn't mean to offend by saying this!