Obviously yes. They all routinely treat my "thingsByID" array like a dictionary - it's a compact array where ID = index though.

They even screw that up inside the tiny function that populates it. If anything IMO, they over-value names immensely (which makes sense, given how they work, and how broadly consistent programmers are with naming).

▲

gnulinux 4 days ago | parent | next [-]

Do you still have this problem if you add a comment before declaring the variable like "Note: thingsById is not a dictionary, it is an array. Each index of the array represents a blabla id that maps to a thing"

In my experience they under overvalue var names, but they value comments even more. So I tend to calibrate these things with more detailed comments.

▲

bluefirebrand 3 days ago | parent [-]

Can't you just write the code instead of the more detailed comments? What is the benefit of this approach?

▲

lazide 3 days ago | parent | next [-]

Have you ever been vacuuming, and ran across a little thing on the floor that refuses to get picked up (a small piece of metal or whatever), and spent 5x more time trying to get the vacuum to work than it would have taken to just pick it up and throw it away?

And then eventually reach down and pick it up - to feed it to the vacuum?

That is what this reminds me of.

▲

gnulinux 3 days ago | parent | prev [-]

You can fix the code of course. I just experiment with what sort of comments produce better code. In my experience, heavily commented code is handled by LLMs significantly better. So the total quality of comments eventually add up, if you're planning to use an LLM in a project in the long term, it pays off to comment it for LLM's context.

	▲	2 days ago \| parent \| next [-]
		[deleted]
	▲	2 days ago \| parent \| prev [-]
		[deleted]

▲

partdavid 2 days ago | parent | prev | next [-]

I get what you're saying, but what's interesting to me is that this case is a mild signal that a subsequent developer could take the same erroneous implication. "Id" does in fact imply to me that entries are indexed by "Id", i.e., an attribute of the item being indexed, and that they are not array-like, in that they wouldn't all get different IDs by a deletion, for example.

▲

DullPointer 4 days ago | parent | prev | next [-]

Curious if you get better results with something like “thingsByIdx” or “thingsByIndex,” etc.?

▲

delifue 3 days ago | parent | prev [-]

Did you add the type annotation of it in code?

	▲	Groxx 3 days ago \| parent [-]
		This is in Go, so both "yes" (it's defined with an explicit type in the file, sometimes the same func) and "yes but" (afaict next to no code-agent looks at type information that e.g. gopls has readily available, or even godoc).