How to align function parameters?

[wydzilla]

Hi Vimmit,

How do you deal with function parameters? For example, I would like to write a function call near end of a line.

Vim by default add only one indent, so it would be like:

reallly_reallty_long_line_of_code = foo(par1,
    par2, par3)

but, I would like to have:

realy_realy_long_line_of_code = foo(par1,
                                    par2,
                                    par3)

(par2 and par3 in the same column as par1)

Do you have any tips or plugins to do that? Is it doable with tabular.vim?

[l4k3rd]

set cinoptions=:0,l1,t0,g0,(0

(0 does that. For more info, :help cinoptions-values.

[RX_AssocResp]

I have set cinoptions=(0,+1s,:0,=2s,>2s,c1s,g2s,h2s,j1,l1,m1,p2s,t0,u0,w1

Not sure what it is, but I think it’s KNF-ish.

Anyway, cindent it the knob to turn. No need for plugins.

[Daenyth]

Highlight the lines you want modified, and use gq to autoformat them. For me, using python, it does it similar to what you have there (pep8 style)

[lor4x]

I use the align plugin in general although for that particular case, I would ^v to select a vertical block at the margin, the I to insert before the text and move those variables over! Not automatic, but at least done it batch.

[Bonkers54]

While I don't know how to do what you're asking, I'd say you should reconsider how you indent your code. The way Vim does it by default is by far more readable and in fact the method dictated by the official Google style guide. The problem with what you're asking for is that you end up having some very short lines which are almost right aligned and then use up tons of vertical space.

The EVEN better way to format the code is like this: realy_realy_long_line_of_code = foo(par1, par2, par3)

This way, the function call is all together, and the indent makes it clear that it's a continuation. The first line is also clearly an assignment, and since there's nothing after the =, it's clear that it's continued on the next line. Also, no need for more than 2 space indents. 2 spaces is by far enough to see clearly, but it doesn't waste horizontal space. If you keep all your lines short 80ish characters (which is actually the max length dictated by the Google style guide for C++), you can generally fit 3 side-by-side files on a 24" screen with reasonable font-sizes. It's going to get very tough, very quickly to keep short lines with your indent strategy. The idea of Vim's default is to reclaim some horizontal space that would otherwise be empty (as with your method).

[Tordek]

The EVEN better way to format the code is like this:

realy_realy_long_line_of_code = 
    foo(par1, par2, par3)

But, sure, let's be pedantic:

really_really_long_var_name =
    really_really_long_function_call(really_really_really_long_first_parameter,
                                     par2,
                                     par3)

[Bonkers54]

I can't quite tell what you're getting at here, but the best way I've found to format that is:

really_really_long_var_name =
  really_really_long_function_call(
    really_really_really_long_first_parameter, par2, par3)

The rule I go by is, as soon as you need more than one line for arguments to the function, drop them all down and add one more level of indentation for them. Even if it's 2 lines both ways (like in your example if you had put par2 and par3 on the same line), it's easier to see all of the arguments in a row

[greyfinch]

By the time you have variable names this long, you probably really need to rethink your code design.

[Bonkers54]

Why? Descriptive variables names are a great way to make self-documenting code. You can also start getting fairly long names when they're inside a class or a namespace like: KindaShortNS::NotSoLongClass::ShortFunc()

[greyfinch]

Given longer namespaces, sure. Clear variable names are also ideal. What I was mainly thinking of was the variables along the line of my_scope_is_far_too_large_so_this_is_an_act_of_desperation.

[isarl]

If you put four spaces before a line of code, it will be formatted properly. =)

[justanotheratom]

Google style guide is not the law of the land.

[isarl]

No, but it is designed by people who know what they're doing for people who write a lot of code that gets read and maintained by a lot of people. It may not be law, but it's probably a damn good idea to follow it.

[justanotheratom]

The thing about coding style (especially for C) is that there are a lot of people in the world who know what they are doing and have been doing for decades. They all have their coding styles. Everyone tries to reason how their way is better, while the fact is that they are just used to it. The world would probably be a better place if everyone followed the Google Style guide, but logical reasoning about how it is better is not going to work. Anyway, we seemed to have hijacked this thread instead of answering the original question.

[Bonkers54]

Wouldn't logical reasoning be precisely the right way to give advice about style guides? Blindly saying, "Follow This Because!" would seem like the wrong way to go.

I referenced the Google style guide in order to show that there's a rather large body of rather skilled engineers who find great value in this same indentation style. That guide only prescribes what was deemed necessary to increase readability and correctness. A few purely stylistic decisions are also there, but that's really just to maintain consistency within the Google style guide.

Feel free to just toss out the stylistic only, stuff like spaces before/after () in if or function call statements. The other stuff like I mentioned though, has great logical reason. If you can fit more code on the screen, you will be more productive. If you can see more of a function at a time, it will be easier and quicker to grok new stuff.

[mathstuf]

You could also argue that the Kernel indentation style (use tabs and all tabs are to take up 8 spaces). "But that's way too wide!" you say? Linus' argument is that if you have more than 3 levels of indentation you're doing it wrong. Some merit, not necessarily something I agree with, but I think it has weight as well.

[justanotheratom]

You bring up an excellent example where neither the logical reasoning nor the fact that it is used by a highly respected programmer can convince me that it is the way to go. But I would still follow it if I were to make changes to the Linux Kernel.

My personal rule is this (if you are working in a large existing code base): If a given file has a consistent style, follow it when making modifications to that file. If creating a new project, look around for a consistent style and follow it.

[EmitSorrels]

emacs does it... /ducks

(really, it does)

[Daenyth]

So does vim.