-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
tools: lint for object literal spacing #6592
Conversation
Sample nit for reference: #6005 (comment) |
'magenta' : [35, 39], | ||
'red' : [31, 39], | ||
'yellow' : [33, 39] | ||
'bold': [1, 22], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unrelated but what about having a lint rule to enforce non-quoted keys for keys that don't need quotes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use http://eslint.org/docs/rules/quote-props for that.
Did you use the |
Hmmm, I'm not really sure these are good enough gains when we still ignore all the other parts of object literals because there's just too much variance in the codebase. |
This comment is vague and therefore difficult to understand or address. |
No. Surprisingly, |
It's confusing we only address space-before colon when we don't do anything about space after colon, or space between braces, or possibly even space after comma(?). All in all this is an awful lot of churn that is only partial, since it doesn't even address the others (which, iirc are too large to address). As such, I'd vote we do nothing about it, probably, while trying to move over in a slower fashion. |
@@ -28,8 +28,8 @@ function loadPEM(n) { | |||
|
|||
var server = tls.Server({ | |||
secureProtocol: 'TLSv1_2_server_method', | |||
key: loadPEM('agent2-key'), | |||
cert:loadPEM('agent2-cert') | |||
key: loadPEM('agent2-key'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did this need to change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It didn't need to change, but it appeared to me that the inconsistent spacing of the original was an attempt to align the values in a single column, so I did that. Don't really care either way TBH.
A couple of nits but otherwise LGTM |
@Fishrock123 Wouldn't incorporating those other changes later on be accomplishing things in a "slower fashion?" It seems like adding all of the other related rules at the same time would be contrary to this. |
@Fishrock123 Thanks for clarifying. We lint for all the things you describe except one.
We do. A space after the colon is required with the rule in this PR. Good: Bad:
I don't think it would be confusing if this PR were to land resulting in us linting for spacing in the key/value pairs but not for the curly braces. Admittedly, that's a subjective assessment, though. Anyway, that would be
We lint for comma spacing. Bad: Good:
Thanks again for explaining. I'll throw in one last argument in favor of the change: I cannot help but cringe every time a new contributor gets nits for things that really ought to be caught by tooling. As a project, we've gotten a lot better about not giving every new committer 150 style nits. Honestly, I'm not sure that's because we're any better behaved or if it's because we just have more lint rules now that catch stuff or what. Regardless, I would happily accept a little churn (and this is only 35 files, almost all tests, and most of which only have one or two lines of change) if it means less churn in PRs on stuff that shouldn't matter. |
Yes please. Definitely happy with this one. LGTM |
Seems fine to me. |
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' };
Rebased against master, addressed the nits, squashed, and force pushed. |
Still LGTM |
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' }; PR-URL: nodejs#6592 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
Landed in 4e6dc00 |
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' }; PR-URL: #6592 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' }; PR-URL: nodejs#6592 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' }; PR-URL: #6592 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' }; PR-URL: #6592 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' }; PR-URL: #6592 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
There has been occasional nits for spacing in object literals in PRs but the project does not lint for it and it is not always handled consistently in the existing code, even on adjacent lines of a file. This change enables a linting rule requiring no space between the key and the colon, and requiring at least one space (but allowing for more so property values can be lined up if desired) between the colon and the value. This appears to be the most common style used in the current code base. Example code the complies with lint rule: myObj = { foo: 'bar' }; Examples that do not comply with the lint rule: myObj = { foo : 'bar' }; myObj = { foo:'bar' }; PR-URL: #6592 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
Checklist
Affected core subsystem(s)
tools lib test
Description of change
There have been occasional nits for spacing in object literals in PRs but
the project does not lint for it and it is not always handled
consistently in the existing code, even on adjacent lines of a file.
This change enables a linting rule requiring no space between the key
and the colon, and requiring at least one space (but allowing for more
so property values can be lined up if desired) between the colon and the
value. This appears to be the most common style used in the current code
base.
Example code the complies with lint rule:
Examples that do not comply with the lint rule: