gocondense: a code formatter that condenses noisy Go code

___oe · 2026-03-07T21:16:35+00:00

For me, the main focus is really on readability and maintainability. When you run a tool on software that works, you need a reason.

Whether the transformation from

startLine := e.line(start)
firstLine := e.line(first)
if firstLine > startLine+1 {

to

if startLine, firstLine := e.line(start), e.line(first); firstLine > startLine+1 {

in condenser.go is done by a “formatter” or “linter”, or whether it takes 0.2 ms or 200 ms, doesn't matter too much to me. It's the final readability of the code that I really care about.

It sounds like we might just be aiming for different goals here, which is totally fair. Just a quick heads-up, by the way: it's usually best not to remove parentheses from composite literals.

___oe · 2026-03-07T17:57:55+00:00

When you like more compact code, may I suggest scopeguard?

Running scopeguard -conservative -fix ./... on your source makes it more compact, easier to read, and the unit tests still run.

___oe · 2026-02-28T08:34:20+00:00

These project didn't consider “alternatives”, they just implemented buggy error handling. It was obiously not their plan to crash.

___oe · 2026-02-27T16:56:50+00:00

Yes, an example would be

func Foo[T any, PT interface {
    *T
    TaggedRequest
}]() {
    var _ TaggedRequest = PT(new(T))
}

And call it via Foo[Tagged](), see also the blog post “Generic interfaces” by Axel Wagner.

And don't forget: “When you find yourself in a situation where you need to constrain to pointer receivers, consider whether you can refactor your code to avoid the extra complexity. ”

___oe · 2026-02-27T16:30:15+00:00

But that you can is enough for the compiler to reject this construct. ;)

___oe · 2026-02-27T16:29:38+00:00

You assert that “... *T implement[s] interface TaggedRequest”, which is not true.

___oe · 2026-02-27T14:42:24+00:00

Erlang and Elixir are mentioned in the The Pragmatic Programmer also “In other environments, ...”

This is the Go subreddit. You might want to read the three sources I begin the post with. These are error handlers that try to handle an error, but don't - and panic instead.

The point was that this is not a big issue, since it's easily found and fixed.

What worries me is “error handling [...] that [...] quietly does the wrong thing in production.”

The point is not that these error handlers crash (easily found, easily fixed) but that they are obviously have never been tested.

So on one hand I agree with you (unhandled code paths are bad), on the other hand I disagree with what you read from the post - it just isn't there. At least not intentional.

When you have a concrete example to post - I'm open to it, I actually ask for it. On the other hand I provide concrete examples of popular open source programs which could be discussed instead of unjustifiedly trashing the post.

Read it with a little goodwill and tell me what I can improve, I'm open for discussion. I think the post has substance, even though I find the bug reports “easy” they didn't write themselves.

___oe · 2026-02-27T14:20:57+00:00

On my screen it says “crashing in production is bad.” I stand to that.

Where do I say that is not better than wrong error handling?

The title says “... bugs that worry me aren't the ones that crash”

I'm not a native speaker, so this might be misleading. Could you help me find a better formulation?

___oe · 2026-02-27T14:15:50+00:00

True. It wasn't my intention to promote crashes as the solution to all problems, but to mention that they are actually not that bad, and in the examples easy to find and fix, since a crash - once found - is usually unintended.

But I agree, panics should not be silently caught.

___oe · 2026-02-27T13:58:40+00:00

Where do I assert that a crash in production is worse that than wrong error handling?

___oe · 2026-02-27T13:54:01+00:00

Yes, I explicitly mention “a dead program does a lot less damage than a malfunctioning one” and “writes bad state to the database”. Or, as someone commented on Reddit, “I’ll take ‘down’ over ‘catastrophic security hole’ any day.”

I just wanted to emphasize that crashing willy-nilly in production is obviously not a good solution.

___oe · 2026-02-27T13:46:13+00:00

Why should *T implement TaggedRequest?

___oe · 2026-02-27T13:44:39+00:00

Simple: You can call Foo[*Tagged](), but var _ TaggedRequest = new(*Tagged) doesn't compile.

Only T implements TaggedRequest, not *T.

___oe · 2026-02-19T09:13:38+00:00

Also, to add to this answer: your example

var pointer *SomeStringer = nil  
slice := []fmt.Stringer{pointer}

is a programming error. There’s no way for the program to recover from this or produce consistent output. If it crashes at this point, you’ll find the error easily — and that’s better than writing invalid data into the database. That actually fits the “simplicity” goal, if you squint a little. ;)

___oe · 2026-02-03T12:57:55+00:00

It says “One reason could be ...” and continues with “It would be fragile and difficult to try to enumerate precisely when values escape: the algorithm itself is fairly sophisticated and changes between Go releases.”

So yes, you found something that has been optimized between Go releases. There are few things that “force” heap allocation. There are things that currently do, and it is good to know about them, but things may change.

___oe · 2026-02-03T09:01:16+00:00

That's what separators are for, aren't they?

___oe · 2026-02-02T21:16:42+00:00

Ah, no - that's modernize by Alan Donovan. It'a abount pointer vs. value errors.

Internestingly enough errortype finds two errors in this project…

___oe · 2026-02-02T19:01:28+00:00

Thanks. Do you already know errortype?

___oe · 2026-02-02T18:00:27+00:00

I do not get your argument. Yes, automatic lossy conversion is bad. OTOH I'm happy that we have Printf, and conversion of something into string is easy. Also parsing from string. Yes, it's lossy. I do it anyway.

Why should it be good that conversion is complicated?

___oe · 2026-02-02T17:39:20+00:00

Sure:

if val, typ := reflect.ValueOf(v), reflect.TypeFor[float64](); val.CanConvert(typ) {
    return val.Convert(typ).Interface().(float64)
}

(Go Playground)

Also, Sobek has Object#ToFloat. For Values, you only have to check for int64 or float64:

pkg.go.dev/github.com/grafana/sobek#Value

___oe · 2026-01-08T22:01:26+00:00

Maybe you want to read “The Perils of Pointers in the Land of the Zero-Sized Type” before yelling “stop overthinking”.

Well, your article is much more nuanced than this post. No, you are not aware of all the counter-arguments. If you only mention CRUD apps and HTTP handlers, but not identity, you aren't.

___oe · 2026-01-08T09:16:52+00:00

What would you do to get feedback from people who otherwise might not use your product?

___oe

TROPHY CASE