Stable code
Author
Hello, I have been programming for about 2 years now.
Mostly in c plus plus.
Been working in the win32 and direct-x apis doing both 2D and 3D applications.
I consider myself to have the basic knowledge, but as they say, "the more you know the more you realize how little you know".
I would like to get some clarifications on what stable code is.
Any examples would be great.
Thanks in advance :)
AFAIK Stable code is simply code that:
1. Is bug free or as close as possible.
2. Is not breakable by invalid input or abnormal or unexpected situations.
1. Is bug free or as close as possible.
2. Is not breakable by invalid input or abnormal or unexpected situations.
Author
Ok, so for example.
Lets say I want to get a value from an std::vector.
I would go about:
instead of just:
Lets say I want to get a value from an std::vector.
I would go about:
if(values.size() > i){ return values;}instead of just:
return values;Quote:
if(values.size() > i)
{
return values;
}
Definitely a step in the right direction, but writing stable code is about thinking of EVERY possible way the code could go wrong and making sure it no longer can.
It's a mindset you will get yourself into after a while of practice. Go through your code you already have and imagine what would happen if input in your functions was not as expected. Think of the entire range of a given data type when you see it coming into a function. For example, integers can be negative, so:
if ( values.size() > i && i >= 0 ){ return values;}
Author
Thanks for the input.
If there is no more to stable code than that, I should be able to grasp it!
in addition to making sure you handle unexpected input well, handling your memory correctly will also go along ways into making sure you code is stable,
nulling pointers when they are first declared,
anytime a pointer is deleted nulling it
and possibly implementing some form of garbage collection or reference counting can go along ways to making your code stable
one of the things that has helped me the most with making sure my code is stable, using readable/understandable variable and function names
nulling pointers when they are first declared,
anytime a pointer is deleted nulling it
and possibly implementing some form of garbage collection or reference counting can go along ways to making your code stable
one of the things that has helped me the most with making sure my code is stable, using readable/understandable variable and function names
Quote:Original post by empirical2This. Stable code should be well tested, and unlikely to need change in the near future.
AFAIK Stable code is simply code that:
1. Is bug free or as close as possible.
Quote:2. Is not breakable by invalid input or abnormal or unexpected situations.This would be more along the lines of 'robust' or 'secure' code. It isn't generally expected that "stable" code be bullet-proof in the face of arbitrary/malicious invalid input.
Quote:Original post by swiftcoder
This would be more along the lines of 'robust' or 'secure' code. It isn't generally expected that "stable" code be bullet-proof in the face of arbitrary/malicious invalid input.
Well personally I would not distinguish between stable and robust. If code is going to fall over because the user does something stupid (100% dead cert) I do not consider it to be stable. However, I'm not a professional and if 'stable' has a defined specific meaning, I, of course, accept that.
If your coding something and your not sure if its gonna crash or not, avoid using while loops, cause they can infintesimally cycle if their break condition is never met.
Something that needs to be coded securely and robustly for example is CSG (constructive solid geometry) its when you get a ball and cube and take a chunk out of the cube with the ball or vice versa.
The code usually gets to be 1000 lines long (longer if you stuff it up) and theres many points inside that can stuff up if the piece of code before doesnt output correctly.
Tesselation is another algorythm which should be robust and allow invalid inputs and still work.
CSG and EAR CLIPPING are 2 algorythms that both best remind me to be very secure when I code, being less lazy can sometimes be less work than careless
programming that ends up getting you no-where.
Youll be coding these 2 algorythms when you are making a model editor or environment builder.
They are both in the "geometry tool" class of algorythms, and in this class of algorythms I say think it 4 times over! before you put hand to keyboard.
Even if you cant see how to get an algorythm to work with every single case you can think of... you can at least let it "fail gracefully" and not crash the program terminally.
Something that needs to be coded securely and robustly for example is CSG (constructive solid geometry) its when you get a ball and cube and take a chunk out of the cube with the ball or vice versa.
The code usually gets to be 1000 lines long (longer if you stuff it up) and theres many points inside that can stuff up if the piece of code before doesnt output correctly.
Tesselation is another algorythm which should be robust and allow invalid inputs and still work.
CSG and EAR CLIPPING are 2 algorythms that both best remind me to be very secure when I code, being less lazy can sometimes be less work than careless
programming that ends up getting you no-where.
Youll be coding these 2 algorythms when you are making a model editor or environment builder.
They are both in the "geometry tool" class of algorythms, and in this class of algorythms I say think it 4 times over! before you put hand to keyboard.
Even if you cant see how to get an algorythm to work with every single case you can think of... you can at least let it "fail gracefully" and not crash the program terminally.
I think stable code is code that is (close to) unbreakable by user input and varying factors (time, thread scheduling, etc). On the other hand, I do *not* think that writing code in a way that it silently ignores bad input from the programmer is a good idea. Consider this silly example:
If someone, for whatever stupid reason, assumes that NULL is a valid value for the second parameter, the program will not crash. Instead, it will silently ignore the error and do nothing, leaving the programmer confused as to why the desired result isn't achieved. A better way to handle this might be with a debug assertion, so that the programmer can clearly see what went wrong, and where, without affecting production code.
void addPlayerToWorld(Player* player, const Vector3* spawnPoint){ // Must not be null. if(spawnPoint == NULL) return; player->setPosition(spawnPoint); players.push_back(player);}If someone, for whatever stupid reason, assumes that NULL is a valid value for the second parameter, the program will not crash. Instead, it will silently ignore the error and do nothing, leaving the programmer confused as to why the desired result isn't achieved. A better way to handle this might be with a debug assertion, so that the programmer can clearly see what went wrong, and where, without affecting production code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
