Check every item from left to right until you find the key or run out. Works on any array, sorted or not, but costs O(n).

• ✗Returning -1 inside the loop (in an else), which stops after checking only the first item.
• ✗Looping with i <= n, one past the end.
• ✗Forgetting that an unsorted array cannot use binary search.

On a sorted array, check the middle, then throw away the half that cannot contain the key. Each step halves the problem, so it takes O(log n).

• ✗Using while (low < high) instead of low <= high. That misses a key when one item is left.
• ✗Setting low = mid or high = mid instead of mid ± 1, which can loop forever.
• ✗Running it on unsorted data. The result is meaningless.

Find the smallest remaining item and swap it to the front. Repeat. Simple, at most n − 1 swaps, but always O(n²) comparisons.

• ✗Swapping inside the inner loop every time a smaller item is found. Swap once, after the inner loop.
• ✗Starting the inner loop at j = i instead of j = i + 1 (compares an item with itself).
• ✗Claiming selection sort has an O(n) best case. It has none; it always scans.

Compare neighbours and swap them if they are out of order. After each pass the biggest remaining item has "bubbled" to the end.

• ✗Looping j up to n - 1 in every pass instead of n - 1 - i. It still works, but does useless comparisons.
• ✗Writing a[j] >= a[j+1]. Swapping equal items breaks stability.
• ✗Reading past the array with j < n and then accessing a[j + 1].

Grow a sorted part on the left by inserting each new item into its correct place, like sorting cards in your hand. Fast on nearly sorted data.

• ✗Writing a[j] >= key in the while loop. That breaks stability.
• ✗Forgetting j >= 0 in the loop condition, which reads a[-1].
• ✗Putting a[j + 1] = key inside the while loop. It goes after the loop.

When records are big, don't move them. Sort an array of pointers (or indices) to the records instead, and only small addresses get swapped.

• ✗Swapping the records (swap(*p[i], *p[min])) instead of the pointers (swap(p[i], p[min])). That defeats the purpose.
• ✗Comparing the pointers themselves (p[j] < p[min]) instead of what they point to (p[j]->score).
• ✗Forgetting to initialise p[i] = &s[i] before sorting.

Insertion sort on items a gap apart, with the gap shrinking to 1. Far-away items move in big jumps, so the final insertion sort has little work left.

• ✗Comparing neighbours (gap 1) in every pass, which is just insertion sort.
• ✗Forgetting that the last pass must use gap = 1, or the array may not be sorted.
• ✗Claiming it is stable. Jumps over a gap can reorder equal keys.

Split the array in half, sort each half recursively, then merge the two sorted halves. Always O(n log n), stable, but needs O(n) extra space.

• ✗Forgetting to copy the leftover items after one half runs out.
• ✗Using < instead of <= in merge, which breaks stability.
• ✗Base case lo > hi only. A single item (lo == hi) must also stop the recursion.

Pick a pivot, partition so smaller items go left and bigger items go right, then sort each side recursively. Average O(n log n), worst O(n²).

• ✗Recursing on (lo, p) instead of (lo, p − 1). The pivot is already in place.
• ✗Forgetting the final swap(a[i + 1], a[hi]) that puts the pivot in place.
• ✗Saying quick sort is always O(n log n).