5 ms·

Your point is valid, that's why I write function( really_really_really_really_really_long_argument1, really_really_really_really_really_lon

by adontz 10y ago

Your point is valid, that's why I write function( really_really_really_really_really_long_argument1, really_really_really_really_really_long_argument2, really_really_really_really_really_long_argument3);

pyre 10y ago
Right, not now you're dictating coding style to work around the warts associated with using tabs. If you use spaces there are no such issues because spaces don't change widths between editors.
- adontz 10y ago
  To be honest, no, because my formatting will not be broken after refactoring changing function name length.
  - pyre 10y ago
    What workflows do you have where renaming functions happens often enough that you need to optimize for it?
    - adontz 10y ago
      I do not really measure how often this happens, just rename as soon as name does not reflect exactly what function does.
- exDM69 10y ago
  The kind of formatting you suggest - aligning with spaces to get beautiful indenting - is a royal pain in the ass to edit. You change the function name to something a few characters shorter and now you have to change all the lines. It's prettier than the alternative, though (I still don't use it). I wish the pioneers of programming languages would have had the foresight to provide an automatic formatting tool and standardize on a canonical layout. So much time and effort would have been saved. Further, I think code guideline documents and discussions without an accompanying config file for astyle or clang-format are pretty useless.
  - pyre 10y ago
    That particular form of formatting is part of Python's PEP-8, which has tooling around it. Maybe not all editors have something built it, though.
    - exDM69 10y ago
      Editor is one thing and most fully featured editors probably have an indent mode like this. Then there's all the other tools, like diff/merge tools, automatic refactoring scripts, etc which don't work as well. I'm not a fan of Python's significant whitespace or PEP-8 in the first place. It puts too much emphasis on aesthetics at the cost of practicality. Writing a parser or any tooling for that is just a pain in the ass. I do use Python occasionally but for very different reasons than aesthetics.
      - collyw 10y ago
        I disagree. I moved form Perl to Python and disliked the whitespace to begin with. It does solve a couple of problems - it forces inexperienced coders to indent properly (I had one colleague who didn't when she used Perl). It also solves the missing brace problem when moving blocks of code around, which for me makes it worthwhile. It does make moving blocks around and commenting sections out a bit more effort, but way less effort than trying to work out where the brace has gone.
  - groovy2shoes 10y ago
    Some languages do have more-or-less canonical formatting styles. The Lisp family comes to mind, as do ML and Haskell. You see far fewer arguments about formatting there, partly because there's very widely-accepted style, and partly because nobody cares to argue about the few things that don't have established canon.

by adontz 10y ago

pyre 10y ago

Right, not now you're dictating coding style to work around the warts associated with using tabs. If you use spaces there are no such issues because spaces don't change widths between editors.

adontz 10y ago
To be honest, no, because my formatting will not be broken after refactoring changing function name length.
- pyre 10y ago
  What workflows do you have where renaming functions happens often enough that you need to optimize for it?
  - adontz 10y ago
    I do not really measure how often this happens, just rename as soon as name does not reflect exactly what function does.
exDM69 10y ago
The kind of formatting you suggest - aligning with spaces to get beautiful indenting - is a royal pain in the ass to edit. You change the function name to something a few characters shorter and now you have to change all the lines. It's prettier than the alternative, though (I still don't use it). I wish the pioneers of programming languages would have had the foresight to provide an automatic formatting tool and standardize on a canonical layout. So much time and effort would have been saved. Further, I think code guideline documents and discussions without an accompanying config file for astyle or clang-format are pretty useless.
- pyre 10y ago
  That particular form of formatting is part of Python's PEP-8, which has tooling around it. Maybe not all editors have something built it, though.
  - exDM69 10y ago
    Editor is one thing and most fully featured editors probably have an indent mode like this. Then there's all the other tools, like diff/merge tools, automatic refactoring scripts, etc which don't work as well. I'm not a fan of Python's significant whitespace or PEP-8 in the first place. It puts too much emphasis on aesthetics at the cost of practicality. Writing a parser or any tooling for that is just a pain in the ass. I do use Python occasionally but for very different reasons than aesthetics.
    - collyw 10y ago
      I disagree. I moved form Perl to Python and disliked the whitespace to begin with. It does solve a couple of problems - it forces inexperienced coders to indent properly (I had one colleague who didn't when she used Perl). It also solves the missing brace problem when moving blocks of code around, which for me makes it worthwhile. It does make moving blocks around and commenting sections out a bit more effort, but way less effort than trying to work out where the brace has gone.
- groovy2shoes 10y ago
  Some languages do have more-or-less canonical formatting styles. The Lisp family comes to mind, as do ML and Haskell. You see far fewer arguments about formatting there, partly because there's very widely-accepted style, and partly because nobody cares to argue about the few things that don't have established canon.