3 ms·

What constitutes an overly long name for you? Are you talking Java-y things likes `UserAccountBuilderFactoryFactory` or even just something like `operation` in

What constitutes an overly long name for you? Are you talking Java-y things likes `UserAccountBuilderFactoryFactory` or even just something like `operation` instead of `op`?

CuriousCosmic 3y ago
not OP but I think even just `operation` vs `op` should be self explanatory for the majority of devs. And documentation can dispel any doubt regarding the interpretation of the name. Terse naming is just fine as long as the names are visually distinct from those in the same scope/namespace and as long as engineers/developers are religious about proper documentation. i.e. members/classes/types/fn/etc getting a doxy/doc description and local variables getting a `//` comment if their meaning and use isn't easily derivable from the immediate context. If that isn't happening however, you probably need to be pushing for more descriptive names or better docs during code review.
- sodapopcan 3y ago
  It's self-explanatory for sure, but I would prefer the actual domain term be Op as well. IE, I really dislike `op = Operation.new()` or whathaveyou. This breaks stuff like editor highlighting and whatnot. It's also harder to keep consistency through a codebase. Like maybe some people do `o = Operation.new()`. I find very high cohesion here helps my code-scanning a ton. I'm not saying that would be true for anyone, just furthering my premise that it's different for everyone.
ziml77 3y ago
For the `operation` vs `op` example, it's highly contextual. If it's used in a narrow scope or if it's repeated many times (like I've seen in functions that copy fields of one structure to another), `op` is preferable. Otherwise I'm fine with `operation`. The Java naming is one cause of what I really have a problem with. Like that name on it's own isn't the worst because the key info is right at the start and I'm probably not going to see the type name in function bodies I'm trying to follow. It's when that naming is combined with other overly verbose naming that it gets really gets bad: `CreateUserFromUserAccountBuilderFactoryFactoryOnBackgroundThread()` By the time I've read "BackgroundThread" I'm glancing backwards to see what is happening on the background thread. Other places where longer names make reading harder are when the names are very similar. With `textBoxXPosition` and `textBoxYPosition` the X and Y get lost too easily. You could rearrange the letters to the front to help with that, but it can still make computations harder to read: `sqrt(xTextBoxPosition * xTextBoxPosition + yTextBoxPosition * yTextBoxPosition)` vs `sqrt(x * x + y * y)` or `sqrt(tbx * tbx + tby * tby)`
- sodapopcan 3y ago
  I think we're mostly in agreement here, thanks for sharing! I actually always write full variable names, even in narrow scopes. This is mostly because I'm used to programming in dynamic languages and it makes renaming much easier. I've also become so accustom to it that it makes scanning incredibly fast. For example: Enum.map(operations, fn operation -> execute(operation) end) I can pretty much just read the left-hand side of that if I'm scanning really quickly, ie, ignore everything after `fn`. I'm talking micro-optimizations here, but I have been tripped up before when someone did something like `optn`. Elixir allows for a shorthand notation for anonymous functions like so: Enum.map(operations, &execute(&1)) Some people hate that but again I like it due to the refactoring advantages (it becomes very simple to read once you get used to it). I hear you on the x/y thing. You example is actually why I really prefer snake case, though I don't want to start a flame war there, haha. But ideally when you're dealing with points and dimensions you wrap them in a type or object that you can pass around and the receivers can extract simple `x` and `y` variables from them.

What constitutes an overly long name for you? Are you talking Java-y things likes `UserAccountBuilderFactoryFactory` or even just something like `operation` instead of `op`?

CuriousCosmic 3y ago

not OP but I think even just `operation` vs `op` should be self explanatory for the majority of devs. And documentation can dispel any doubt regarding the interpretation of the name. Terse naming is just fine as long as the names are visually distinct from those in the same scope/namespace and as long as engineers/developers are religious about proper documentation. i.e. members/classes/types/fn/etc getting a doxy/doc description and local variables getting a `//` comment if their meaning and use isn't easily derivable from the immediate context. If that isn't happening however, you probably need to be pushing for more descriptive names or better docs during code review.

sodapopcan 3y ago
It's self-explanatory for sure, but I would prefer the actual domain term be Op as well. IE, I really dislike `op = Operation.new()` or whathaveyou. This breaks stuff like editor highlighting and whatnot. It's also harder to keep consistency through a codebase. Like maybe some people do `o = Operation.new()`. I find very high cohesion here helps my code-scanning a ton. I'm not saying that would be true for anyone, just furthering my premise that it's different for everyone.

ziml77 3y ago

For the `operation` vs `op` example, it's highly contextual. If it's used in a narrow scope or if it's repeated many times (like I've seen in functions that copy fields of one structure to another), `op` is preferable. Otherwise I'm fine with `operation`. The Java naming is one cause of what I really have a problem with. Like that name on it's own isn't the worst because the key info is right at the start and I'm probably not going to see the type name in function bodies I'm trying to follow. It's when that naming is combined with other overly verbose naming that it gets really gets bad: `CreateUserFromUserAccountBuilderFactoryFactoryOnBackgroundThread()` By the time I've read "BackgroundThread" I'm glancing backwards to see what is happening on the background thread. Other places where longer names make reading harder are when the names are very similar. With `textBoxXPosition` and `textBoxYPosition` the X and Y get lost too easily. You could rearrange the letters to the front to help with that, but it can still make computations harder to read: `sqrt(xTextBoxPosition * xTextBoxPosition + yTextBoxPosition * yTextBoxPosition)` vs `sqrt(x * x + y * y)` or `sqrt(tbx * tbx + tby * tby)`

sodapopcan 3y ago
I think we're mostly in agreement here, thanks for sharing! I actually always write full variable names, even in narrow scopes. This is mostly because I'm used to programming in dynamic languages and it makes renaming much easier. I've also become so accustom to it that it makes scanning incredibly fast. For example: Enum.map(operations, fn operation -> execute(operation) end) I can pretty much just read the left-hand side of that if I'm scanning really quickly, ie, ignore everything after `fn`. I'm talking micro-optimizations here, but I have been tripped up before when someone did something like `optn`. Elixir allows for a shorthand notation for anonymous functions like so: Enum.map(operations, &execute(&1)) Some people hate that but again I like it due to the refactoring advantages (it becomes very simple to read once you get used to it). I hear you on the x/y thing. You example is actually why I really prefer snake case, though I don't want to start a flame war there, haha. But ideally when you're dealing with points and dimensions you wrap them in a type or object that you can pass around and the receivers can extract simple `x` and `y` variables from them.