Women in Technology

Hear us Roar



Article:
  Myths Open Source Developers Tell Ourselves
Subject:   on code reading
Date:   2003-12-12 11:54:06
From:   chromatic
Response to: on code reading

I'm not sure where you picked up the idea that I don't recommend reading code. One of the persistent problems in software development today is that far too few people DO read code.


That said, the myth is that pointing at a huge pile of code and telling new developers "just read it" is effective. I think that's possibly the least effective way to learn a project.


There's no substitute for reading code. I certainly don't intend to give that impression. At some point, new developers absolutely must read the code.


I don't think that's the best, first place to start though. Show them a glossary, an overview, completed story cards, or maybe UML. Explain how the pieces fit together. Then (and only then) let them examine the individual pieces.

Full Threads Oldest First

Showing messages 1 through 3 of 3.

  • on code reading
    2003-12-16 13:00:49  theoldmoose [View]

    Heh. The quickest I've learned code is to port it to another platform. That will force you to become aquainted with the entire code base in fairly short order. 8-)

    And while I was at it, I 'ANSI-fied' a piece of C code (a 400+ function machine vision library) that produced hundreds of warnings when fed to a modern compiler. The original code had virtually no prototypes, except those that were thought to be required for functions whose Miranda prototypes might not match.

    Of course, I uncovered several bad assumptions in that code along the way, including unused and incorrect parameter passing. Some of these were causing latent and/or re-occurring mysterious errors that applications programmers had long ago given up finding, and had coded work-arounds to in their code.

    That was the initial payoff. Having a much more maintainable piece of code continued to pay off over the 10+ year lifespan of the code as a library. It is still in use in hi-speed wirebonding machines on the Intel Pentium line.

    The library was not Open Source in the sense that we use it today, but it was shipped in source form to our machine vision OEM customers, for use by their application programmers. So, it had to be buildable on various embedded 32-bit Unix-like platforms, and useable both within realtime OS environments (like VxWorks) or running on a bare-metal C runtime library.

    It was all done with the GNU cross-compiler toolset and CVS, on SunOS workstations. Most fun I remember having in a long time. 8-)
  • on code reading
    2003-12-14 03:33:14  anonymous2 [View]

    <blockquote>At some point, new developers absolutely must read the code.</blockquote>
    Having just told you off above for panning code reading as a project intro: Graphic artists? Translators? Must read code? Hmmm...
  • on code reading
    2003-12-12 12:44:57  anonymous2 [View]

    I totally agree with you.

    If reading code is the starting point for learning, nothing guarantees that the code that one is reading is of high enough quality to emulate or incorporate into one's own repertoire of coding techniques.

    There can be no objective evaluation of the techniques that one uncovers.

    I've found that the "cookbook" approach to learning to code can be of extremely high value if one already has some solid experience, but one must know if the "recipe" is worth repeating in the first place. This doesn't just apply to bad code but inefficient code, as well.

    Once someone has learned a poor technique, it's impossible to estimate what or how long it'll take to switch to a superior one, especially in an unstructured environment.