[flagged]
You're making yourself redundant if you don't keep your actual programming skills sharp.
Go Naming Conventions: A Practical Guide
11–20 of 77 posts
Re: Go Naming Conventions: A Practical Guide
#12> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough.
No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it out as `person`.
Re: Go Naming Conventions: A Practical Guide
#13> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…
Long lines make reading rhythm uncomfortable (long jumps, prolonged eye movements) and long words make the text too dense and slow down the reading. It’s bad typography.
I have heard an idea that a good variable should be understood by just reading its name, out of context. That would make “ProductIndex” superior to “i”, which doesn't add any clarity.
Re: Go Naming Conventions: A Practical Guide
#14> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…
I've felt strongly for a while now that abbreviations should be "lossless" in order to be useful; it should be unambiguous now get back to the unabbreviated form. For whatever reason, people seem to love trying to optimize for character count with abbreviations that actually make things more confusing (like `res` in a context where it might mean either "response" or "result).
I just don't get the obsession with terseness when we have modern tooling. I don't type particularly fast, but autocomplete makes it pretty quick for me to type out even longer names, and any decent formatter will split up long lines automatically in a way that's usually sane (and in my experience, the times when it's annoying are usually due to something like a function with way too many arguments or people not wanting to put a subexpression in a separate variable because I guess they don't know that the compiler will just inline it) rather than the names being a few characters too many.
Meanwhile, pretty much everywhere I've worked has had at least some concerns about code reviews either already being or potentially becoming a burden on the team due to the amount of time and effort it takes to read through someone else's code. I feel like more emphasis on making code readable rather than just functional and quick to write would be a sensible thing to consider, but somehow it never seems to be part of the discussion.
Re: Go Naming Conventions: A Practical Guide
#15> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…
I agree with this comment so much.
Tried to use the new slices package or comparables? It's a nightmare to debug, for no reason whatsoever. If they would've used interface names like Slice or Comparable or Stringable or something, it would have been so much easier.
The naming conventions are something that really fucks up my coding workflow, and it can be avoided 100% of the time if they would stop with those stupid variable names. I am not a machine, and there is no reason to make code intentionally unreadable.
Re: Go Naming Conventions: A Practical Guide
#16[dead]
Re: Go Naming Conventions: A Practical Guide
#17> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…
I've felt strongly for a while now that abbreviations should be "lossless" in order to be useful; it should be unambiguous now get back to the unabbreviated form. For whatever reason, people seem to love trying to optimize for character count with abbreviations that actually make things more confusing (like `res` in a context where it might mean either "response" or "result). I just don't get the obsession with terse…
> and any decent formatter will split up long lines
Any decent editor can wrap long lines on demand. But it's even better not to have to do either of those if not necessary.
> I've felt strongly for a while now that abbreviations should be "lossless" in order to be useful
This is how we got lpszClassName. The world moved away from hungarian notation and even away from defining types for variables in some contexts (auto in cpp, := in Go, var in Java). Often it just adds noise and makes it harder to understand the code at a glance, not easier.
Re: Go Naming Conventions: A Practical Guide
#18[flagged]
> passed to the ai model for the code it generates
AI can't generate code. It only copies it (badly) from somewhere else.
Re: Go Naming Conventions: A Practical Guide
#19> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…
Long lines make reading rhythm uncomfortable (long jumps, prolonged eye movements) and long words make the text too dense and slow down the reading. It’s bad typography. I have heard an idea that a good variable should be understood by just reading its name, out of context. That would make “ProductIndex” superior to “i”, which doesn't add any clarity.
I would argue that ambiguity and uncertainty slow down reading, and more importantly comprehension, far more than a few additional characters.
Re: Go Naming Conventions: A Practical Guide
#20> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough. No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it ou…
Long lines make reading rhythm uncomfortable (long jumps, prolonged eye movements) and long words make the text too dense and slow down the reading. It’s bad typography. I have heard an idea that a good variable should be understood by just reading its name, out of context. That would make “ProductIndex” superior to “i”, which doesn't add any clarity.
A good variable name is the one that is understood by reading it in context, which is why you don't have names like "current_person" or "CurrentIndexOfProductBeingUpdated".