Consider switching style guide to comma at the end

[Sebastian Porto]

Hi

Currently the Elm style guide http://elm-lang.org/docs/style-guide considers good practice to write records and list like this:

type alias Circle =

    { x : Float

    , y : Float

    , radius : Float

    }

I have been using elm-format which follows this but I have noticed that I find this style difficult to work with. Let me explain.

I usually sort attributes in records alphabetically. e.g.

type alias Circle =

    { radius : Float

    , x : Float

    , y : Float

    }

    

This style makes sorting really attributes quite difficult. Consider what needs to be done to add an attribute before `radius`. 

Because the style guide suggest using { in front of the first item I can't use my editor automatic sorting command.

I suggest switching to a style where the first items is not preceded by { or [

type alias Circle = {

    radius : Float,

    x      : Float,

    y      : Float

}

or in case of a list

list = [

'a',

'b'

]

This will mean to put the comma at the end but will make sorting trivial. Please consider this.

Thanks
Sebastian

[Mike MacDonald]

I think aligning the delimiters is a large boon for readability, and code should be written for humans first and tools second.

It should not be too difficult to create a PR to your editor's sort plugin to support this syntax. (Given that your editor supports open-source plugins...)

[James Wilson]

personally I much prefer commas at the beginning for readability nowadays

[Matthew Griffith]

I prefer commas at the beginning in order to have quicker visual confirmation that a comma is not missed.  If they're at the end I think they're objectively harder to notice (or notice when they're missing).

For larger records where field organization is more important, I group fields semantically.   Or I try to think why I have such a large record in the first place.

[Sebastian Porto]

Maybe the best tradeoff would to allow the compiler to start records and list with a comma:

type alias Circle = {

,   radius : Float

,   x      : Float

,   y      : Float

}

In this way we will have the readability benefits people mention and allow sorting.

[Fernando Alegre]

Actually, if that route was chosen, the best tradeoff would be to have no commas in multi-line lists and records, and just use the indentation levels to
separate items, just like it is done in "case" clauses.

example_list = [
    item1
        still part of item 1
    item2
    item3
        still in item 3
    ]

On Saturday, May 20, 2016 at 8:43:12 PM UTC-5, Sebastian Porto wrote:

Maybe the best tradeoff would to allow the compiler to start records and list with a comma:

type alias Circle = {

,   radius : Float

[Sebastian Porto]

Here is another reason we should consider moving away from the current style.
If I want to add an item at the beginning of a list or if I want to delete or comment the first item, currently it is unnecessarily hard.

If we have each item in its own line then it become really easy to add, delete or comment lines.

[Francesco Orsenigo]

Second that.
I don't especially mind the comma-first style, but it does make the first element in a list or record different than the others. Adding or removing the first element requires to change TWO lines instead of one, which is really inconsistent with all the wankery in the style guide regarding newlines after the assignment operator.

[Mark Hamburg]

The best approach I've seen to this in other languages is Lua which allows an extraneous trailing comma. In Elm, that would enable one to write:

fn [

    a,

    b,

    c,

]

Note, however, that there is a separate issue lurking in this formatting style and that is the cases where indentation matters and outdenting the closing bracket — a la K & R — can cause problems with some constructs.

I've gotten used to the leading commas in most places — though I'm not really happy with them in view construction — but do find that making the first line special is annoying.

Mark

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/99892eb7-7631-4587-b785-c34427f4f79f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Feldman]

Just FYI, this has all been discussed before. :)