Since the space bar isn’t use in normal mode, map zz to it. This makes it easy when using “N” or “n”. Then you can quickly press space bar and it will center the found item to the center of the screen.

Put this into your .gvimrc file: nmap <space> zz

You could also do the following:

nmap n nzz
nmap N Nzz

You can also change how it scrolls by setting the amount of lines from the edge of the buffer you can go before it starts scrolling

:set scrolloff=1000 

This scrolls whenever you move the cursor, but you can set it to 10, for example, to scroll if it comes within 10 lines of the edge of the buffer.

void AwesomeFunc( void )
{
    if( var == 3 )
    {
        if( var2 == 4 )
        {
            if( var4 == "napkin" )
            {
                if( var5 == 8495 )
                {
                    g_flag = true;
                }
                else
                {
                    Debug.Log( "var5 wasn't 8495" );
                }
            }
            else
            {
                Debug.Log( "var4 was not napkin" );
            }
        }
        else
        {
            Debug.Log( "var2 wasn't 4" );
        }
    }
    else
    {
        Debug.Log( "var wasn't 3" );
    }
}

This situation has numerous problems.

1. It’s difficult to read.
2. The cohesion is terrible. If you trace a debug log to one of the debug statements, it is no where near the failure. So you have to sloppily figure out which if failed.
3. It can get complicated.

At first it may seem that you can just pull all of the if statements together like this:

void AwesomeFunc( int var, int var2, string var4, int var5 )
{
    if( var == 3 &&
        var2 == 4 &&
        var4 == "napkin" &&
        var5 == 8495 )
    {
        g_flag = true;
    }
    else
    {
        Debug.Log( "Problem. I do not know what the problem is though." );
    }
}

It’s pretty clear what the problem is. We simplified the statement, but we lost all our debugging information.
If one of the ANDed statements fails, we still have to check which one in the “else” clause.

Enter “Early-out”. The concept of an early-out is simple. Just check for negative conditions instead of positive ones.

1. It keeps the errors together with the failure check.
2. It makes the code easier to read
3. Its easy to tell if you forgot something
4. Use this method to check input arguments passed to the function

It’s simply a matter of reorganizing the code.

void AwesomeFunc( int var, int var2, string var4, int var5 )
{
    // Check parameter 1
    if( var != 3 )
    {
        Debug.Log( "var wasn't 3" );
        return;
    }

    // Check parameter 2
    if( var2 != 4 )
    {
        Debug.Log( "var2 wasn't 4" );
        return;
    }

    // Check parameter 3
    if( var4 != "napkin" )
    {
        Debug.Log( "var4 was not napkin" );
        return;
    }

    // Check parameter 4
    if( var5 != 8495 )
    {
        Debug.Log( "var5 wasn't 8495" );
        return;
    }

    // If we got this far, we're golden...
    g_flag = true;
}

So all we did was reorganize the code, got rid of the “elses,” and changed the boolean logic to != instead of == on all if statements. This is a good way to make sure you’re testing all of your parameters for valid input before you actually execute any code… They’re called early-outs because they attempt to exit out of the function as early as possible. This avoids any unnecessary processing (that’s the theory any ways.)

• BVT (Base verification tests)
• –Positive test cases
• FVT (Functional verification tests)
• –Positive Test Cases (Tester tests for expected failures )
• –Negative Test Cases (We catch unexpected failures during testing (hopefully) )

BVT (Base Verification Tests)
These are the basic tests performed to show that the operation is basically working. Sometimes you just want to run the BVT tests because they’re faster and shorter. Example:

// Function to be tested
float Calc( float a, float b, float c )
{
    return a * b / c;
}

// The actual BVT
void RunTestCalculateDataBVT( void )
{
    TEST( Calc(2.0f, 2.0f, 1.0f), 4.0f );
}

It is short and to the point. TEST is a simple macro that checks if the return value of the function is equal to the second parameter. It checks to see if 2*2/1 == 5. Nothing more. It is fast, but it doesn’t check everything. This test is also called a positive test case. A positive test case consists of passing in valid data, and expecting to get a valid result.

FVT (Functional Verification Tests)
The FVTs are a much more in depth testing stage. It consists of a much more thorough testing of the functions, in both quantity, and quality. FVTs consists of the BVT tests as well. So they may be duplicated, but this isn’t necessary. In some cases, the FVTs consists of modifications to the BVTs.
From the example above:

// The actual FVT
void RunTestCalculateFVT( void )
{
    // Positive test cases
    TEST( Calc( 2.0f, 2.0f, 1.0f ), 4.0f );
    TEST( Calc( 0.0f, 0.0f, 1.0f ), 0.0f );
    TEST( Calc( 1.0f, -1.0f, 1.0f ), -1.0f );
    // …..
    // More positive test cases to show that it works.

    // Negative test cases
    TEST_THROW( Calc( INF, INF, 1.0f ), EXCEPTION_OVERFLOW );
    TEST_THROW( Calc( 1.0f, 1.0f, 0.0f ), EXCEPTION_DIV_BY_ZERO );
    TEST_THROW( Calc( INF, INF, INF ), EXCEPTION_NAN );
    // More negative test cases.
}

As you can see, we now have a lot more test cases and they’re broken up into positive and negative test cases. We may want then to be in separate functions too, but I didn’t do that here. Our positive test cases have a lot more cases and are simple modifications to the BVT.

The FVT also consists of our negative cases, where, if the function fails, (gives an invalid result the user can’t use) it needs to fail in an expected and deterministic way. Under no circumstances should it crash. When it crashes, this is an “unexpected failure,” and is usually caught very soon, since your tests will also crash. This is the most common unexpected failure. I can’t really think of any other right now.

Also, all of the negative test cases will fail in this scenario because nothing in the function is being thrown. And our tests are expecting it to throw the correct exceptions. When testing, it’s important to test common boundary values. In the example above, good things to test are 0, -1, 1, INF, -INF, NaNs, and other such things. When writing code, it’s important to check for the same boundary conditions immediately at the top of the function.

One final note before I leave. These are NOT unit tests. Unit tests sometimes overlap the BVTs, but they are written by the developer who wrote the code (in this case the Calc function). So they are not written by the tester (or SDET).

// These two lines are the same type
// const and int can be switched around and the result is the same.
const int i;
int const j;

// If the word "const" follows the "*", it affects the pointer
int* const k;

// Both the pointer and the int are const
const int* const m;

// Same as line above, it just looks weird
int const * const n;

// Does the const affect the pointer or the int? The int..
int const * p;

Lets say for example, we only have access to a 1 dimensional array data structure and it has 50 elements in it.

int data[50];

Lets break this array up into 10 rows and 5 columns to make a grid. So how do we get access to a position say data[4][3]?
There are two things I’m going to teach you now:
1) Retrieve the column & row numbers from a linear index counter.
2) Retrieve the index from a row & column numbers.

Before I continue, i want you to notice that the row and column numbers are zero based. So they start at zero, not one.

Lets do #1 first:

unsigned int index = 6;
unsigned int numRows = 10;
unsigned int numCols = 5;

int row = index / numRows;
int col = index % numCols;

Here, “col” and “row” will contain the column and row number for index #6 in the linear array.

Here, we are taking advantage of dividing up a long linear array up into sections (rows), hence the division operator. So we have 10 rows / sections. We get a particular one by using the formula index / numRows.

If we were to loop through the linear array (0-50), moding (%) each number with some maximum number (say 5), we would obtain a series of numbers that went like the following: 0,1,2,3,4,0,1,2,3,4,0,1,2,3,4… (index % numCols). Notice how it repeats between 0 & numCols – 1? Where numCols is 5 in this case. Where index goes through 0 – 50, our column repeats from 0 – 4. Nifty huh? This works because the mod operator returns the remainder of a division (4 % 2 = 0 because there is no remainder).

As a side note: col could also be written like such: col = index – numRows * row. See below for why.

Now lets do #2:

unsigned int row = 4;
unsigned int col = 3;
unsigned int numRows = 10;

data[ numOfRows * row + col ];

This is a pretty simple idea. We basically took the formula from #1 above and rearranged it. (row = index/numRows). Here we are also using col as an offset into the row. So we just add it on.

If you take index = numOfRows * row + col, you can solve for col, since we already solved for row. Hence the formula in #1′s side note: col = index – numRows * row

Example program:

#include "stdafx.h"
#include <iostream>
using namespace std;

const int LENGTH = 9;
int data[LENGTH] = {0};
int numOfRows = 3;
int numOfCols = 3;

int _tmain(int argc, _TCHAR* argv[])
{
	for( unsigned i = 0; i < LENGTH; ++i )
		data[i] = i;

	for( unsigned row = 0; row < numOfRows; ++row )
		for( unsigned col = 0; col < numOfCols; ++col )
			cout << data[ numOfRows * row + col ] << endl;

	// Get the column or row from a linear index
	unsigned indexNum = 4;
	int row2 = indexNum/numOfRows;
	int col2 = indexNum%numOfCols;
	cout << "row: " << row2 << endl;
	cout << "col: " << col2 << endl;

	// Get the index from a column & row
	int row = 1;
	int col = 1;
	cout << data[ numOfRows * row + col ] << endl;

	return 0;
}

The output for this program is:

0
1
2
3
4
5
6
7
8
row: 1
col: 1
4

Lets say you have the sentence “you are a car.” Let’s also assume you have placed your cursor on the letter “a” in “are.”

And we want to highlight the word “are.” So we press “vw”. When you press the letter “w”, it highlights the following: “are a”. Note that it includes a space and the letter a.

So the letter “w” is the wrong key to use, so what is the key to go to the end of the word instead?

It’s the letter: e

This book was a pretty good book for what it is. It’s a very small book, so you really can’t expect much. It’s catered towards teenagers in school and you can read it in about a day. The contents are about how to save up for retirement, basically. If you do it soon enough, and correctly, you can have about a million dollars or more. The critical ideas are: mutual funds, 401Ks, roth IRAs, and insurance.  I recommend it if you don’t know anything about finances or about where to put your money. Even if you don’t have any money, you can still save up, but the key is to do it early enough (when you’re young).

2) 3/5 The Complete Idiot’s Guide to String Theory (978-1592577026)

Amazingly, there aren’t any equations. There are good and bad parts and I get lots quite often. Mainly when he says “The blank-blank theory says this”… But doesn’t leave any references to say why, because I don’t know where he gets quite a few of his statements. The author is probably correct, because I don’t know any better. On a good note, the appendix has a wealth of really good links and info if you want more info. Overall, so far, it’s ok. But there’s got to be a book that explains it better. It does make some things clearer though, but I guess it’s just piecing things together piece by piece, but you will probably need other resources to complete the picture. This book just feels like a bunch of random physics statements thrown together.

3) IN PROGRESS 5/5 The Holy Bible

I won’t be reading all of it, but I will be reading all of the main narrative books that go through the main story. So far, the story is very unique and inspiring. You can’t really attempt to understand it by yourself unless you’re a history buff and know what was going on in the time period. Also knowing which books were written in which time period is very helpful as well. Who was in world power, where the old nations were located, etc. I have quite a few resources and help to figure things out, so if a regular person picked up the bible and started reading it, they’d most likely miss a good portion of the important things that require an understanding of real history. This will always be “in progress.”

big_huge_array_with_a_big_long_name[ indexThingy ] = 5;

If the cursor is at the beginning of the line, and we want to change the name of the array completely, we could type this:

df[

This will delete all the way to the bracket. Unfortunately, it deletes the bracket.
So instead, this works nicely to NOT remove the character you type:

dt[

This will delete every character up until the bracket, but leave the bracket. How nice.
So what does this “t” movement key do exactly?
It simply moves the cursor to the character right before the one specified, and it stays in “normal” mode.
If you wanted to immediately type after deleting the characters, you would use the following:

ct[

Which will delete the text, leave the “[” character, but change to insert mode right before the “[” character.

Another thing you can do is type:

de

/Ctrl-r Ctrl-w

If you want to maximize your vertical or horizontal buffer splits, type one of the following:

Ctrl-w|
Ctrl-w_

If you want to equally resize all of your buffers, type the following:

Ctrl-w=

To make a vertical split a horizontal one, or visa versa, type the following:

Ctrl-w H
Ctrl-w K

To center the cursor on your screen, press:

zz

To bring up the build in “file explorer” window, type one of the following:

:E
:Ex
:n .