lynx-dev
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]