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

Fix Out-Of-Order Variable Declarations #989

Closed
wants to merge 2 commits into from
Closed

Conversation

s0
Copy link
Contributor

@s0 s0 commented Jun 6, 2017

Following #988, I decided to see if lgtm.com would be useful for enforcing chai's coding style guidelines. I'm not sure if this is the sort of thing you'd be interested in, but I'd love to hear feedback either way.

I wrote a query for variable declaration order, and you can see the results it produces for chai (and mozilla's pdf.js for comparison) here: https://lgtm.com/query/1983330216/lang:javascript/

Currently it's quite a broad query, and has many results in test code, but I can make it more specific if you'd like, and exclude certain results, e,g:

  • if there's whitespace / extra lines between groups of variable declarations, consider them different groups.
  • exclude test code
  • exclude complicated variable declarations (for some definition of complicated)

I'm not sure whether you'd like to include this query in this repository, but it does have some interesting results, some of which I've addressed in a separate commit, and we could start to write further queries. We do have plans to allow projects to run their own custom queries as part of pull request integration soon, but we don't currently have a timeline for that.

If you like this sort of contribution, I can write queries for some of your other guidelines to see what we can find.

Full Disclosure: I'm a core developer at lgtm.com

@keithamus
Copy link
Member

Thanks very much for your work here @samlanning. We're aware there are a few issues with the codebase, and we have some plans to fix them a bit later - we're very likely going to use eslint with a configuration which will catch what this PR provides, and more (we've been trialing this out in sub-projects; example).

Because of that, I think we'll close this PR. If we end up not choosing eslint, we can re-open this and have another look, but right now I'm very confident we'll be sticking with eslint.

@keithamus keithamus closed this Jun 6, 2017
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.

None yet

2 participants