Long function signatures should break about v HOT 8 CLOSED

My question is: Why?

Long lines were a problem on printouts, but hopefully (almost?) all of us have moved beyond that stage.

I know people are sometimes annoyed by actually having to scroll horizontally, but others are just as annoyed by having to scroll vertically.

The simplest "fix" for this issue is to create a struct for the parameters, and pass the struct instead of all the separate parameters.

struct LongerFunctionNameParams {
    x u32
    y u32
    z u32
    first_parameter package_name.LongerTypeName
    second_parameter package_name.LongerTypeName
    third_parameter package_name.LongerTypeName
    fourth_parameter package_name.LongerTypeName
    fifth_parameter package_name.LongerTypeName
    sixth_parameter package_name.LongerTypeName
}

pub fn longer_function_name(params LongerFunctionNameParams) {
	first_variable := params.first_parameter.whatever
}

from v.

Yes, horizontal scrolling is never good.

This has indeed been approved by me.

from v.

Thinking about it, I personally actually don't care much whether V enforces an arbitrary width limit.
Others might expect that, though.

From my perspective, the opposite question would be warranted:
Why remove manually placed line breaks and mess up formatting without a good reason?

from v.

v fmt is an opinionated formatter. Same as go fmt before it.

That's why there are no options - you get what you get... and so does everyone else.

This makes it trivial to look at someone else's code and not have your first thought be "Gah! I have to format this before I can make sense of it!"

I could tell you horror stories...

from v.

Those are a bunch of non-arguments going in circles.

This looks like horror to me:

So I'd have to actively decide to extract it to a struct as a workaround, which renders the whole point of automatic consistency moot.

I can't remember the last time formatting issues actually kept me from understanding others' code.
But unreasonable default formatting makes me not want to use the language enforcing those on my own code.

An in this case, the formatter isn't just not helping, it's actively disrupting readability for no gain I can think of.

from v.

When Go's formatter was released, it was simultaneously the most loved AND most hated feature.

It doesn't give you any options - it always formats things the same way.

What "looks good" to one person may be a complete "horror" to another. The only way to make things fair is to always format the same way, regardless of individual preferences.

That said, if you can make a good case for why a particular thing should be formatted differently (and "because I like it better that way" is not good enough), then perhaps you can convince Alex that it's a change that should be made.

Otherwise, love it or hate it, the formatter will continue to act as it does.

from v.

I do think having long functions should break to be honest, it is a pain when you have to scroll loads horizontally but I do understand it is preference too.

from v.

That said, if you can make a good case for why a particular thing should be formatted differently (and "because I like it better that way" is not good enough), then perhaps you can convince Alex that it's a change that should be made.

Otherwise, love it or hate it, the formatter will continue to act as it does.

As I mentioned in both recently opened issues, that's exactly what I did before opening them:

from v.