Archive for October, 2009

Reading Code As Literature

Sunday, October 25th, 2009

After reading a few pages on Code Reading I’ve decided to start reading TinyPy as literature. That is, just read to understand and for enjoyment. Hopefully this will boost my code reading ability.

It also gives me a chance to play with CScope and Splint. Currently the TinyPy code doesn’t compile with gcc -ansi -pedantic, eventually I’ll change that it get to pass through splint with no errors.

I continue to be impressed with cscope’s interface and ability. I wish there was a similar tool for python. Huh, it looks like it may be able to do at least some stuff for python  (being a dumb “grep” without the ability to understand variables or functions).

I also eventually want to try:

  • BLAST (Berkeley Lazy Abstraction Software verification Tool) — a software model checker for C programs based on lazy abstraction.
  • Frama-C — A static analysis framework for C.
  • Uno — A tool designed to find most common type of programming errors without generating too much output.

Projects to test pythoscope on

Tuesday, October 20th, 2009

Just chatted in #python to get some ideas of what to try pythoscope on.

I guess I’ll start with pydoc first since it probably could be accepted as a patch to python.

Issues found while initializing:

  • Pythoscope needs the ability to exclude directories when initializing.
  • Pythoscope needs to be optimized during initialization — memory use grows to over 800 MB looking at the python standard library. At which point my poor netbook starts to page like mad :(

Testing, active reading and code reading

Saturday, October 17th, 2009

After reading Cem Kaner’s and James Bach’s slides on exploratory testing I noticed a technique I didn’t know about before, active reading, which can be distilled into SQ3R. Basically when you have a document to read, start by skimming the headings/topic sentences, determine questions to ask, read the document to answer the questions, distill the information into proper recall and review it.

This fits into spaced repetition quite nicely. After the information is distilled for recall, input it into a spaced repetition system for review.

The emphasis in the exploratory testing slides is to use this technique to rapidly gain information from documentation such as user manuals, design specs, etc. This is important, but I wonder if it can be used in code reading.

For example, for the YAJII project it might be broken into steps like this:

  • Scan the names of public classes
  • Ask questions about functionality
    • What is the public API and how is it used?
    • What are the areas that are highest risk?
    • What are the inflection points where unit tests can easily be added?
  • Read the code in detail while trying to answer these questions.
  • Write unit tests and additional documentation to record the answers found.
  • Reread the new documentation and unit tests, verifying against the code.

I’m going to try to do this in detail for my book on structured programming, even though I’ve read through it once, it’s very dense and some parts are hard to apply to modern programming languages. Some questions that I’ll want to answer (probably using my type system for objects book) are:

What are the terminologies used in structured programming and how do they relate to modern languages and object oriented programming? What techniques do they recommend for reading structured programs that can be applied to modern languages? What techniques need to be adapted? Are there techniques for unstructured program reading and modification that can be applied to modern languages?

YAJII Static Analysis

Saturday, October 10th, 2009

Ok, so I’ve got YAJII to compile and have the javadoc to help with browsing, so now it’s time to do the static analysis.

I’ll start by doing a callgraph of the Main class in the testbed package. This seems to have been used for doing functional tesitng by the author, so it’s a good place to start.

This leads me to the DefaultIRCPeer class. The most interesting method there is the sendMessage method, with interacts with the private class MessageEventDispatcher.

I’ve been able to comment out the methods in this class, but it uses fireMessageReceivedEvent and fireMessageSentEvent from the IRCPeer class.

The fireMessage*Event methods call the EventDispatcher.fireEvent methods for the receive and send dispatchers. EventDispatcher.fireEvent simply delegates to an EventHandler class that then delegates to the listeners.

And now I’m going to switch gears and try to find a test server to use…

Nomic in Normalized English

Thursday, October 8th, 2009

New thing I want to try: Convert the Nomic core rules into normalized english.