[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev Dead code tactics: call for comments
From: |
John Bley |
Subject: |
lynx-dev Dead code tactics: call for comments |
Date: |
Fri, 12 Mar 1999 17:12:14 -0500 (EST) |
I've enumerated several dozen functions which I believe are dead code.
In addition, there are several thousand lines sitting between dead #if
constructions (a wide variety of them). There are code-level features
(such as SHORT_NAMES) that haven't been used in a long time and wouldn't work
anyway with a current source tree since newer code doesn't adhere to them.
Here are five tactics for dealing with the dead code in lynx (which I'd
estimate at about 3%). For each one, of course, I'm omitting the obvious
"except for code that somebody has plans to use/update in the immediate
future" clause.
1) "Complete removal." Remove dead files such as HTAAServ.c, cut the lines
between #if 0 and company, etc. This means that some elements of
"history" might get lost, since lynx doesn't have a publicly-readable
cvs server or something similar.
PRO: smaller code base, smaller distribution, smaller binary, etc.
CON: "History loss" unless a source control system is implemented
2) "Partial removal/partial commenting." On a case-by-case basis, decide
whether the code is interesting enough to save and comment out, or if it
can be tossed without any loss.
PRO: Loss of only meaningless things, smaller binary
CON: Many man-hours and bickering over what to keep/toss
3) "Comment everything." Remove makefile targets for unused files but
leave them in the distribution, comment out all the dead code, leave
stuff that is currently #if 0-ed in place.
PRO: No history loss, smaller binary, only a little time wasted
CON: Distribution actually grows a little bit
I'll point out that, as a relative newcomer to the lynx source tree, I've
been diverted many times by code only to find it was sitting in a #if
0-type construct. A smaller distribution means that new coders have an
easier time learning how to program for lynx and don't waste time
patching dead code. Leading me to what I think is a compromise solution
(unless somebody would be *oh so kind* enough to set up a cvs system for
lynx):
4) "Move it or lose it". Lacking a proper source control system, move
dead code chunks/files to a "deadsrc" directory or something similar,
possibly leaving comments in place pointing out that "X used to be
here but was moved to deadsrc/ on <date>".
PRO: smaller binary, no history loss, not much time wasted, new coders
adapt easily
CON: Distribution grows a little
Personally, I think that the only proper, long-term strategy is to
adopt a source control mechanism so that the project history can be
examined, and then to use (1). But I recognize that I'm only one
developer, and that changing the development process affects every
developer as well as making the maintainer's task harder in the short term.
Of course, there's also the easiest solution of all,
5) "Nop." Do nothing. Who cares about a few K of binary or tarball?
PRO: Easy.
CON: The binary and tar file keep growing.
So, I open the floor to comments. What do we do with the mess of dead
code in lynx?
--
John Bley - address@hidden
Duke '99 - English/Computer Science
Since English is a mess, it maps well onto the problem space,
which is also a mess, which we call reality. - Larry Wall
- lynx-dev Dead code tactics: call for comments,
John Bley <=