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

docs(style): add style guide to contributing #8092

Merged
merged 2 commits into from
Jan 26, 2024

Conversation

gforsyth
Copy link
Member

Description of changes

Adding a first version of our unwritten style guide for prose and documentation.

Issues closed

Resolves #7094

@lostmygithubaccount
Copy link
Member

lostmygithubaccount commented Jan 25, 2024

idk what this is called but should have something about section headers -- "They should always be like this" instead of "Them Being Like This"

"sentence case" vs "title case" according to my good friend chatgpt

**NEVER** use `freeze: true` as this results in silently stale pages.
:::

Format code blocks with `black` or `ruff` where possible.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since Ibis uses ruff now, should we just stick to ruff.

If we don't care about this, and we would accept black, it might be worth considering this quarto extension https://github.com/shafayetShafee/black-formatter

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the style differences are extremely minimal, but an auto-formatter for the quarto code blocks would be nice.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing that makes me hesitant is that the formatting happens at the rendering level, it doesn't modify the file. I'll look into it a bit more, that being said that's out of the scope of this PR.


Format code blocks with `black` or `ruff` where possible.

Prefer `language` over `{.language}` in code blocks:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow this one, is this for non-executable cells?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, adding a comment about that.

docs/contribute/03_style.qmd Outdated Show resolved Hide resolved
docs/contribute/03_style.qmd Outdated Show resolved Hide resolved
docs/contribute/03_style.qmd Outdated Show resolved Hide resolved
docs/contribute/03_style.qmd Outdated Show resolved Hide resolved
- In vim you can use `gq` and then a movement to wrap. `gqG` to wrap an entire document.
- In neovim you can use `gw` and then a movement to wrap. `gwG` to wrap and entire document.
- In emacs you can use `fill-paragraph`.
- VSCode has a plugin called Rewrap (and probably several others).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the VIM commands also work if you're using it in VSCode as one should

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean if you're using the vim plugin / mode inside VSCode?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep! so I use gq and whatnot in VSCode

docs/contribute/03_style.qmd Outdated Show resolved Hide resolved

Format code blocks with `black` or `ruff` where possible.

Prefer `language` over `{.language}` for non-executable code blocks:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why? I thought quarto convention was the opposite

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, but it seems like a bad convention. More typing overall and also more prone to accidentally making a block executable.

@gforsyth
Copy link
Member Author

This can be squashed down when we merge it in, but I left the wrapping of previously existing lines in a separate commit if folks want to view those changes separately.

Copy link
Member

@lostmygithubaccount lostmygithubaccount left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see the sentence casing bit added, but that can be a follow up

I also think it might be worth having separate code vs documentation contributing guides, but that can also be a follow up when we have more content for that


### Text formatting

Wrap long prose strings between 80-90 characters per line. It is very helpful
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to just pick a number? :) Like 80 or 88?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can specify an upper bound, how about that?

@gforsyth
Copy link
Member Author

The preference for sentence case is on line 92

@gforsyth gforsyth enabled auto-merge (squash) January 26, 2024 14:33
@gforsyth gforsyth merged commit b807555 into ibis-project:main Jan 26, 2024
18 checks passed
@gforsyth gforsyth deleted the styleguide branch January 26, 2024 15:46
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

Successfully merging this pull request may close these issues.

docs: add contributing style guide for docs
4 participants