Admittedly this may not be the best choice of words... but it was a good trade-off of length/clarity at the time for me.
The longer version is: an _ideal_ programming language (from the perspective of debugging, though not all other perspectives) would just allow a full reverse playback through time from the point-of-failure to an arbitrary point in the past. A (small) step towards that is the "Breadcrumb" as introduced by Sentry; a hint at what happened before an error occurred. I argue that, in the coding-style as discussed, and when exposing local variables in stacktraces, local variables actually serve as breadcrumbs, albeit not explicitly set using the breadcrumb-tooling.
> along with a print statement
yeah but the point is that in this combination of coding style and tooling print statements become redundant
> third-party addon called Bugsink
If by third-party you mean "the data flows to a third party" you're mistaken, Bugsink is explicitly made to keep the data with you. If by "third party" you mean "not written by either myself or the creators of my language of choice, you're right.
Right now the code is clear. After you’ve had your morning coffee, and read my PR description. How about at 5:05 when you’re trying to get to your kid’s soccer game and there’s a production issue? After I merge this you’re never going to look at this code again when there isn’t something else going on. A bug or a feature you’re trying to wedge into this code.
header = {"name": "Unknown"}
body = {"items": []}
footer = {"page": 0}
placeholder = {
"header": header
"body": body
"footer": footer
}
return(placeholder)
What? For whom? I've been extremely intentionally breaking up longer expressions into separate lines with local variables for a long time.
Writing local variables as "breadcrumbs" to trace what happens is one of the very first things new developers are taught to do, along with a print statement. I'd wager using a "just to break things up" local variable is about as common as using them to avoid recomputing an expression.
... Perhaps the author started out with something in the style of Haskell or Elm, and casual/gratuitous use of named local variables is new from that perspective?
> However, the local variables are a different kind of breadcrumbs. They’re not explicitly set by the developer, but they are there anyway.
While I may not have manually designated each onto a "capture by a third-party addon called Bugsink" whitelist, each one is very explicitly "set" when I'm deciding on their names and assigning values to them.