main.go does not pass lint test

oduwsdl / MemGator

A Memento Aggregator CLI and Server in Go

https://memgator.cs.odu.edu/api.html

MIT License

55 stars 11 forks source link

main.go does not pass lint test #54

Closed machawk1 closed 8 years ago

machawk1 commented 8 years ago

Largely an issue of style but until we have some CI system setup for the repo, we ought to at least align with convention per https://github.com/golang/lint.

[ ] main.go:22:2: exported const Name should have comment (or a comment on this block) or be unexported
[ ] main.go:57:6: exported type Session should have comment or be unexported
[ ] main.go:61:6: exported type Archive should have comment or be unexported
[x] main.go:62:2: struct field Id should be ID
[x] main.go:70:6: exported type Archives should have comment or be unexported
[x] main.go:84:1: receiver name a should be consistent with previous receiver name slice for Archives
[ ] main.go:97:6: exported type Link should have comment or be unexported
[x] main.go:417:6: func parseUri should be parseURI

machawk1 commented 8 years ago

@ibnesayeed The *Archives is akin to a pointer (Go probably has its own name for it) but the Linter complains. Suggestions on remedying this?

ibnesayeed commented 8 years ago

I was not too much into linting it as the code really need some serious refactoring. Let me have a look at whats the complain about the *Archive thing and then I will see what can be done about it.

ibnesayeed commented 8 years ago

I don't see it being names something else anywhere else or I am failing to understand the suggestion by the linter well.

ibnesayeed commented 8 years ago

I don't see anything wrong according to the Receiver Names code review comments.

machawk1 commented 8 years ago

Be consistent, too: if you call the receiver "c" in one method, don't call it "cl" in another.

Maybe the linter is having issues with: func (slice Archives) vs func (a *Archives)

ibnesayeed commented 8 years ago

Yes, you were right, that was the issue. I have fixed and pushed the code. I would encourage you to make a pull request of your other changes in 11503d3 as well.

machawk1 commented 8 years ago

I merged 11503d3bc58fc4ca8ce1cb2e6685f8ae8a7b66ee but need to re-validate the lint before closing this issue.

machawk1 commented 8 years ago

That fixed the Receiver issue, @ibnesayeed , but the comment issues still need to be resolved to close this ticket.

ibnesayeed commented 8 years ago

Yes, we will keep this issue open. Investing of comments only makes sense after doing some refactoring. There is no point on adding comments just to pass the lint that might changes latter. I came to know something about the function arguments little late that I would like to do when refactoring. Which might actually change the function signatures, but would make them more compact.