4 ms·
Agreed, "aligned with opening delimiter" is brain dead, you just waste time re-justify everything if you refactor. It's just more effort in the long run, and fo
by guitarbill 10y ago
Agreed, "aligned with opening delimiter" is brain dead, you just waste time re-justify everything if you refactor. It's just more effort in the long run, and for what? It isn't prettier, more readable, or more convenient.
As for strings, meh. But consistency is nice. Line length exceeding an arbitrary standard, fine. Rules can be broken if there's a good reason.
- merlincorey 10y ago> Agreed, "aligned with opening delimiter" is brain dead, As a smug lisp weenie that has been working in python for many years, I completely disagree with this. > you just waste time re-justify everything if you refactor. A single `indent-region` in emacs and you are rejustified, no trouble. > It's just more effort in the long run, and for what? It's more effort as opposed to what, exactly? > It isn't prettier, more readable, or more convenient. It is, to me, prettier, but I think, objectively, it is more readable than alternatives, especially if there is any kind of nesting involved. I concede that if there is nesting involved, you might be bumping into other python style issues, and generally might want to add some intermediate variables, etc; however, I do believe that in at least some cases this is entirely inconvenient, and so the lisp way of aligning parameters with their delimiter is the way to go in those cases. Anything else would be quite a bit less readable.
- antris 10y ago> A single `indent-region` in emacs and you are rejustified, no trouble. Yeah, I'll just change my text editor because someone in the team wants to use this rule. So convenient.
- guitarbill 10y ago> > you just waste time re-justify everything if you refactor. > A single `indent-region` in emacs and you are rejustified, no trouble. Because when you refactor the function/class name, it's never just one region. So now you have to go back and indent all occurrences, maybe even over multiple files. Brilliant!
- dkbrk 10y ago> Because when you refactor the function/class name, it's never just one region ... the region is whatever you say it is: (mark-whole-buffer) (indent-region) Or, most likely, something like: C-x h TAB I don't think that's particularly onerous. It's only a few lines of elisp to visit all the files in a tree and automatically format them. That said, it would probably be more sensible to modify whatever refactoring tool to be indentation aware, if it isn't already. Again, that's easy to do with elisp.
- OJFord 10y agoI hate that with a passion. But I'm not clear what's being suggested in the article. Personally, I'd turn: foo = long_function_name(var_one, var_two, var_three, var_four) into: foo = long_function_name( var_one, var_two, var_three, var_four ) or: foo = long_function_name( var_one, var_two, var_three, var_four, ) depending on the actual length. (Or all on one line if short enough of course.) "Aligned with opening delimiter" basically just means "put all the code as close to our column limit as possible", which is nuts.
- ojii 10y agoWhat's your solution for function definitions for this? def very_long_function_name(arg_one, arg_two, arg_three, arg_four): ...
- Longwelwind 10y agoI believe it will be: def very_long_function_name( arg_one, arg_two, arg_three, arg_four ): It's consistent and doesn't require spaces so it lets you use tabs to let the reader choose its indentation size.
- guitarbill 10y agoI can't tell (might have got lost in the edit), but PEP8 suggests the arguments are more indented than the function body: def very_long_function_name( arg_one, arg_two, arg_three, arg_four ): pass For data structures, I definitely prefer the bracket to be on it's own line, but for function definitions I don't, so I'm also a fan of: def very_long_function_name( arg_one, arg_two, arg_three, arg_four): pass def very_long_function_name( arg_one, arg_two, arg_three, arg_four): pass
- dozzie 10y ago