Pseudocode is, as the name implies, not real code, but it looks like code. It helps people to understand a problem domain or solution better without having to add all the baggage necessary when using a real language.
In short: it's used only for illustrational purposes.
Pseudocode and programming
There is no definition or fixed rule of pseudocode, it can be different each time. It is not a (real) programming language and no-one will consider it one. It cannot be compiled or used as a real programming language: if you could do that, it ceases to be pseudocode. Pseudocode does not need to be deterministic (a necessity for computers to compile), it rather needs to be understood by humans. To use pseudocode, you'll have to convert it to your favorite programming language. This conversion process can be different each time and no rules can be given for it because, again, pseudocode is like free speech: it can take any form.
Usages
It is commonly used, especially in the design phase of projects to help understand a certain approach to a problem. It's also commonly used in algorithm design, or when teachers draw something on the board. In all these cases it is not necessary to compile the code, you just want to understand the problem/solution.
Types of pseudocode
Pseudocode can be, but doesn't have to be of a certain type, i.e., you can have a stack-based pseudocode to illustrate MSIL, you can have an imperative pseudocode to illustrate Java, C#, C++, Python, you can have a functional pseudocode to illustrate F#, Haskell, SQL etc.
Examples
From the top of my head, but anything goes, because pseudocode can be invented on the spot:
XML pseudocode, showing a head+body structure that allows for multiple p-elements:
<head ...
<title ...
</
<body ...>
(<p>...)+
</
Imperative pseudocode, showing the diamond problem in languages that support multiple inheritance:
class A() { readFile(); }
class B() : A {} // overrides readFile in A
class C() : A {} // overrides readFile in A
class D() : B, C {} // what definition of readFile should be used?
The above two examples obviously resemble some (type of) language, but aren't really that language and cannot possibly compile. They rather illustrate something that you want to explain.
Flowcharts and pseudocode often have the same level of expressiveness, but differ in linearization. Pseudocode is linear (i.e. a sequence of lines with instructions), a flowchart is not. Therefore, flowcharts are a higher abstraction level, used before writing pseudocode or for documentation.
Flowcharts have, in my opinion, two strong advantages over pseudocode: Firstly, they are graphical. Many non-technical people have a strong fear of structured text, but not of graphical descriptions, so flowcharts will sit much nicer with them. Secondly, flowcharts are much better at expressing meta-considerations such as showing the main line of execution as opposed to branches.
Your questions in detail:
- For a really complicated problem, you would use flowcharts first, then pseudocode. Both are optional when you feel secure enough.
- Yes, pseudocode has the advantage of being mergeable with real code. Steve McConnell, for example, strongly recommends writing methods in pseudocode first and then leaving the pseudocode in the code as comments.
- I always felt that the need to draw a flowchart during design shows insufficient partition of your problem. Non-trivial flowcharts indicate convoluted logic, which should be avoided at great costs.
Best Answer
That line (3) is simply saying initialize the Minimum value to the highest feasible value. In pseudocode that is infinity. If min was UInt32 in real code, then min would be UInt32.Max.
In other words, start off min at a really high value, so when searching iteratively for progressively lower values (by comparing to the previous value), then the first value is something so high that the next value will always become the next min.