I've been working (part-time) on an existing Rails application for the last
month or so, getting comfortable with it, modifying some sections to
support needed functionality, and beginning an all-out, carpet-bombing
"shock and awe" assault on it's test suite. However, a significant portion
of the system is (or rather was, since I've already gutted a lot of it) a
chunk of rather messy and unpleasant auto-generated code.
I've always been a bit iffy about code generation tools, ever since my
first encounters with them whilst working on some $DEITY-awful access
application years ago. (First encounters with
anything Microsoft
usually have that effect on me, though). Since then, I've never found any
reason to change my mind, and dealing with this particular chunk of
auto-generated code has pushed me over the edge into "wild-eyed extremist"
territory.
Please note that when I say "code generator", I'm talking here about
programs or wizards or whatever that create a block of code that you're
then expected to tweak to suit your conditions. If it's just a mechanical
transformation of an input format to an output format, where a human is
never expected to maintain the output by hand, that's not code generation
in my book -- that's just a compiler being used for it's intended purpose.
I like compilers. I'm fairly sure you do too. Code generators, though?
EVIL.
Consider what you get out of your generator: A big blob of code in your
application that you then have to understand and maintain. It's like you
gave a commit bit to some random person who dropped a 5000 line change into
your tree and then ran away into the night, cackling.
If there's bugs in the generated code (and remember, there's
always bugs in software), when they get fixed upstream you're up
the creek unless you haven't modified the code at all (and thus can
regenerate), or you're willing to apply the necessary patches to your
modified version, often by hand. Hand-patching is error-prone, and if
you've modified the code at the same place that has to be patched, things
can get unpleasant.
In the case of the generator I'm dealing with at the moment, I'm not even
blessed with it being decent code. It's ugly code, in every possible sense
of the word. There's inconsistent formatting, poor commenting, it uses
some totally whack coding constructs[
1], the hard-coded text strings are
ungrammatical, it's got very few (and poorly covering) test cases, the
methods are huge and unwieldy, and it's got security bugs (not so hot for
something that's supposed to be guarding your application). In short, it
looks like some quick-and-dirty internal hack that escaped one night and is
now wreaking havoc on the world.
There's probably some really good code generators out there. I've been
poking around a bit, and there's some written for Rails by people who I
know produce good code. However, no matter how good the author of the code
generator is, the very best you can hope for is solid, clean code that is
the equivalent of some portion of your application having been coded by
some member of your team who you (and nobody else) has ever met, who didn't
follow your team's coding conventions, and who has never looked at any
other part of your application to make sure that everything hung together
in a consistent manner. Which you now have to maintain.
I've read a lot of books, articles, blog posts, and mailing list messages,
and participated in no shortage of "why software sucks" discussions with
other programmers, but I've
never heard anyone advocate that the
way to clean code, minimal bugs, and happy programmers was to drop a big
chunk of unknown code right in the middle of things.
Before you start charging up the e-mail-delivered tasers, ready to fry my
delicate braincells for the twin crimes of Xenocodophobia and a vicious
case of Not Invented Here syndrome, though, please understand that I'm not
against code reuse in the right place. That right place is a library,
component, or other abstract, documented, fairly static, and
presumably-replaceable chunk of code. By using a library, you get a
relatively simple interface to somebody else's complexity. This is a good
thing, for all the reasons that everyone should already be able to recite.
Items such as a comprehensible interface, minimal learning curve, and so
on. Things you don't get with generated code because, pretty much by
definition, the entire chunk of code is you "interface".
There are some times, though, when what you want to do can't be done in a
library. Either the thing has too many tentacles to be able to easily
encapsulate behind an abstracted interface, or you need to modify it's
behaviour in too many places to be able to get away with a few simple
callbacks to get the job done. Hence, it might be tempting to fire up the
code generator to get yourself out of a hole quickly.
Don't do it though. Don't succumb to the temptation of saving yourself a
little bit of time by firing up a code generator. What you're doing there
is just making pain for yourself, by inheriting a big chunk of code that
you don't fully understand, probably doesn't solve your problem
particularly well, and which you (or whichever poor slob gets the job after
you) will have to maintain into perpetuity -- most likely by gradually
rewriting large pieces of it so that it fits your application better.
The output of a code generator is likely to be the least maintainable code
in your tree -- either by virtue of the fact that it's crap code, or at the
very least because you just don't understand it. The general principle of
good codebase hygiene is that you get rid of unmaintainable code quickly,
so it doesn't infect everything else (a la the "broken window theory").
With that in mind, why would you ever consider deliberately introducing a
huge chunk of unmaintainable code into your application?
The closest I can come to a defence of code generators is something like
Rails' scaffolding, where the controller and views for a set of simple CRUD
operations on a table are auto-generated. The key word there, though, is
scaffolding. It's very name suggests that it's temporary, to be
replaced with something more robust and useful as soon as is reasonable.
The default scaffolding is ugly as sin, besides, which encourages you to
replace it, and -- as of Rails 1.1 (I think), there's a 'scaffold' method
which creates the scaffolding output at runtime, so you never, ever need to
generate scaffolding code any more.
Anyone planning on producing any significant piece of their application
through the use of code generators is, in my book, committing a crime
against software decency.
1. My favourite whack code
construct thus far has been this gem:
case somevar
when 17
do_something_here()
end
Because, you know,
if statements are for people who know how to
program, or something.
Sometime in August,
I said I would watch the
Inbox Zero
talk later on that day. Well, I finally did today. And I'm ready to mass-murder
my (now not so) fat inbox folder and start from scratch, and becoming a good
boy.
In fact, I've been on probation for a few weeks. While I wasn't watching
the talk (which is pretty insightful and fun, and useful if you also
have these horrid mail handling problems) I did roll up my sleeves a few times
and worked on reducing the problem. After a few rounds of fighting, things
were looking slightly better. I deleted TONS of spam which still was sitting
in there. I deleted entire threads of list mail which for some reason wasn't
being filtered properly. I archived a lot of random, misc email. I even replied
to some job offers, for a change. I fixed my .procmailrc a little
to get rid of lots of useless stuff that appears in my mail. It got better,
but not entirely better.
I went from the 6600~ which was probably the figure when I said Enough!
to around 2580. It's still a lot, and I can still get rid of a lot more with
easy pattern searches in mutt. The good news is that, for the first time in
ages, the number of emails in the mailbox has stayed stable for more
than a month. I tell you: I'm proud!
So Merlin gets asked in the talk
what to do when you've been a naughty boy for a long time, and you've ended
up with this HUGE mailbox you can't handle anymore. His answer was what some
people suggested in blog comments: put it aside, start from zero. Merlin calls
it mail-DMZ, and that's probably what I'll do in a few hours, admittedly with
a sentiment of guilt deep in my chest. And from that point, I'll have my
mailbox be a TODO list. Delete. Defer. Delegate. Respond. Do. Simple!
Other Planet Debian participants like
joeyh commented
that something that really helps is reducing the number of times you poll
for email. For me, that means
Since I never really found a nice overview of which CPU flags (see /proc/cpuinfo) mean what, so I gathered some information using the web, with the most notable sources being the BOINC FAQ entry on CPU Register Acronyms at 
Well, still in the planning stages...
The general idea is to get a largish house in Denmark for one or two weeks, share the cost among ten people, and live a life of debauchery for one or two weeks, probably in the first or second week of January.
My Python development environment consists of a GVim window for editing code and a gnome-terminal for running the unit tests. This works out well, but leaves some integration to be desired. In particular, jumping to a test failure point is a little cumbersome. I used to do it this way: copy the filename from the traceback, switch to vim, then type :e, paste the filename with middle-click (now I know I can use * instead) and press Enter, then enter the line number and press G. That is barely acceptable; this particular wart has even contributed to pushing a ex-co-worker towards Emacs (the horror!).
I have written a small vimscript function to make the aforementioned use case slightly easier. Now to jump to a failure point, just triple-click the corresponding line in the traceback (that selects the whole line), switch to Vim and invoke the function, which scrapes the clipboard for a filename and line number and opens it in the active buffer.
Installation: paste the