elm / elm-lang.org

Server and client code for the Elm website.
http://elm-lang.org/
BSD 3-Clause "New" or "Revised" License
1.99k stars 366 forks source link

Should better format the code in introduction document #582

Closed hyouuu closed 5 years ago

hyouuu commented 8 years ago

First of all thanks for the Elm lang! I'm following the introduction, but found it annoying that similar patterns in code appear in different format on different topics, which made me feel "This is lousy, should I trust this language?" Taking http://guide.elm-lang.org/architecture/effects/http.html as example:

view model =
  div []
    [ h2 [] [text model.topic]
    , img [src model.gifUrl] []
    , button [ onClick MorePlease ] [ text "More Please!" ]
    ]

Here around text and src there is no space, but around onClick and "More Please" there are spaces.

type Msg
  = MorePlease
  | FetchSucceed String
  | FetchFail Http.Error

Here the = is on the second line, whereas all other places have = on the first line.

Obviously it's no big issue at all, but as I felt it shows un-polished quality and makes it feel less trust-worthy.

I could also help correct the formats but now sure how GitBook and its permission works...

evancz commented 5 years ago

It is pretty common to put the equals sign on the next line when defining a new type.

I definitely know what you mean here, but there are tradoffs with every convention! E.g.

-- possible alternative
type Msg =
    MorePlease
  | FetchSucceed String
  | FetchFail Http.Error

-- alternative that'd need language changes
type Msg =
  | MorePlease
  | FetchSucceed String
  | FetchFail Http.Error

However you do it, it's a bit weird. I think it makes sense to stick with the current way given the options available.