Happy Path

The positive path thru a program. The customer logs in, puts an item in their shopping cart, passes their credit card, and buys the item. No typo is committed, no exception is thrown, and no cloud shall blot out the sun.

In terms of a CodingStandard, functions and blocks on the happy path should appear first, preferably in chronological order.

Some crews generally code the HappyPath first. Given a simple method with only happy-path lines, TestDrivenDevelopment makes layering in the SadPaths and error handlers easy. The method should then refactor to IlluminateTheMainline and preserve the happiness of the original method.

See IntegrationTest

Discussion:

Q: Is this pattern in conflict with use if GuardClauses?

A: In the presence of GuardClauses, the HappyPath would be the flow-control path that is not blocked. (Being trapped by guards is usually the beginning of a very long SadPath...). Coding the HappyPath first does not conflict with later integration of GuardClauses.