News for hackers. Stuff that matters.
Re:Go Naming Conventions: A Practical Guide by zer00eyz on Saturday March 28, 2026 @12:47PM (#47556238)
> I think this may be related to how people read code. You have people who scan shapes, and then you have people who read code almost like prose.

I think this is an astute observation.

I think there is another category of "reading" that happens, is what you're reading for "interaction" or "isolation".

Sure c.method is a scalable shape but if your system deals with Cats, Camels, Cars, and Crabs that same c.method when dealing with an abstract api call divorced from the underlying representation might not be as helpful.

I would think that we would have more and better research on this, but the only paper I could find was this: https://arxiv.org/pdf/2110.00785 its a meta analysis of 57 other papers, a decent primer but nothing ground breaking here.

> I scan shapes. ... verbal description.

I would be curious if you frequently use a debugger? Because I tend to find the latter style much more useful (descriptive) in that context.

Re:Go Naming Conventions: A Practical Guide by bborud on Saturday March 28, 2026 @01:19PM (#47556568)
dealing with an abstract api call divorced from the underlying representation

I don't understand what you mean. Could you give me an example?

I would be curious if you frequently use a debugger?

I practically never use a debugger.

Re:Go Naming Conventions: A Practical Guide by functional_dev on Saturday March 28, 2026 @01:30PM (#47556648)
The shape argument works well in small packages but it starts to fail once you have multiple domain models starting with the same letter
Re:Go Naming Conventions: A Practical Guide by bborud on Saturday March 28, 2026 @05:21PM (#47558211)
I wasn’t talking about just symbols but entire paragraphs of code as well.