Red/Green Code (for programmers)

Started by RickJ, Wed 03/12/2014 14:10:22

Previous topic - Next topic

RickJ

I recently viewed a video where the speaker talked about Red Code and Green Code in his programs.  He characterized Green Code as the part that says what he wants the computer to do and the Red Code as the extra bits that persuade the computer to do it.

I think this is an interesting concept that could help programmers of all levels simplify and structure their code.  I am unfortunately unable to remember/find the link to the video where I saw this presented.  I thought it was this one (Stop Writing Classes (python)) but now I am not so sure.  But I did find a couple of blog posts that explain the concept in more detail.

http://weblog.raganwald.com/2006/12/economizing-can-be-penny-wise-and.html
http://tapestryjava.blogspot.com/2013/01/red-code-green-code-my-code-your-code.html

This is of course the whole reason to have game engines in general and AGS in particular; a whole lot of the red/yellow code reside in the engine so that the game script has mostly green code.  The story doesn't end there; red/yellow code have a tendency to crop up in game scripts in spite of the engine.  AGS provides additional means of segregating red/yellow code from the main program through the use of modules and functions.

I think it is useful to think about this concept and how to put it into practice.  All of us Engine/Editor Developers, Module Authors, and Game Programmers could benefit from it.

Crimson Wizard

Quote from: RickJ on Wed 03/12/2014 14:10:22
I recently viewed a video where the speaker talked about Red Code and Green Code in his programs.  He characterized Green Code as the part that says what he wants the computer to do and the Red Code as the extra bits that persuade the computer to do it.

Um. I think this concept exists nearly as long as programming languages, like division between low-level code and high-level code, application code and library code, engine code and scripts, and so forth.

RickJ

#2
Yes the concept is as old as the hills, but I've never heard it summed up so well in just four words.

... And for being such a tried and true concept it's amazing how little it is practiced.

st.

I could say something from the position of one that does not program for a living; and I'm not an experienced game maker either. For me the advance of an AGS project depends mainly on inspiration; first for what I want to output, second for the manner of obtaining it. I have an idea and I seek to implement it. Then I have another idea and I go in that direction; sometimes in the context of the same function. And some times I have better ideas and I have to redo previous code. This kind of management, different from the following of a completely (or greatly) predefined pattern, does not favor the use of much "green" code. The ideas come and go fast. When this happens while programming there is simply no time for "green" code. One relies on memory to keep order in the program. When not working inside AGS, I write my ideas in a "Production/Ideas" folder using numbered files called "Theme", "Technique" and "Programming". While programming, I (in my turn) learned that a big help comes from the proper pre-structuring of a script file into general purpose segments and from using an organized notation for variables and functions; the structure is there to support my sort of creative (on the fly) programming. For me extensive "green" coding comes in handy only when going back to an old project, as a tool to refamiliarize myself with the program.
springthoughts

Snarky

I think you're misunderstanding the terms, springthoughts. It's not (directly) about code quality, i.e. that "green code" is better than "red code"; rather it's about separating what you want to do from how the computer should go about doing it. There's already a word for that: abstraction. You wrap all the nitty-gritty of how something works up into a function or a module, and provide an interface to just do it without worrying about the details.

st.

Perhaps I misunderstood the context of the discussion as being more general. Anyway, I suppose every programmer uses specialized functions; one of the most usual examples I think would be an Update<something>() function called from room_RepExec() or repeatedly_execute_always(). About modules I would add, without going too much off topic I hope, that the average game maker would have his or her game implemented through the Room(s) and Global Scripts and only after it is functional could he or she consider making a module out of some part of the program. This accords with the kind of project management that I described; supposing that the average game maker works like I do. It's simpler (faster) to adapt programming to game ideas this way.
springthoughts

Snarky

I suppose it depends on what sort of code you're writing. If it's just normal adventure game events and actions there's no reason you can't write them in the global/room scripts, but for "systems" like the UI, inventory, or if you have specific dialog customizations for example, as well as for minigames, I would always write it as a module (or if it's a very simple job at least as a helper function) straight away. At its most basic a module is just a separate place to put code, so it's no more work to do so. You don't have to write a complex API with everything wrapped up into a struct and so on.

st.

I suppose one can have the use of modules a habbitual part of his coding management. In the case of my latest projects it seemed easier to manage the code by having almost all of it in one room script; organized top-down by notation and block comments. It may be a matter of how flexible my mind can be while programming. The handling of errors, the design and update of segments of code interrelated by game concepts - these things seem more difficult when advancing a project containing modules. What I need is to have the coding distract me as little as possible from the game concepts. This may be the case of inexperienced programmers in general. Anyway, if I understood correctly, with me is green and red code in the same script; and what I wrote earlier may still apply. For interaction through GUIs I (have to?) use GlobalScript, but only to catch the clicks on GUI elements which I then throw to the (main) Room script with CallRoomScript().
springthoughts

st.

#8
Yup, I misunderstood the terms. I obviously had something else on my mind. Initially the topic may have had something to do with a tendency to replace the standard AGS entities with similar ones built from scratch, using the freedom given by the C++(-like?) basis, but again I may be seeing things. If this is true, however, perhaps an interesting continuation would be to discuss the concept of extension (classes?) in AGS with short examples from your practice. I thought that something from my experience could be of interest, like "a layman's point of view", but really, the point of view suitable to the original subject may be too high for my needs. Unless it was meant as a discussion between professional programmers, please give some examples to illustrate your meanings; you can add "(for springthoughts)" as an excuse.
springthoughts

SMF spam blocked by CleanTalk