
A rewrite of this recipe, incorporating comments. Does anybody remember problems in which rotating and reflecting directions really helps?
Problem
One of most common graph representations in TopCoder problems is square grid graph, with vertices corresponding to cells of a grid, and edges connect vertices in adjacent cells (and sometimes other pairs of vertices, depending on the problem statement). Such structure of a graph allows a lot of small tricks that simplify and standardize processing it. Note that grid processing is rarely the main part of the problem, but having it standardized as much as possible helps concentrate on actual problem solving instead of coding.
Solution
Grid graphs are usually rectangular ones, given as an array of strings, where each character is one grid cell and one graph vertex. If the grid describes some kind of a maze, with impassable cells, such cells simply don't have a corresponding vertex (or have a vertex without edges leading to it  whichever way of thinking about it you prefer). The most common case of edges is vonNeumann neighborhood, when edges connect vertically and horizontally adjacent cells. Sometimes diagonally adjacent cells are added to form Moore neighborhood, and in rare cases other types of neighborhood are introduced.
In case of grid representation, graphs are rarely converted to explicit lists of vertices and edges; instead they are processed based on the original grid. The usual task is graph traversal (as part of finding the shortest path of some kind). For it, we need to be able to find all vertices which are adjacent to a certain vertex. For vonNeumann neighborhood a cell in row i and column j (denoted as (i,j)) has four adjacent vertices  (i+1,j), (i1,j), (i,j+1) and (i,j1). They can be processed explicitly, by coding processing of each cell separately (we're not giving the code, so that you don't think that's the advice!). However, this method requires a lot of copypasting (especially for larger neighborhoods) and is really errorprone  editing copypasted code adds small typos easily, and testing might not reveal them.
A much cleaner and safer way to process grid graphs is the following. Introduce arrays of deltas drow and dcol, which contain offsets of adjacent cells (relative to main cell). After this, you will be able to process all adjacent cells in a loop:
for (k=0; k<drow.size(); k++)
{ //process cell (row+drow[k], col+dcol[k])
...
}
Alternatively, you can skip forming arrays (which might be tricky for nonstandard grids) but instead loop through all possible values of drow and dcol and reject those which don't result in valid adjacent cell (see the table for clarification).
This technique is universal and applicable to all gridbased graphs and neighborhoods on them, regardless of shape of the grid. The exact values of drow and dcol for nonstandard grid might depend on its representation. It's a good idea to have values of deltas for main grid shapes prewritten and use them as required instead of reinventing them each time. (this should be a table, with images showing the neighborhoods, matching values of drow and dcol and matching loops; it will look more neat than it does now) _________________________________________ vonNeumann
drow = {1, 0, 1, 0} dcol = {0, 1, 0, 1}
for (drow=1; drow<=1; drow++)
for (dcol=1; dcol<=1; dcol++)
if (abs(drow)+abs(dcol)==1)
//...
_________________________________________ Moore
drow = {1, 1, 1, 0, 1, 1, 1, 0} dcol = {1, 0, 1, 1, 1, 0, 1, 1}
for (drow=1; drow<=1; drow++)
for (dcol=1; dcol<=1; dcol++)
if (abs(drow)+abs(dcol)>0)
//...
_________________________________________ triangular grid (TrianglesBoard)
> c  /\  /__\ \/ /\ /\ /__\/__\ r /\ /\ /\ /__\/__\/__\
for cell board[i][j] adjacent ones will be [i][j1], [i][j+1] and [i1][j1] for odd j and [i+1][j+1] for even j _________________________________________
hexagonal grid (Hex) coordinates are (diagonal distance, vertical distance)
\ __ _\ d  /a \__  \__/d \__ \/ /b \__/g \__ \__/e \__/l \ v /c \__/h \__/ \__/f \__/ \__/
dd = { 1,1,0,1,1, 0} dv = {1,0,1, 1, 0,1} _________________________________________
hexagonal grid (ExploringHoneycombs) coordinates are (row, column)
> c __ __  /a \__/g \__  \__/d \__/k \ \/ /b \__/h \__/ \__/e \__/l \ r /c \__/j \__/ \__/f \__/m \ \__/ \__/
drow0 = { 1, 1, 0, 0, 1, 1 } (for even columns) drow1 = { 1, 1, 0, 0, 1, 1 } (for odd columns) dcol = { 0, 0, 1, 1, 1, 1 } _________________________________________
3D rectangular grid (LightsCube)
for (dx=1; dx<=1; dx++)
for (dy=1; dy<=1; dy++)
for (dz=1; dz<=1; dz++)
if (abs(drow)+abs(dcol)>0)
//...
_________________________________________
Chess knight move (ChessKnight)
drow = { 1, 2, 2, 1, 1, 2, 2, 1 } dcol = { 2, 1, 1, 2, 2, 1, 1, 2 }
for (drow = 2; drow <= 2; drow++)
for (dcol = 2; dcol <= 2; dcol++)
if (abs(drow*dcol) == 2)
//...
_________________________________________
Another trick helps treating boundary conditions. See, cells which are in row 0 or R1, or in column 0 or C1, have less neighbors than central ones. Trying to use a generic formula and to access cells outside of the grid results in an error, and it might be tiresome to check whether the cell is within the grid each time it is accessed. This can be avoided by padding the original grid with rows and columns of impassable cells on each side. This way, the border cells are guaranteed not to be reached, so boundary checks can be omitted. 