Stable code

Quote:

if(values.size() > i) { return values; }

if ( values.size() > i && i >= 0 ){   return values;}

Quote:

Original post by empirical2 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.

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.

Quote:

Original post by empirical2 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.

Quote:

Original post by swiftcoder For normal software (applications, games, etc.), we don't need to handle every eventuality robustly. There are many cases where it is acceptable to just crash, for example: power-outages, hard-drive crashes, a dying memory chip returning random values, some random idiot manually corrupting your stack with a debugger, ...

Quote:

Original post by empirical2 User open case and goes at the RAM with a hammer and chisel.

Quote:

Original post by frob One feature of a mature code base is that the code is covered with asserts and each one of them has a corrective action.

Quote:

Original post by PrestoChung Noob question: Is this assert thing like exception handling?

// Reading a file. Anything could go wrong.// Same with user input. Network data. etc.std::ifstream file("my.txt");int data;if( !( file >> data ) ){  std::cerr << "ERROR! CAN"T READ HEADER!!!" << std::endl;}vs// Allocating memory, it should almost always just work// but we could have fragmented too much or some other edge case.try{  foo = new foo[200000];}catch(...){// whoops! out of memory!}vs// Sanity check inputs! The function has error correction anyway, but// a dev will hit the assert in the debugger.  This gives easy access// to the problem without having to debug as much. The asserts aren't errors or// exceptions because this function isn't EVER supposed to be called with bad// data. If the data is bad, the caller screwed up something or someone overwrote// the caller's data with something bad.void DoStuff( unsigned char *buffer, const size_t sz, const foo &object ){  assert( buffer );  assert( sz < MAX_BUFFER_SZ );  if( !buffer || sz >= MAX_BUFFER_SZ )      return;   assert( object.is_valid() );  assert( object.is_active() );  if( !object.is_valid() || !object.is_active() )      return;......}

Quote:

I would go about: if(values.size() > i) { return values; }

Quote:

Original post by Windryder 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:

void addPlayerToWorld(Player* player, const Vector3* spawnPoint){    // Must not be null.    if(spawnPoint == NULL)        return;    player->setPosition(spawnPoint);    players.push_back(player);}

Quote:

Original post by Windryder 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.