4 ms·

I'm only a begginer, of course, but it seems to be long lines are better than broken ones. `MyDict[family][subfamily][element][property_a][value]` is much bet

I'm only a begginer, of course, but it seems to be long lines are better than broken ones. `MyDict[family][subfamily][element][property_a][value]` is much better imo than: ``` MyDict[family][subfamily][element][property_a][ value ] ``` Probably the data format is what's wrong here in the first place, lol, but anyhow.

wodenokoto 3y ago
When using pandas in Python you are encouraged to keep each “chained operation “ on its own line. (MyDict [family] [subfamily] [element] [property_a] [value] ) I honestly think all suggestions here are equally bad in their own regards.
cerved 3y ago
If a long line can't be hardwrapped nicely at 80 chars, it typically means there's room for improvement in the actual code.
yungporko 3y ago
i'd say that this is much nicer than both. there is always a better option than an abnormally long line. personally i limit my lines to 120 characters MyDict [family] [subfamily] [element] [property_a] [value]
- gverrilla 3y ago
  it's very clear indeed, but makes the code much harder to navigate in my opinion, and makes it look more complex than it really is, particularly for absolute beginners. In python, specifically, where indents matter, these line breaks seem very confusing for those starting to learn.
  - Brian_K_White 3y ago
    Significant whitespace is a python problem not a whitespace problem. I am not one of the ones who cry about Make, but many do and for that reason primarily.
broscillator 3y ago
I don't think the first example is a long line. Imagine opening a book, and to have to read sentences that span both pages rather than just one. It's uncomfortable for the eye and it makes it harder to keep track of the motion of finishing one line on the right, and starting the next one on the left. Similar to how websites employ a lot of white space, imagine if instead the text went from the first pixel on the left to the last one on the right, it feels awkward.
addicted 3y ago
The solution to long lines isn’t to break up the line. The solution would have been (let’s say JS since that’s the most “beginner”ish language where this could even have a perf impact”): const myElement = myDict[family][subfamily][element]; const propValue = myElement[property][value];
dsego 3y ago
Ideally, you would never access deep props like that. First it's easy to make a mistake, and secondly each of those keys can fail if the dict doesn't contain that prop. You probably want to de-structure it first, depending on the language, or use a path getter that has a fallback value (or even better, use strictly defined object types). Long lines are usually a code smell and harder to visually parse and understand. I don't adhere to 80 chars, but somewhere around 100-120 is comfortable.
_ZeD_ 3y ago
both of the lines you've showed are poorly readable. not for the length itself, but for the attached mental needs needed to understand the `MyDict` data structure (that is the only variable here in your expression). that said, having a max-length, apart from the eyesight reasons, have this nice side effect that make it blatantly obvious that one expression is definitely too complex, as you've shown in your second example

wodenokoto 3y ago

When using pandas in Python you are encouraged to keep each “chained operation “ on its own line. (MyDict [family] [subfamily] [element] [property_a] [value] ) I honestly think all suggestions here are equally bad in their own regards.

cerved 3y ago

If a long line can't be hardwrapped nicely at 80 chars, it typically means there's room for improvement in the actual code.

yungporko 3y ago

i'd say that this is much nicer than both. there is always a better option than an abnormally long line. personally i limit my lines to 120 characters MyDict [family] [subfamily] [element] [property_a] [value]

gverrilla 3y ago
it's very clear indeed, but makes the code much harder to navigate in my opinion, and makes it look more complex than it really is, particularly for absolute beginners. In python, specifically, where indents matter, these line breaks seem very confusing for those starting to learn.
- Brian_K_White 3y ago
  Significant whitespace is a python problem not a whitespace problem. I am not one of the ones who cry about Make, but many do and for that reason primarily.

broscillator 3y ago

I don't think the first example is a long line. Imagine opening a book, and to have to read sentences that span both pages rather than just one. It's uncomfortable for the eye and it makes it harder to keep track of the motion of finishing one line on the right, and starting the next one on the left. Similar to how websites employ a lot of white space, imagine if instead the text went from the first pixel on the left to the last one on the right, it feels awkward.

addicted 3y ago

The solution to long lines isn’t to break up the line. The solution would have been (let’s say JS since that’s the most “beginner”ish language where this could even have a perf impact”): const myElement = myDict[family][subfamily][element]; const propValue = myElement[property][value];

dsego 3y ago

Ideally, you would never access deep props like that. First it's easy to make a mistake, and secondly each of those keys can fail if the dict doesn't contain that prop. You probably want to de-structure it first, depending on the language, or use a path getter that has a fallback value (or even better, use strictly defined object types). Long lines are usually a code smell and harder to visually parse and understand. I don't adhere to 80 chars, but somewhere around 100-120 is comfortable.

_ZeD_ 3y ago

both of the lines you've showed are poorly readable. not for the length itself, but for the attached mental needs needed to understand the `MyDict` data structure (that is the only variable here in your expression). that said, having a max-length, apart from the eyesight reasons, have this nice side effect that make it blatantly obvious that one expression is definitely too complex, as you've shown in your second example