HackerTube.dev

The Forgotten Art of Structured Programming - Kevlin Henney [C++ on Sea 2019]

cpponsea · 245.1K views · 2019-02-15 · 1:29:27

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

Kevlin Henney revisits structured programming, from Go To Statement Considered Harmful to block-structured code and object orientation. He argues it still matters for how we write code today.

On Hacker News

HN commenters point to it in discussions of goto, early returns and cognitive load when reading code.

Recommended by 2 HN people across 2 months · HN mentions 2021–2022

Topics

Search by tags

What people said

jiggawatts · 2021-07 · Recommendation

I get that, but the comment was specifically about pointers (not gotos or structure), and is interesting in general from a historical perspective. The "goto" keyword is similarly dangerous. I've seen very good arguments for leaving it out, and generally poor arguments for keeping it in a language. "I can use it safely" is not a good argument, because it's just like Jim Jefferies' standup routine linked above: "Why should I have my guns taken away from me?" An example of a good argument for structured programming is the talk "The Forgotten Art of Structured Programming - Kevlin Henney [C++ on Sea 2019]": [VIDEO] Similarly, this article makes a very good argument that concurrent or async code is essentially the "goto spaghetti reinvented, but even worse ", and that Structured Concurrency is the solution: [LINK]

Read the original HN comment ↗
kbenson · 2021-04 · Recommendation

If you haven't seen it, Kevlin Henney's talk about "The Forgotten Art of Structured Programming"[1] is interesting (if somewhat long in the examples later), and somewhat related. It's not specifically about return early (and a case could be made that it should or should not apply specifically to early return), but it is about if, else, return, and how they affect cognitive load when reading code. 1: [VIDEO]

Read the original HN comment ↗
shadowofneptune · 2022-09 · Reference

For some of these reasons, I prefer to write this: if (condition) { throw } else { <rest of code> } Rather than: if (condition) { throw } <rest of code> The justification, which I found in this presentation ( [VIDEO] ) is that if you only looked at the block structures, could you tell that the rest of the code might never run?

Read the original HN comment ↗

Sources

Video by cpponsea, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources