Is there a "Large Scale Python Software Design" ?

[Andrew Dalke]

Alex
> "The goal is to silence the compiler" is a common mindset, quite
> understandable given the popular and reasonable shop rule "-Wall, and
> can't be checked in until it given no warnings".  Not exclusive to lazy
> or inexperienced coders.  Still, you do have a point here.

One shop I worked in, in fact my first commercial job, ignored
warnings.  Didn't even try casting.  The framework used void*
function pointers for the three main event handlers, which could
take different argument in certain cases.

My first job was to learn how to build the system.  The second
week I cleaned up the 1,200 or so warnings (judicious use of
unions; didn't need many casts) and found the half dozen actual
errors embedded in those warnings.

I used the term "code mucking" for that case.  As in "stable
mucking" (cleaning out horse manure).  Doing a search now and
it appears that phrase is rarely used, and even less frequently
with that meaning.  Mostly "mucking" is used in the phrasal
verbs "mucking about", "mucking up", or "mucking with".

Huh, and it comes from the Middle English "muk" meaning "dung"
and not as I conjectured a bowdlerized version of a stronger
rhyming expletive.

To any maintenance programmers out there, feel free to use
it as needed.  Perhaps in the retelling of the labors of
Hercules as a programmer he'll use a refactoring browser to
clean the Augean code base.

				Andrew
				dalke at dalkescientific.com