Provide guidance on what to do with long lines

[khanage]

Just had a discussion with a coworker about what to do with imports once they exceed 80 characters.

Would something like

import Some.Long.Module (Thing, That, Blah, asdasd, asdasdasdasd, adasdasdasdas, vjviodfjvdfovj)

Make sense to go to

import Some.Long.Module ( Thing, That, Blah, asdasd, asdasdasdasd
                                              , adasdasdasdas, vjviodfjvdfovj )

or

import Some.Long.Module 
            ( Thing, That, Blah, asdasd, asdasdasdasd
            , adasdasdasdas, vjviodfjvdfovj )

or should it be consistent with the approach for other collections?

import Some.Long.Module 
    ( Thing
    , That
    , Blah
    , asdasd
    , asdasdasdasd
    , adasdasdasdas
    , vjviodfjvdfovj 
    )

[garyb]

I would recommend never formatting imports manually, since purs ide should be managing them for you 😉 - imports aren't really code that you read the same way you do functions and such, so I think the benefit of formatting those lines is minimal.

[khanage]

Yeah, I agree with that, I just want to add that we often review code in github PRs, so having lines that would wrap around the earth is a little jarring. We can always have purs ide conform to the style listed here, right?

[arhont375]

imports aren't really code that you read the same way you do functions and such, so I think the benefit of formatting those lines is minimal.

Will disagree with that, it's quite convenient to have readable imports. For example if you want to have a brief way to understand what used in this module, what types from other module used in this module.

So purs ide should change imports than longer then 80 characters to this format:

import Some.Long.Module 
    ( Thing
    , That
    , Blah
    , asdasd
    , asdasdasdasd
    , adasdasdasdas
    , vjviodfjvdfovj 
    )

Also this format is friendly to git as you will understand easily which lines was changed.