3 ms·

Regarding your variable naming: why `price_prediction_calculator_settings' and not, say `settings'? Same with the type; why not: class PricePredictor:

Regarding your variable naming: why `price_prediction_calculator_settings' and not, say `settings'? Same with the type; why not: class PricePredictor: class Settings: def __init__(self, x: int, y: int): self.x = x self.y = y def __init__(self, settings: Settings): self.x = settings.x ...

nerdponx 9y ago
That battle was lost before I even had a chance to fight it.
backslash_16 9y ago
I'm curious why about why you don't like that name? I'm asking because I'm usually torn between short names that assume the reader can understand them and long overly descriptive names that (in theory) require less implicit understanding. Is the name price_prediction_calculator_settings too long? If we call it settings I can see an issue come up if we need to pass in another type of settings object calculator_format_settings or something like that.
- KingMob 9y ago
  This is one of those areas where you're actively being hurt by the need to name something or give it a type. Wouldn't passing in a simple dictionary for the settings be simpler? Something called PricePredictionCalculatorSettings probably isn't being reused elsewhere.
  - nerdponx 9y ago
    The whole idea was to get away from passing dictionaries around. There's no IDE support for "plain" dictionaries, they resulted in code duplication and broken encapsulation since you can't add any logic to a dictionary, and they put unnecessary cognitive load on the developer by forcing them to keep track of which fields go in which dictionary. I saw it as a form of design-by-contract and self-documenting code. The app I worked on had a ton of these mappings being passed around between different subsystems and it was becoming nightmarish to deal with. With this style, if you were on Team A and needed to plug your work into Team B's FooBar class, all you had to do was look at the FooBarInputData class to see exactly what the FooBar class needs.
    - KingMob 9y ago
      Interesting point. If you were using Clojure I'd suggest checking out Schema and spec. They allow you to define the expected fields of a map/dictionary, without requiring a full type, which is handy for well-defined data objects without attached behavior.
- xapata 9y ago
  Overly-long names are an indication that the design could use some refactoring. There's a tradeoff between variable name length and the amount of readable logic you can fit into a line. The name ``settings`` is too generic. There's probably a better way, but to demonstrate that we'd need a real example and not hypothetical.
- proaralyst 9y ago
  Long names require lots of keystrokes and more reading effort. Also you have to split your lines earlier. If I have long names, I won't remember what I called things, at which point I'm leaning on autocompletion. Hitting tab every few keystrokes really takes me out of my flow. The other general issue is why have the redundancy? There's only one settings object here. If you need to pass something different in later, refactor! Remember the principle of You Ain't Gonna Need It.

nerdponx 9y ago

That battle was lost before I even had a chance to fight it.

backslash_16 9y ago

I'm curious why about why you don't like that name? I'm asking because I'm usually torn between short names that assume the reader can understand them and long overly descriptive names that (in theory) require less implicit understanding. Is the name price_prediction_calculator_settings too long? If we call it settings I can see an issue come up if we need to pass in another type of settings object calculator_format_settings or something like that.

KingMob 9y ago
This is one of those areas where you're actively being hurt by the need to name something or give it a type. Wouldn't passing in a simple dictionary for the settings be simpler? Something called PricePredictionCalculatorSettings probably isn't being reused elsewhere.
- nerdponx 9y ago
  The whole idea was to get away from passing dictionaries around. There's no IDE support for "plain" dictionaries, they resulted in code duplication and broken encapsulation since you can't add any logic to a dictionary, and they put unnecessary cognitive load on the developer by forcing them to keep track of which fields go in which dictionary. I saw it as a form of design-by-contract and self-documenting code. The app I worked on had a ton of these mappings being passed around between different subsystems and it was becoming nightmarish to deal with. With this style, if you were on Team A and needed to plug your work into Team B's FooBar class, all you had to do was look at the FooBarInputData class to see exactly what the FooBar class needs.
  - KingMob 9y ago
    Interesting point. If you were using Clojure I'd suggest checking out Schema and spec. They allow you to define the expected fields of a map/dictionary, without requiring a full type, which is handy for well-defined data objects without attached behavior.
xapata 9y ago
Overly-long names are an indication that the design could use some refactoring. There's a tradeoff between variable name length and the amount of readable logic you can fit into a line. The name ``settings`` is too generic. There's probably a better way, but to demonstrate that we'd need a real example and not hypothetical.
proaralyst 9y ago
Long names require lots of keystrokes and more reading effort. Also you have to split your lines earlier. If I have long names, I won't remember what I called things, at which point I'm leaning on autocompletion. Hitting tab every few keystrokes really takes me out of my flow. The other general issue is why have the redundancy? There's only one settings object here. If you need to pass something different in later, refactor! Remember the principle of You Ain't Gonna Need It.