The Old Joel on Software Forum: Part 4 (of 5)

Table Driven Programming

Reference this post:
http://weblogs.asp.net/ericlippert/archive/2004/02/24/79292.aspx

Eric says, "Table driven programming is a technique that can make any program more readable and maintainable, but is often overlooked by script developers."

I haven't heard of this technique before. Any good sources online where I can learn more about it? Eric suggested "Writing Solid Code" by Steve Maguire - any other books or resources that are good?

Is this method of programming only for scripting?

nathan
Tuesday, March 2, 2004

The concept of a "Jump Table" has a long history, going back to machine language. No, it's not just for scripting. However, many times the compiler will expose higher level constructs that make them less necessary.

For example, virtual functions are implemented via a jump table. Just calculate the array offset, grab the address, and jump.

I don't have any other references on these kinds of things at hand, unfortunately.

Chris Tavares
Tuesday, March 2, 2004

The 'article' is a dull and obvious observation (IMHO).

Tuesday, March 2, 2004

Here's a link to a book-length discussion on programming with tables: http://www.geocities.com/tablizer/top.htm

There's also a lengthy rant on there about the evils of object-oriented practices, and discussions about other topics of interest: http://www.geocities.com/tablizer/index.html

The stuff seems a little over the top, and I don't agree with most of it, but it is a different point of view.

chip
Tuesday, March 2, 2004

Using Metadata to help a program run is nothing new. I do this with most of my projects.

Norrick
Tuesday, March 2, 2004

If you are at all confused by the article then don't fret, just practice programming some more. If you are writing code like that shown in the article, with reams of conditional statements, you are doing it the wrong way. By encoding the choices in a table, and writing a small amount of (perhaps a bit more complex) code to pick the right one, the program magically becomes simpler overall.

Insert half smiley here.
Tuesday, March 2, 2004

I do all my programming on a table. Lap driven
programming never worke for me.

son of parnas
Tuesday, March 2, 2004

I've seen this method suggested to be used with meta-data stored in files external to the program, and then read and interpreted at run-time.

I agree that table-driven methods can make code a hell of a lot more maintainable (and the logic, too, if you structure the data correctly).

However, by exposing the program's logic to anyone with a curious eye, is this approach not not asking to be considered a security flaw?

Has anyone suggestions as to how this risk might be reduced to an acceptable level?

C Rose
Tuesday, March 2, 2004

Then encrypt the god damn config files!

MX
Tuesday, March 2, 2004

"Security through obscurity" doesn't work in practice, despite the common belief. Security flaws can be discovered with or without access to your source code; Source code availability sometimes makes it easier, but that doesn't mean that undisclosed source code isn't vulnerable.

Everybody has access to Apache source; Yet, it has proved more secure than the closed source IIS over a long period of time. (Apache is about twice is popular BTW - so IIS is not a more visible target).

It's possible to design a secure, robust system whose design and implementation is public - unfortunately, most systems aren't.

Ori Berger
Tuesday, March 2, 2004

The point is that most languages don't make this particularly easy. He puts a bunch of functions in a table, and later grabs the one he wants. Forget the fact a table is used, and just see it as a way to "name" these handlers.

The reason he posted it is because most languages don't support the ability to easily pass around functions in a pretty way. But it's a very basic programming technique, and no deeper than it seems. Think of these functions as "objects"; I don't mean OOP, but just as a "thing you can operate on." If you put objects like numbers and strings into a table, you should be able to stick a function in there too. Then you can pull it out when needed. It's a very dynamic form of programming, where you're dealing with stuff at runtime instead of compiletime.

Tayssir John Gabbour
Wednesday, March 3, 2004

Annon and Norrik,

Your right that this is all old news. The incredible things is that so few people use these techniques.

Some programmers seem to be in love with the case statement. In the code I maintain there is a function that exists of a case statements embedded 3 deep that stretch over nearly a 1000 lines of code!

Ged Byrne
Wednesday, March 3, 2004

I have to agree, there's nothing particularly revolutionary about what he's doing, although it's not something taught in university classes. I use the technique heavily in CGI programs to determine which function will handle request processing based on the label on the button that the user pushed.

Clay Dowling
Wednesday, March 3, 2004

> I haven't heard of this technique before

Good thing I blogged about it then!

> Is this method of programming only for scripting?

Good heavens no. Very handy in C.

> The 'article' is a dull and obvious observation

Thanks for sharing! I'm sure we're all thrilled by your fascinating opinion, sparkling wit, and condescending attitude.

Oh, wait, am I feeding the troll? Never mind then. Forget I said anything.

> by exposing the program's logic to anyone
> with a curious eye, is this approach not
> not asking to be considered a security flaw?

The question is far, far too general. Pick a specific case and then ask "What's the threat?" "What are the vulnerabilities?" "what are the consequences?"

For example, the threat might be "bad guys change the configuration file", the vulnerability might be "because I left the file on a world-writable share", and the consequences might be "and now my program is going to email my financial data to Fidel Castro instead of my accountant."

Once you know what the threats, vulnerabilities and consequences are, you can make sensible risk assessments. See Mike Howard's book for more details.

> Your right that this is all old news.

I don't believe I made the claim of originality! :-)

> The incredible things is that so few people
> use these techniques

I agree -- which is why I wrote the article in the first place.

Eric Lippert
Friday, March 5, 2004