4 ms·
The difference is that code from an existing developer is going to be maintained: that is, the existing developer will stay around to take care of it. Code fro
by DarkShikari 17y ago
The difference is that code from an existing developer is going to be maintained: that is, the existing developer will stay around to take care of it.
Code from an outside developer will just be committed and never touched again in many cases, since the outside developer doesn't intend to stay and work on the project. If you don't believe me, look at the history of the ffmpeg project: there are enormous swaths of unmaintained code (and uncommitted code) for exactly this reason.
Thus, it is often reasonable to have higher code standards for code whose author does not intend to maintain it into the future.
- ErrantX 17y agoGreat unmaintained code is better than a well maintained codebase that features a set of fatal flaws :) These things are relative
- natrius 17y agoThere's no such thing as "great unmaintained code".
- ErrantX 17y agoof course there is... great code that doesnt get refactored. Kick aside corporate jargon and namby-pamby ness :) The point was sometimes stuff just works, much better than a mess of a refactored project that has a core flaw.
- nailer 17y agoGreat code is still subject to entropy. Shit will break. Mail servers will start using some proposed SMTP extension, someone will find a nasty bug or two, there will be security problems and inconsistencies and inefficiencies discovered.
- torr 17y agoSure. Then you simply require hit-and-run commits to be well-commented and also include good docs. Just because it's not currently maintained does not mean it won't be maintained in the future.
- rbanffy 17y agoWhat set of fatal flaws are you talking about?
- ErrantX 17y agohuh? what? the flaws in XYZ piece of code. (I think your misunderstanding: I was replying to the generalisation with a generalisation)