[ojii]

What's your solution for function definitions for this?

  def very_long_function_name(arg_one, arg_two, arg_three, arg_four):
    ...

[Longwelwind]

I 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]

I 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]

> 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

Please don't. It looks awful.

[OJFord]

The same thing basically, sibling comment has it.

`):` always either on the first (and only) line or the last line, which ensures it either over-runs the function body indention level, or falls short:

    def a():
        pass

    def b(
    ):
        pass

[Stratoscope]

Use the same principle as the last of OJFord's examples:

  def very_long_function_name(
      arg_one,
      arg_two,
      arg_three,
      arg_four
  ):
      ...

The nice thing here is that the close parenthesis separates the parameters from the function body, without having to do anything like double-indenting.

What's interesting to me is to try to understand why people are attracted to the column-aligned style even when it has so many problems. I think it comes directly from being unwilling to put spaces inside the parentheses when it's a one-liner:

  long_function_name(var_one, var_two, var_three, var_four)

If you find that line getting too long and want to break it into multiple lines, it's natural that the first thing you do is to turn spaces into newlines:

  long_function_name(var_one,
  var_two,
  var_three,
  var_four)

Well that's ugly, so what can we do with it? A few people indent the arguments after the first one:

  long_function_name(var_one,
      var_two,
      var_three,
      var_four)

That doesn't make much sense; why is the first argument not lined up with the rest? So the next natural thing to try is the column aligned style:

  long_function_name(var_one,
                     var_two,
                     var_three,
                     var_four)

And now you have the problems that brings; fiddly maintenance and excessive line lengths.

But what if you cultivate a style of putting spaces inside the parens, like this:

  long_function_name( var_one, var_two, var_three, var_four )

Now when you have to break it into multiple lines, the natural place to start is again to turn the spaces into newlines:

  long_function_name(
  var_one,
  var_two,
  var_three,
  var_four
  )

and from here it's simple to add some indentation:

  long_function_name(
      var_one,
      var_two,
      var_three,
      var_four
  )

What I haven't figured out is why so many programmers are opposed to putting spaces inside the parentheses. Not only does this lead to better practices when you switch back and forth between single line and multiline styles, but it's more logical too. In this example, the open paren "belongs" to the function call, not to the first argument. Why should the arguments get spaces between then, but the first argument is a special case, directly attached to the function name?

In fact, PEP8, if you take it as gospel, forbids spaces inside the parentheses. But as is common with these things, it gives no reason or rationale for this. It's simply listed as a "pet peeve".

I've seen a few style guides where the authors realized it would be nice to have some whitespace between the function name and first argument, but just couldn't bring themselves to try putting the space inside the parentheses, so they put it outside:

  long_function_name (var_one, var_two, var_three, var_four)

A lot of Unity C# code is written like this, because it's MonoDevelop's default style. It's not terrible when you see a simple example, but it gets pretty bad when there are nested functions:

  DoSomething (Foo (x), Bar (y))

The whitespace here has very little to do with the actual structure of the code. Contrast this with:

  DoSomething( Foo(x), Bar(y) )

Now the things that belong most closely together are visually connected, and spaces separate the things that are less connected. I didn't put spaces inside the parens for the inner functions, only the outer one, to help emphasize what is connected to what.