Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Wednesday, January 30, 2013

Red Code, Green Code, My Code, Your Code

I had a very odd interchange with my friend Merlyn over lunch; he started talking about red code vs. green code (in the context of supporting both callbacks and promises inside NodeJS). At first I thought he was referring to code coverage of those lines of code ... the implication being that supporting multiple paths of execution may lead to laziness in testing every possible path (with some code going "red" in the code coverage report).

But that wasn't it at all: "red" code referred to framework code, "green" code referred to end-user code, leveraging the framework.

Odder still, Merlyn insisted that he first heard this term from ... me, a few years ago. That's what being in the baby-raising camp can do to you ... I know longer have any idea of what I've said or thought in the past. Actually, this isn't new for me ... I've always had a very vague memory for anything not code.

In any case, this red vs. green terminology is a useful concept ... certainly I move the earth in Tapestry's red code to make end-user's green code as simple as possible.

So, I want to do three things:

  • It's definitely worth reflecting on the fact that all code is not created equal, and that long-lived, reusable code ("red") will inevitably grow in complexity to a level that would not be acceptable in client ("green") code.
  • Let's promote this term, because it is so handy!
  • If I didn't create the term myself, let's track down the originator and thank them!

2 comments:

Curious Attempt Bunny said...

I'm not sure, Howard. I think you might have invented it. You were certainly struggling to explain your thinking at the time.

I don't agree with your definition now. In particular, I disagree with this:

* It's definitely worth reflecting on the fact that all code is not created equal, and that long-lived, reusable code ("red") will inevitably grow in complexity to a level that would not be acceptable in client ("green") code.

It's not about how long lived the code is or how reusable it is. That could be said for both red and green code.

This fits better for me:

"Frameworks and APIs should be designed to make the code that's written on top of them as clean as possible. I call this client code the green code. The flip side of this is that the framework/API code may have to contort itself and jump through hoops by way of complexity in in order to be able to deliver this simplicity of use. This code is red code. Sometimes you have to write red code in order to let other people write green code."

From
http://www.curiousattemptbunny.com/2013/02/red-code-vs-green-code.html

Curious Attempt Bunny said...

In fact, I've added a very good example of red code vs green code to my post: Gralde's buildscript block: http://www.gradle.org/docs/current/userguide/userguide_single.html#sec:external_dependencies