You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Talk:Style guidelines

From Wikitech-static
Revision as of 20:59, 18 August 2022 by imported>BryanDavis (→‎Coming to a consensus on Python style guidelines: Reply)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Coming to a consensus on Python style guidelines

I hear that multiple projects have multiple styles, so which one wins out? I've also heard disagreements on whether to use Black as the style guidelines or to bend Black to whatever we define (I'm of the opinion for the latter) BCornwall (talk) 17:25, 18 August 2022 (UTC)

I also want to clarify that by "wins out" that doesn't exclude the possibility that each team/project has its own style guidelines. Shoehorning something in for the sake of it doesn't help anyone if it causes the project undue stress. I'm more interested in a general "gonna write some code for WMF? Here's how we prefer you do it" --BCornwall (talk) 18:26, 18 August 2022 (UTC)
This is revealing some of my biases and triggers, but the "As a team," starting the article immediately made me say "which team?". The main namespace on wikitech is generally thought of as Wikimedia Foundation SRE oriented content, but even that is not very specific.
I would personally like to think about these kinds of standards and guidelines as FOSS community needs rather than siloed team solutions. mw:Manual:Coding conventions/Python is an existing set of guidelines, but one that would likely be found lacking by a group starting new Python codebase from scratch.
Lacking energy to push for shared standards in the past, the Cloud Services team drafted Wikimedia Cloud Services team/Python coding which can generally be summarized as "use Black with line length 80" (default is 88 chars I believe). The beauty of Black otherwise is that it really isn't variable. Max line length is the only per-project adjustable knob.
Black is only concerned with source code formatting and does not address things like import styles and their sort order, etc. This means that there are certainly still things to debate in building a comprehensive style guide (and things I know that we will never have unanimous consent about).
The Toolhub project I bootstrapped has a style guide, but it is implemented in the configuration of linters including Black rather than by prose description. A convention in that project is that if a linter has not complained about a purely stylistic part of a change the reviewer should not either. Finding a thing in the code that makes your eyes hurt is a prompt to propose a global style change, but not to block a patch. -- BryanDavis (talk) 20:59, 18 August 2022 (UTC)