Open lwasser opened 1 day ago
@sneakers-the-rat i welcome edits to this lesson to reorg it some if you want to implement them! otherwise, i'll do it after the fall festival 🚀
I haven't documented the setup here, but it's a sphinx book running pydata_sphinx_theme by myst_nb and jupytext. So, using Jupy, I only commit the .md files, making for lovely, easy diffs! Locally you have to set this all up, and I haven't had time to document it - YET, but I'll do my best to make that happen soon!!
Ok - and here is the feedback on org from @willingc @lwasser @sneakers-the-rat Let's split this PR up or merge as is and then do another iteration. I'm finding it difficult to work with all three files in the same PR and follow proposed edits.
I would love to see something more along the lines:
Etc.
link here: to the formatted comment
we will need to come together on a structure that makes sense for this section!
I think the only major difference between Carol and my suggestions are the order of "overview, tooling, rules" vs. "Overview, rules, tooling" and I would be fine with either.
I actually slightly prefer Carol's version, because then we could tag each of the rule suggestion sections to a ruff/pyflakes/etc rule code.
The difference between current version and reorganized version would then mostly be to group related content and provide a little more structure for skimming, which doesn't seem too complicated :)
One thing i'm missing here is an overview of "what are the kinds of things that might be subject to style rules." The examples are good, but some bigger picture categories that i could group things into: naming, comments, whitespace, character use (tabs/spaces, '/"), syntax (eg. using a ternary rather than if/else, etc.). I think reordering that section, adding subheadings between each of them, would make it easier to digest :)
Current structure:
So this is how i would do it (but as always not saying you have to):
One other sorta tangential thing- think it's important to give the other side so this too, that they shouldn't feel restricted by linters/formatters! they should use them if they support their work and help them think clearly. If they find a rule annoying? they should turn it off. it's their call. i don't mean to be annoying or overly ideological about this since i am known to make a big deal about standardization in devops but figured i'd bring it up.
Originally posted by @sneakers-the-rat in https://github.com/pyOpenSci/lessons/pull/12#pullrequestreview-2363727185