I fully agree on the general idea everything should be linted by linters and similar tools that are de-facto standard for their respective language. We should configure them only to deviate from the defaults if it's really necessary.
Manual following the standards while writing and reviewing code won't work at all IMHO. Therefore I don't think we need to write it down in text form, because most people won't read it. It just raises the barrier to contributions and that's something we really shouldn't do. We could gradually configure, document and add lint tools to CI on a repo basis, lint the code once again and then make sure the checks are green in PRs. That would be my pragmatic approach to this and just my personal opinion as someone who reviews a lot of code but rarely works in Cordova these days. On January 8, 2026, "[email protected]" <[email protected]> wrote: > ### Comments on Enforcement > > Code styling is obviously very opinionated and subjective so whatever > what we choose here... it needs to be something that can be enforced > by > a tool. Otherwise conflicting code styles are going to leak through > the > cracks and committed into the code-base. > > If there is a tool that can enforce a code-style, via a lint check > then > we have an authoritative guideline that all contributors must follow. > If it relies on self-discipline, then enforcement will quickly fall > apart. > > ### Comments on conflicting tooling > > IDEs could also be a problem here. I know that Android Studio IDE is > very opinionated, and hard to configure (in my opinion). In my own > projects I constantly fight with the IDE over spacing and such. It > likes to rewrite a lot of formatting. > > Not sure how far editorconfig will get us. Supposedly XCode 16+ and > Android Studio does natively support editorconfig. Pretty sure all the > common your common text code editors (VS Code, Sublime, Atom, etc) all > also support editorconfig natively. > > One problem with editorconfig I believe is that it only enforces it > during authoring time. It doesn't mean a PR won't come in that > violates > rules defined in editorconfig, so the editorconfig cannot be served as > an authoritative policy. Ideally it should just match our lint > policies. > > ### Comments on code styling that cannot be lint checked > > I feel like if a style policy cannot be enforced by a tool to check it > during PR review time then we probably should opt to be un-opinionated > on style generally speaking. These cases could also be reviewed on a > case-by-case basis. > > On Thu, 2026-01-08 at 23:14 +0900, Bryan Ellis wrote: > > I don't exactly have time to fully write out this email but here is > > the PR > > for adding the Coding Style Guideline. > > > > Since there seems to be a lot of questions and behind the scenes > > investigation that's colliding with the work that's going into > > this guideline, I decided to push it ASAP so it can be reviewed and > > people > > can start asking questions and leaving comments. > > > > https://github.com/apache/cordova-docs/pull/1460 > > > > Also I didn't have time to fully prepare a complete demo but here it > > is: > > > > https://github.com/erisu/cordova/tree/demo/style-guide > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
