NOLOCK aka READ UNCOMITTED aka "dirty read"

Allows reading a table in spite of any uncommitted transactions that may be in progress on other connections.

Pro: It saves time by not creating locks, and by not waiting for or blocking other transactions.  It only requires a schema lock on the table, rather than creating locks for all the rows/pages/extents that are read.  It ignores exclusive locks owned by other connections instead of waiting for those transactions to complete.

Cons: You can read data from partially completed transactions, then those transactions may be rolled back and the data disappears.  For instance, you have a query WITH(NOLOCK) to sum the sales for each salesman to calculate commission payments.  Just before you run this, someone begins a transaction showing they sold the Brooklyn Bridge for $2 billion.  After your comission query runs and calculates a huge bonus for this guy, the transaction is rolled back and there is no trace of the data to explain what happened to the accountants.

It is very useful for reporting queries on production databases, if you know that either the data you're reading is static or you don't mind having counts and totals being a little off.  A history table that sees INSERTs but no UPDATEs for example, or maybe a query summarizing last week's data when only today's data might be volatile.  An inventory query that is checking whether there are less than 5000 #8 wood screws on hand to decide when to reorder is not going to notice the difference between 3875 and 3750.

It obviously is not recommended for accounting, or any application where exact numbers are required.  An inventory query that is a little fuzzy about whether there should be 2 or 3 Ferraris on the showroom floor is a bad idea.