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

check: use "comma,ok" for all type assertions #28

Merged
merged 1 commit into from
May 4, 2018
Merged

check: use "comma,ok" for all type assertions #28

merged 1 commit into from
May 4, 2018

Conversation

quasilyte
Copy link
Contributor

Use "ok" to check against type assertion failure
everywhere for consistency.

Also s/point/ptr/ as "point" is not very common
abbreviation for pointer (it could be just "p" as well).

Use "ok" to check against type assertion failure
everywhere for consistency.

Also s/point/ptr/ as "point" is not very common
abbreviation for pointer (it could be just "p" as well).
Copy link
Owner

@mvdan mvdan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks good, and yes, consistency is important.

Just FYI, the reason that x, _ := y.(T); if x == nil is sometimes better than x, ok := y.(T); if !ok is that you use one less variable, and you avoid the ok && x == nil case (which is an edge case).

But either is equally correct most of the time, as we should never have that edge case here. And, as you say, consistency :)

@mvdan mvdan merged commit f2c87d2 into mvdan:master May 4, 2018
@quasilyte
Copy link
Contributor Author

Just FYI, the reason that x, _ := y.(T); if x == nil is sometimes better than x, ok := y.(T); if !ok is that you use one less variable, and you avoid the ok && x == nil case (which is an edge case).

Thanks.

I wanted to get involved and found no real low hanging fruits, so did this. :)

@mvdan
Copy link
Owner

mvdan commented May 4, 2018

There are some ways to make the tool more precise, but I doubt there's any hanging fruit :)

If you want ideas, run the tool on the Go tree, and see if any warnings are wrong (false positives). Or if you find an unused parameter and the tool didn't find it, that should also be fixed (false negative).

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