evancz/guide.elm-lang.org

Consider making guide style consistent with `elm-format` or vice-versa

bbkane opened this issue · 2 comments

Please fill in the following information:

  • My programming background is ...

Software Engineer / Site Reliability Engineer (Python, C++, Go)

  • I want to learn Elm because ...

    • I want to learn frontend/GUI programming
    • I want to learn a functional language
    • I want to build apps quickly and correctly
  • I was confused by ...

Problem

As a newcomer, it was jarring to type up all of the code in this book, make my little changes to experiment, then install elm-format and change all indented lines.

The code style in the guide uses 2 spaces and the code style imposed by elm-format uses 4 spaces. There may be other differences as well.

Supporting Statements

As a developer who's used similar tools in other languages (black, gofmt, clang-format, etc.), I think its very important for developers to have an auto-formatter, and especially for new developers to see consistent style in their books/tutorials and from what their formatter gives them.

Elm has a productive history of removing confusing and ultimately non-productive choices from the language (removal of custom operators, limitations on tuple types, canonical ways to build, excellent and consistent documentation from the language creators).

It'd be really nice to have a canonical style guide like Python's PEP8, or Go's gofmt. For a negative example, anyone who's worked with C++'s proliferation of style guides knows developers have to waste time context-switching between different styles between projects.

Elm is a white-space heavy language, so white-space matters.

Possible resolutions

  • format this guide's code to elm-format's style. This might amount to implicitly/explicitly accepting the output of elm-format as the "blessed" style or even adopting elm-format into core. If this option is taken, please update the guide.
  • Write a "blessed" style guide and working with elm-format to adopt it (issues, code, conversations) or writing a replacement tool
  • Some combination of the above options

I don't really have on opinion on the "correct" style, I care a lot more about consistency.

Final thoughts

I just want a consistent style between docs, tools, and projects. This might seem nitpicky, but ask any developer who has tried auto-formatters and you'll hear them rave about how great they are. I'm very new to Elm and I don't want to work without auto-formatting, so I'm going to be using elm-format's styling. I'm going to be referencing the guide/docs for code, so I'll have to constantly mentally reformat code.

See this Slack comment for status

Welp, guess this isn't gonna happen