I feel like writing something so I'm going to analyse a line of your code that can be changed to be more efficient, I'm doing this to help you learn not to make fun of your code.
This is the line I've chosen:
inc green : if green>255 then green=255
What the computer will do here is increase green by 1 (you can specify a different increment if you want), then check if green is over 255 and if it is, green will be assigned the value 255.
Here's the process the computer will go through:
[pseudo code]
green=253 (we only need to look at numbers close to 255)
1. inc green [green=254] : if green>255 [false]
2. inc green [green=255] : if green>255 [false]
3. inc green [green=256] : if green>255 [true] then green=255
4. inc green [green=256] : if green>255 [true] then green=255
5. inc green [green=256] : if green>255 [true] then green=255
6...
Notice how after the 2nd iteration green is being increased for no purpose, this will continue for the rest of the program.
A more efficient way of doing this would be to have the computer check the variable before altering it:
if green<255 then inc green
So now green will only be increased if it is below 255.
Here's the process the computer will go through:
[pseudo code]
green=253 (we only need to look at numbers close to 255)
1. if green<255 [true] then inc green [green=254]
2. if green<255 [true] then inc green [green=255]
3. if green<255 [false]
4. if green<255 [false]
5. if green<255 [false]
6...
The computer is doing half the work this time.
Like I said earlier, it is possible to specify an increment with the INC command. My example comes into problems here:
[pseudo code]
green=253 (we only need to look at numbers close to 255)
1. if green<255 [true] then inc green,3 [green=256]
2. if green<255 [false]
3. if green<255 [false]
4...
When we increment by 3 green gets stuck on 256 which is too large for a single colour value. The resolution is to check the value of green after we have altered it; doesn't that sound familiar? It's your original line! Not quite (get ready for a tongue twister); because we are only altering after a check, we will only perform our second check if the first check was true.
Maybe I should let my code do the talking
[pseudo code]
green=253 (we only need to look at numbers close to 255)
1. if green<255 [true] then inc green,3 [green=256] : if green>255 then green=255
2. if green<255 [false]
3. if green<255 [false]
4...
So now we can keep the maximum of green to 255 and still save the computer a lot of work.
ADVANCED SOLUTION
I am currently in a phase of trying to condense my code by using maths instead of IF statements etc.
Here is my solution to this line:
s=3 : `define step value
green=248
inc green, ((green<(255-s))*s) + (green>=(255-s)) - (green>(255-1))
Woah! That was more complicated than I first thought, I spent a good 30 minutes working on that one line

I will now attempt to explain what all that does.
The first part
((green<(255-s))*s)
will return 3 (or whatever the step value is) if a full step can be added to green, if not it will return 0.
The second part
+ (green>=(255-s))
acts a bit like ELSE in an IF statement. It will return 1 if a full step cannot be made or 0 if it can. This is added to the first part because one must always be true (anything is either true or false).
The third part
- (green>(255-1))
stops anything being added once green has reached 255. It is subtracted from the second part to cancel out its effect.
Well there you go, I think I learnt something new, hope you did too
"You must be someone's friend to make comments about them." - MySpace lied.
