There are a number of proven algorithms out there, each with its own advantage, depending on exactly what kind of shortest path you're looking for. I'm going to assume that you have a specific start and end/goal vertex.
- If you have an unweighted graph (no distance on the edges), use a simple breadth-first search, and when you reach the goal, you're done. The pseudocode given by Wikipedia doesn't know to stop when it gets to the goal, so every time you dequeue a vertex, you'll have to check if it's the goal. Where it says process(v), you need to check if v is the goal vertex, and if it is, end the search right there. Also, your vertices need to have a way of knowing what vertex was visited to get to it (which I will call the vertex's parent). After you "mark i as visited," you need to mark v as i's parent. After you find the goal and exit the search, check to see who the goal's parent is, then check to see who that parent's parent is, and keep going until you reach the start vertex, then you will have the path in reverse. Depending on your data structure, this might require recursion or simply a loop.
- If you have a weighted graph (you know the distance between two vertices), use Dijkstra's algorithm, which guarantees the "single-source shortest path" from one start vertex to every other vertex in the graph. Then, you only have to look at the results for the specific goal vertex you have in mind.
Dijkstra's algorithm gets complex and is for more advanced computer programmers. And yes, it is common knowledge that both of these solutions have been proven by their inventors.