[ i'm still working on this concept, so this is a very rough draft... ]
writing beautiful code.
sometimes you code, and it seems as straightforward as:
"all nearby units - protect/serve - wilshire and santa monica". (high fives all around - but no touching! ).
and sometimes you code, and its like "well, i know i'll need this...
and i might need that... but then i'm also going need some other
kind of thing to take care of this other part..." and so you code
some, and think some, and code some more, and think some more, and
eventually something comes together (lets hope! ). and then you
might do some refactoring and cleanup.
and sometimes you code and you get big complex lines of code like
this one from Caveman 3.0 animal_in_strikezone(int cm1):
rh=RH(cm[cm1].mx,cm[cm1].mz,(int)cm[cm1].x,(int)cm[cm1].z,(int)rad2deg(cm[cm1].yr),animal.mx,animal.mz,(int)animal.x,(int)animal.z);
whew! just reading it hurts! and i had to write it! .
and then sometimes you code and you get what i can only describe
as beautiful code - things like:
if (!camera.cansee(location)) return;
location includes a bbox/bsphere rad or Brect dimensions.
this one line performs both farclip and frustum cull.
and it reads like english.
i think thats the key to beautiful code.
it tends to read the way you'd say in engish how to do something.
so i suspect that top down pseudo coding in english will tend
to create more beautiful code.
when i've done this in the past i've noticed this.
i also had one group project experience with this as well.
as part of systems programming class at OSU, teams of four
students each implemented a compiler, linker, loader, and
emulator as a group project. we had a 2 page pseudocode algo we
were given for the compiler. we were to use C, and were expected
to learn it on our own as we went along. back then, OSU taught
you pascal, then let you figure out C for yourself. at our first
team meeting, i applied top down pseudo coding to each part of
the compiler algo. within an hour or two, we had everything
figured out, it was all simple, neat, and clean. coding tasks
were assigned, all team members were comfortable with their
assignments and confidence levels were high. at the end of
the session one of the team members commented as to how the
top down pseudo code approach made everything amazingly simple.
needless to say that was about the last thing that went right
in the project. we only had 3 team members to start with,
and one of them dropped the class, leaving just me and one
other coder. he did what he was originally assigned to do.
i pulled two all nighters in a row doing the rest while
visiting my finacee at VA Tech over the weekend. on monday
morning, having not slept since friday night, i uploaded the
code to my partner at OSU, who turned it in. there was only
one minor bug in the compiler. we got an A! :)
i think i should get into the habit of trying to code this
way more often. it could lead to good things.
after all, we're giving instructions to something (a computer).
and we speak english or some other human tongue - although we
probably tend to think in code - being programmers. perhaps its
time to think in english (or whatever) rather than code.
write down an instruction in english. change the nouns to
variables, and the verbs to method calls, that kind of idea.
following that analogy, direct objects would probably be
parameters. an example:
step 1 in english:
make Jack throw the ball.
step 1 in code:
jack.throw(ball)
i know, pitifully obvious and contrived! but i think it gets
the point across.
here's a more real-world example:
if the camera can't see the object's location, don't render it.
if (! camera.cansee(object.location)) return.
so perhaps we should not only strive for good code, perhaps we
should also try to make it beautiful - IE god-like in its clarity.
