Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add editor config #79

Open
alexpearce opened this issue Feb 8, 2018 · 6 comments
Open

Add editor config #79

alexpearce opened this issue Feb 8, 2018 · 6 comments

Comments

@alexpearce
Copy link
Member

With lots of contributors having strong opinions on their text configuration, we should include a style guide and/or editor config file that defines how we format the lessons. This is partly to circumvent the need for style debates, and also to reduce the number of re-formatting changes made in PRs, which clutter the diff.

@goi42
Copy link
Contributor

goi42 commented Feb 8, 2018

Style suggestions:

  • ~80 character line length with breaks after whole words (to make change tracking easy) and with a space at the end of the line.
  • bullet points should not end in punctuation (e.g., the Learning Objectives, not the list in Contributing).

@apuignav
Copy link
Contributor

apuignav commented Feb 8, 2018

I prefer line break after sentence (easier to track changes). Maybe editor config doesn't handle this properly?

@goi42
Copy link
Contributor

goi42 commented Feb 8, 2018

That sounds reasonable to me. (I do my line-breaks in Markdown manually anyway.) If we break after each sentence, maybe suggest no hanging white-space?

@chrisburr
Copy link
Member

I typed this earlier but then forgot to comment:

I've not really thought about this but perhaps we could have CI:

  • Autoformat merge requests when they're merged (one sentence per line, normalise whitespace)
  • Add a branch (travis-mr-XYZ) when merge requests are made and then leave a comment linking to the diff so a normalised diff can be viewed

It might make leaving comments on diffs a little more awkward but it would avoid requiring people to configure editors.

@goi42
Copy link
Contributor

goi42 commented Feb 8, 2018

I like that idea as it's basically impossible to enforce style-guides. And it's no more awkward than looking through commits that contain style-updates.

@apuignav
Copy link
Contributor

apuignav commented Feb 8, 2018

I like the idea a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants