[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Dead code tactics: call for comments
From: |
Philip Webb |
Subject: |
Re: lynx-dev Dead code tactics: call for comments |
Date: |
Fri, 12 Mar 1999 22:14:52 -0500 (EST) |
990312 John Bley invited comments:
> 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 % ).
>
> 1) "Complete removal." Remove dead files such as HTAAServ.c,
> cut the lines between #if 0 and company, etc.
> This means some elements of "history" might get lost,
> since lynx doesn't have a publicly-readable cvs server.
> PRO: smaller code base, smaller distribution, smaller binary, etc.
> CON: "History loss" unless a source control system is implemented
people have long been grumbling at the size of Lynx source,
both as a big stumbling-block for newcomers
& as a pain to maintain, esp if long-time regulars fall by the way;
already, too few people feel at ease working on the stuff.
so (1) seems the obvious choice,
esp if combined with a permanent archive of what's been removed.
> 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
too much fuss, not enough volunteer time.
> 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
still time-consuming & too many comments can make for more confusion.
> as a relative newcomer to the 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 new coders have an easier time learning
> how to program for lynx and don't waste time patching dead code.
i hope LE & KD will comment on this issue: both may be absent right now.
> Leading me to what I think is a compromise solution
> 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
> "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
this is close to my picture of (1):
the dead code needn't be distributed, merely centrally preserved somewhere.
but better than commenting the on-going source,
preserve the whole present state of things for people to explore if they wish,
while allowing the developing code to take off on its own.
a good point to freeze the historic picture would be 2-8-2rel.1 ,
which would be carefully preserved IN TOTO somewhere safe & public,
while 2-8-3dev.1 would result from (your) patches deleting dead wood,
which would also be carefully preserved for people to see what was changed.
once the deletion patches are made, it's really a simple process.
> 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.
the big objection is the one above:
it's already too big for volunteer programmers to master.
> I think 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 changing the development process
> affects every developer & makes the maintainer's task harder short term.
we don't need a formal project-control mechanism.
the number of people who have contributed to Lynx source since 980101
is probably around 1 dozen & REGULAR contributors less than that:
part of the reason is the intimidating size for anyone new to it.
of course, you are 1 of the dozen (smile).
--
========================,,============================================
SUPPORT ___________//___, Philip Webb : address@hidden
ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies
TRANSIT `-O----------O---' University of Toronto