I am not sure what's your point? Starting a new project from scratch, how to prevent generating legacy code? That would be following best practices, striving for clean code and minimalism, conceiving or using a good software architecture, writing tests right from the start (TDD if possible), naming variables and functions, adding useful comments (like JSDoc), preferring typed languages etc. and last but not least, as you said, documentation!
But maybe you mean how to deal with legacy code when joining an existing project? That's more common and worse in a way, but on the other hand, there is always someone else to blame at least before you have touched most lines of code sooner or later. Again, testing and documentation might help: is there documentation at all? Is it outdated? Does it still contain helpful information? Maybe it helps to understand the original intentions and requirements. Are there tests yet? If there aren't, we can start adding some simple tests while or before proceeding with our work.
Some other considerations: for the sake of consistency, we should probably align our new work with the existing code style and tools, even though they might be outdated from the current point of view. When everything has been written in ES3 JavaScript with spaced brackets and aligned equals signs, that's obviously the project's code style at the moment (and that's still the official WordPress recommendation right now, in 2023, as I found out recently).
And like Jean-Michel said, accepting that we are going to ship more bugs can help us to achieve anything at all.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am not sure what's your point? Starting a new project from scratch, how to prevent generating legacy code? That would be following best practices, striving for clean code and minimalism, conceiving or using a good software architecture, writing tests right from the start (TDD if possible), naming variables and functions, adding useful comments (like JSDoc), preferring typed languages etc. and last but not least, as you said, documentation!
But maybe you mean how to deal with legacy code when joining an existing project? That's more common and worse in a way, but on the other hand, there is always someone else to blame at least before you have touched most lines of code sooner or later. Again, testing and documentation might help: is there documentation at all? Is it outdated? Does it still contain helpful information? Maybe it helps to understand the original intentions and requirements. Are there tests yet? If there aren't, we can start adding some simple tests while or before proceeding with our work.
Some other considerations: for the sake of consistency, we should probably align our new work with the existing code style and tools, even though they might be outdated from the current point of view. When everything has been written in ES3 JavaScript with spaced brackets and aligned equals signs, that's obviously the project's code style at the moment (and that's still the official WordPress recommendation right now, in 2023, as I found out recently).
And like Jean-Michel said, accepting that we are going to ship more bugs can help us to achieve anything at all.