assert( yourCodeCorrectly );

Everyone thinks asserts will somehow help you or somehow make your life easier or better. Sometimes they do, but sometimes n00bs don’t know how to use them properly. Here is an example of just such a case:

We stopped it from crashing, but it still asserts, and so it exits the app, so it is equivalent to a crash because the app stopped working. Oh yea, this code only works in debug mode, so if we’re running release, this statement gets stripped out too. So whether we are in release mode or debug mode, the app will terminate in some way, so we have done nothing to solve the problem, which is, the app exits unexpectedly and the user will no longer run it anymore, even if you fix it in the future. You have just proven to the end user that you are indeed incompetent so anything you produce in the future will probably go unnoticed.

This isn’t the real problem though. The real problem is when you use asserts all over the place without thinking, assuming they’ll protect your product somehow. Then, when you go to release, crash here, crash there, you get the idea. What asserts should be used for, aren’t to check right before a possible crash, they’re to check that some of your logic is indeed correct.

For example, you may assert that a return value is correct (the function works correctly), or a loop invariant does not change, but do not use asserts to check indices into an array or for checking null pointers right before dereferencing them. Those cause crashes in debug and release mode and we know that asserts will not save you in release mode.

We have a few options here:

  1. Use if statements to protect indexing into the array and also to spit out an error, probably returning in the process. This clutters code up with a bunch of error checking though.
  2. We can throw an exception if possible. If you’re using regular C arrays, in C++, then this isn’t going to happen, it will crash when you index. So you need to wrap the array with your own custom array interface probably and throw accordingly.
  3. Use goto and labels if exception handling is not possible. If you don’t suck at coding, goto statements have their use and can act as a crappy but cheap exception handlers when you don’t have the compiler flag to enable exception handling turned on. But, of course, be careful with it n00b.

Ok, so we’re talking about being robust here. We have traded speed for robustness and this is perfectly fine for some enterprise level applications where quality is more important (such as handling your credit card info). But if speed is more important, then asserts may very well be what you’re looking for.

vim – Quote something quickly

This is actually two tricks. Surrounding and highlighting something easier.

Step 1: Install the “Surround” vim plugin
Step 2: type the following: viwS”

This means, go into visual mode, and select the inner word, then surround it with quotes.
If you use “W” instead of “w”, it will select the whole chain of words.. Or highlight them.

If your cursor is situation on the word “car2” and you use:
lower case w: car.car2.car3 will select car2
upper case W: car.car2.car3 will select car.car2.car3