Date: Thu, 7 Mar 2002 14:31:13 -0700 From: Nate Williams <nate@yogotech.com> To: Mark Murray <mark@grondar.za> Cc: nate@yogotech.com (Nate Williams), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/rwall rwall.c Message-ID: <15495.56353.158608.817241@caddis.yogotech.com> In-Reply-To: <200203072124.g27LOvRV092027@grimreaper.grondar.org> References: <15495.55333.300370.385829@caddis.yogotech.com> <200203072124.g27LOvRV092027@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > There is no clear direction in the above statement, although it has > > > elements of truth from several disparate arguments. > > > > > > "Good reason" == "code rot". > > > > Code can not 'rot'. If it works, it works. All the rest of the > > arguments are based on the invalid assumption. > > I disagree. > > If an API ir function changes, and a program does not have the > information necessary to warn you of any problems that crop up, the > code is said to have rotted. Then the code has changed. It has not rotted. That means whomever changed the code has not done a good job. > If you port code to a compiler or system that is different in some > important way, and the compiler has not enough information to handle > introduced incompatibilities, you have an analagous problem. Then you have a compiler problem, not a code problem. Neither of the above problems are in effect with your recent lint changes. > If FreeBSD was to upgrade the C compiler (Gee, when are we ever > going to do that?), things _will_ change. These things (if problematic > in client code) are usually referred to as code rot if left unfixed > or crudely patched over. See above. The code you are fixing has not changed, and the compiler still produces correct code. You're changing things for the sake of change, and unfortunately introducing both signficant and insignificant bugs in the process. Even worse, the readability of the original code is *lessened* because you're modifying to make automatic tools happy with, rather than the *much* more important (IMO) job of making the code reabable for a person who needs to modify the code at a later point. IMO, the *single* biggest positive to OpenSource programs is the ability to see what's going on. That's what drew me to it 15 years ago, and it seems that people are now spending more time making tools happy, rather than worrying about Real (tm) bugs. (And, for what it's worth, this sort of things happens at work, and I hate it just as much there as I do here...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15495.56353.158608.817241>