4 ms·

My concern with 80 cols is that it is not friendly to dynamic languages that allow nested definitions, or long variable names. if name == 'main':

by Retra 11y ago

My concern with 80 cols is that it is not friendly to dynamic languages that allow nested definitions, or long variable names. if __name__ == '__main__': def this_is_a_function(*args, **kwargs): def this_is_a_helper_function(arg1, arg2=('this line is already indented 39 ' 'chars!')): this_long_variable = ("Don't put an expression here unless you " "want to use useless intermediate variabls.") return this_long variable if var else 'really short here' return 1 And some people want to insist on 8 char indents!

deleted 11y ago
[deleted]
bpicolo 11y ago
Then use better whitespace rules. Not to mention the helper isn't capturing any closure here so it's not particularly useful inline, and even when they are you can refactor variable capture to new functions. Nested definitions in python are pretty rare, and oft unnecessary if __name__ == '__main__': def this_is_a_function(*args, **kwargs): def this_is_a_helper_function( arg1, arg2='this line is now indented 12 chars!' ): this_long_variable = ( "Don't put an expression here unless you " "want to use useless intermediate variabls." ) return this_long variable if var else 'really short here' return 1
- deleted 11y ago
  [deleted]
- JadeNB 11y ago
  Surely the fact that there are two typos in your code, one of them in the name of a variable (`this_long_variable` vs `this_long variable`), indicates that things can go wrong when you abstract out a literal to a variable?
  - bpicolo 11y ago
    I literally copy pasted from the other guy and added whitespace.
sago 11y ago
Why not follow pep 8's indentation rules: def this_is_a_function(*args, **kws): def this_is_a_helper_function( arg1, arg2='this line is indented 12 chars!'): this_long_variable = ( 'Don\'t put an expression here unless you ' 'want to use useless intermediate variables') return this_long_variable if var else 'really short here' return 1 (for the same number of lines) or better still follow some basic common sense: 1. Local functions should be short and have short names since their scope is limited. 2. Local variables, similarly 3. Don't put long explicit strings in code. and get messages = dict( long_default = \ 'Don\'t write strings that may wrap in ugly ways on 80 col shells.', short_default = 'Keep it short' ) def this_is_a_function(parameter): def message(long, message='this is only 36 chars'): long_message = messages.long_default short_message = message or messages.short_default return long_message if long else short_message # Do something here. return 1 And if you have an expression that is more than 80 characters long, breaking bits of that expression and assigning them to temporary variables is not 'useless', it makes code clearer and is only rarely a performance hit.
- coldtea 11y ago
  If I see a "\" I close the editor and delete the source file.
  - deleted 11y ago
    [deleted]
  - sago 11y ago
    How impressive of you.
- Retra 11y ago
  Those are great suggestions, but may point is more that "too much on one line" isn't necessarily better than "too little over too many lines." It can be hard to get a good overview of what is happening when you've got to resort to splitting one significant token per line. In other words, I try to use vertical space for higher-level work than horizontal space, and when you have to fit both into vertical space, you lose some clarity in high-level in order to gain it in low-level.
nvader 11y ago
To quote the Zen of Python: Flat is better than nested. Too many levels of nesting is definitely a code smell. Often it's better to pull those helper functions out, and/or create function or method factory functions at a higher level of organization.
- Retra 11y ago
  You can't really do that if you're writing closures.
  - zo1 11y ago
    Have you had a look at https://docs.python.org/2/library/functools.html#functools.partial https://docs.python.org/2/library/functools.html#functools.p... ? Anywho, do you have a genuine example of where a closure is helpful for you in python? I'm very curious.
    - Retra 11y ago
      I don't understand the question. Your link has examples of closures right in it, so naturally if you're doing anything like that, you'll want them.

My concern with 80 cols is that it is not friendly to dynamic languages that allow nested definitions, or long variable names. if __name__ == '__main__':

by Retra 11y ago

deleted 11y ago

[deleted]

bpicolo 11y ago

Then use better whitespace rules. Not to mention the helper isn't capturing any closure here so it's not particularly useful inline, and even when they are you can refactor variable capture to new functions. Nested definitions in python are pretty rare, and oft unnecessary if __name__ == '__main__': def this_is_a_function(*args, **kwargs): def this_is_a_helper_function( arg1, arg2='this line is now indented 12 chars!' ): this_long_variable = ( "Don't put an expression here unless you " "want to use useless intermediate variabls." ) return this_long variable if var else 'really short here' return 1

deleted 11y ago
[deleted]
JadeNB 11y ago
Surely the fact that there are two typos in your code, one of them in the name of a variable (`this_long_variable` vs `this_long variable`), indicates that things can go wrong when you abstract out a literal to a variable?
- bpicolo 11y ago
  I literally copy pasted from the other guy and added whitespace.

sago 11y ago

Why not follow pep 8's indentation rules: def this_is_a_function(*args, **kws): def this_is_a_helper_function( arg1, arg2='this line is indented 12 chars!'): this_long_variable = ( 'Don\'t put an expression here unless you ' 'want to use useless intermediate variables') return this_long_variable if var else 'really short here' return 1 (for the same number of lines) or better still follow some basic common sense: 1. Local functions should be short and have short names since their scope is limited. 2. Local variables, similarly 3. Don't put long explicit strings in code. and get messages = dict( long_default = \ 'Don\'t write strings that may wrap in ugly ways on 80 col shells.', short_default = 'Keep it short' ) def this_is_a_function(parameter): def message(long, message='this is only 36 chars'): long_message = messages.long_default short_message = message or messages.short_default return long_message if long else short_message # Do something here. return 1 And if you have an expression that is more than 80 characters long, breaking bits of that expression and assigning them to temporary variables is not 'useless', it makes code clearer and is only rarely a performance hit.

coldtea 11y ago
If I see a "\" I close the editor and delete the source file.
- deleted 11y ago
  [deleted]
- sago 11y ago
  How impressive of you.
Retra 11y ago
Those are great suggestions, but may point is more that "too much on one line" isn't necessarily better than "too little over too many lines." It can be hard to get a good overview of what is happening when you've got to resort to splitting one significant token per line. In other words, I try to use vertical space for higher-level work than horizontal space, and when you have to fit both into vertical space, you lose some clarity in high-level in order to gain it in low-level.

nvader 11y ago

To quote the Zen of Python: Flat is better than nested. Too many levels of nesting is definitely a code smell. Often it's better to pull those helper functions out, and/or create function or method factory functions at a higher level of organization.

Retra 11y ago
You can't really do that if you're writing closures.
- zo1 11y ago
  Have you had a look at https://docs.python.org/2/library/functools.html#functools.partial https://docs.python.org/2/library/functools.html#functools.p... ? Anywho, do you have a genuine example of where a closure is helpful for you in python? I'm very curious.
  - Retra 11y ago
    I don't understand the question. Your link has examples of closures right in it, so naturally if you're doing anything like that, you'll want them.