3 ms·

Thanks for the reddit thread. Code quality seems to be something I have never really learned. I understand some of the principles of it, but executing them ove

• SwellJoe 18y ago
  One thing I should have specified in my explanation above is that this project has been going on for years. I'm working on a nearly 11 year old codebase. The age of the code makes no difference (actually, it probably does...you probably need to be more respectful of old code, because it probably knows about stuff, like edge cases, that you've long forgotten). You can always gradually improve your code. I get a vague feeling that you're looking for someone to tell you, "A rewrite is just what the doctor ordered!" And, I can assure you that no one with more than passing experience in the field will suggest it (and I note that others have already pointed out good resources on why not...but they mostly boil down to: you'll still hate the code when it's rewritten, and you'll be months or years behind where you would have been had you not rewritten from scratch). The system has gotten so big and bloated over that time. That's what living systems do. If it were useless, it could remain tiny and pretty. But real world systems have ugly problems and sometimes uglier solutions. Your job is to use it as a learning experience. Every time something new is added, require yourself to make adding that new feature easier, and then add it. e.g., if you need to add support for a new data format, take it as an opportunity to abstract out the import/export routines so adding additional data formats is trivial. Once you've abstracted it out, and you have the original data format code working in the new model, then you can add the new data format. If Lispers have one really undeniably great notion, it is that the tools should match the job, so they build the tools for doing the job, and then they do the job with the custom tools. Most languages aren't quite as malleable as Lisp (though Perl, Ruby, and to a somewhat lesser degree, Python, come pretty close on many fronts), but you can still think of your task as being, "What would a library or subroutine look like that would make adding this new data format really easy?" And then you build that library or subroutine rather than jumping right into writing the data format handling code. And, of course, every time you have to touch a file, leave it prettier than you found it. Even if it's just mild improvements. Slow and steady wins the race, and such.
  • chez17 18y ago
    This is what I needed to hear. Thanks for the great advice.