golang / lint Goto Github PK
View Code? Open in Web Editor NEW[mirror] This is a linter for Go source code. (deprecated)
License: BSD 3-Clause "New" or "Revised" License
[mirror] This is a linter for Go source code. (deprecated)
License: BSD 3-Clause "New" or "Revised" License
Trying to make my build fail when golint finds lint, but that's kind of annoying to do right now with golint because it always exits 0.
It would be useful and consistent with other tools to allow to invoke golint like this:
golint github.com/foo/bar
golint all
golint ./...
Hello!
I'm just wondering if it's valid for Go code to totally ignore values returned from some func.
Example:
func producer() (int, int, error) {
return 10, 20, errors.New("something")
}
func processor() {
producer(); // MATCH /error function returns 3 values, 3 ignored/
}
Test case is prepared in commit elgris@6541f24
Cheers!
Is it possible that checks for the following constructs should be added to lintMake?
Or are they intentionally left out?
Golint doesn't compile since golang changed repo.
Hi,
I have this in my ~/.vimrc:
filetype plugin indent on
set rtp+=~/golib/src/github.com/golang/lint/misc/vim
But when I run ':Lint' in a go file vim says:
E492: Not an editor command: Lint
What am I missing?
Thanks!
I originally prepared a go vet
check for this, but came to the conclusion that it was a better fit for go lint
. I'm opening this issue as a place to stash the idea + tested go vet code until such time as I (or someone else) adapts it.
Running this check over a recent corpus of public code caught this distribution of ugliness:
4303 use ! instead of '== false'
2762 '== true' is extraneous
2710 use ! instead of '!= true'
1398 '!= false' is extraneous
63 '&& false' always yields false
32 '&& true' is extraneous
29 '!!' is extraneous
18 '|| false' is extraneous
17 '|| true' always yields true
Test cases:
func OhItHurts() {
var b bool
_ = b == true // ERROR "'== true' is extraneous"
_ = b == false // ERROR "use ! instead of '== false'"
_ = b != false // ERROR "'!= false' is extraneous"
_ = b != true // ERROR "use ! instead of '!= true'"
_ = b && true // ERROR "'&& true' is extraneous"
_ = true && b // ERROR "'&& true' is extraneous"
_ = b || false // ERROR "'|| false' is extraneous"
_ = b && true && b // ERROR "'&& true' is extraneous"
_ = b && b && true // ERROR "'&& true' is extraneous"
_ = true && b && b // ERROR "'&& true' is extraneous"
_ = !!b // ERROR "'!!' is extraneous"
}
func DebugMeNot() {
var b bool
_ = b && false // ERROR "'&& false' always yields false"
_ = b || true // ERROR "'|| true' always yields true"
_ = true || b // ERROR "'|| true' always yields true"
}
Excerpted vet
check:
func checkBoolUnaryExpr(f *File, e *ast.UnaryExpr) {
if e.Op != token.NOT {
return
}
if u, ok := e.X.(*ast.UnaryExpr); ok && u.Op == token.NOT {
f.Badf(e.Pos(), "'!!' is extraneous")
}
}
var dual = [token.VAR + 1]token.Token{ // token.VAR+1: issue 7951
token.LAND: token.LOR,
token.LOR: token.LAND,
token.EQL: token.NEQ,
token.NEQ: token.EQL,
}
func checkBoolBinaryExpr(f *File, e *ast.BinaryExpr) {
if dual[e.Op] == token.Token(0) { // not a boolean operator
return
}
var tf string
var op token.Token
for _, expr := range [...]ast.Expr{e.X, e.Y} {
if ident, ok := expr.(*ast.Ident); ok {
switch ident.Name {
case "false":
op = dual[e.Op]
tf = ident.Name
break
case "true":
op = e.Op
tf = ident.Name
break
}
}
}
if tf == "" {
return
}
switch op {
case token.EQL, token.LAND:
f.Badf(e.Pos(), "'%s %s' is extraneous", e.Op, tf)
case token.NEQ:
f.Badf(e.Pos(), "use ! instead of '%s %s'", e.Op, tf)
case token.LOR:
f.Badf(e.Pos(), "'%s %s' always yields %s", e.Op, tf, tf)
}
}
Note that most of these can be fixed with simple gofmt -r
invocations.
I'd like to suggest that log messages should be lowercase similar to error messages, e.g.
log.Println("This is a log message")
should probably be lowercased.
Would it be possible to relax the comment requirements for constants so they can also include an optional leading article.
Below is a simple example:
package p
// Mod corresponds to a bitfield of modifier key flags.
type Mod int
// Modifier key flags.
const (
// The ModControl bit is set if one or more Control keys were held down.
ModControl Mod = 1 << iota
// The ModShift bit is set if one or more Shift keys were held down.
ModShift
// The ModAlt bit is set if one or more Alt keys were held down.
ModAlt
// The ModSuper bit is set if one or more Super keys were held down.
ModSuper
)
Running golint on p
gives the following warnings:
p/p.go:8:2: comment on exported const ModControl should be of the form "ModControl ..."
p/p.go:10:2: comment on exported const ModShift should be of the form "ModShift ..."
p/p.go:12:2: comment on exported const ModAlt should be of the form "ModAlt ..."
p/p.go:14:2: comment on exported const ModSuper should be of the form "ModSuper ..."
dougfort@fog:~$ go get github.com/golang/lint/golint
git/gospideroak/src/github.com/golang/lint/lint.go:883: function ends without a return statement
dougfort@fog:~$
plese provide emacs hooks like golang provide for save
Some error messages use the following prefix T.M: error message
where T
refers to the receiver type of a method M
. Below are some examples from the standard library:
math/big/int.go:507:21: error strings should not be capitalized
func (z *Int) Scan(s fmt.ScanState, ch rune) error {
...
return errors.New("Int.Scan: invalid verb")
math/big/rat.go:414:21: error strings should not be capitalized
func (z *Rat) Scan(s fmt.ScanState, ch rune) error {
...
return errors.New("Rat.Scan: invalid verb")
time/time.go:853:27: error strings should not be capitalized
func (t Time) MarshalBinary() ([]byte, error) {
...
return nil, errors.New("Time.MarshalBinary: zone offset has fractional minute")
What are your thoughts on whitelisting this specific use of capitalized error strings?
Hi, I just tried doing a go get github.com/golang/lint/golint
and got the following output on go version go1.1.1 darwin/386
# code.google.com/p/go.tools/go/types
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/exprstring.go:80: x.Slice3 undefined (type *ast.SliceExpr has no field or method Slice3)
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/exprstring.go:82: x.Max undefined (type *ast.SliceExpr has no field or method Max)
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/exprstring.go:83: x.Max undefined (type *ast.SliceExpr has no field or method Max)
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/initorder.go:64: undefined: heap.Fix```
package main
import (
"fmt"
)
func main() {
res := get(3)
fmt.Println(res)
}
func get(i int) int {
if f := i * 2; f == 6 {
return f
} else {
return f * 3
}
}
Running golint displays:
main.go:15:9: if block ends with a return statement, so drop this else and outdent its block
The $GOPATH
variable is defined to be a platform list (ie, on Unix, something with colons in it), so the README instructions fail because the globpath() parameter is a supposed to be a vim string delimiting items with commas.
The closest I've gotten to correct is this:
if exists("$GOPATH")
let t=globpath(substitute($GOPATH, ":", ",", "g"), "src/github.com/golang/lint/misc/vim")
if t != ""
let &runtimepath.=','.t
endif
unlet t
endif
Perhaps of use.
should omit type uint32 from declaration of var flags; it will be inferred from the right-hand side
This is technically incorrect, as type inference assumes int.
This is similar to #7.
The line in question is this ugly bit of code:
var flags uint32 = syscall.IN_MOVED_TO | syscall.IN_MOVED_FROM |
syscall.IN_CREATE | syscall.IN_ATTRIB | syscall.IN_MODIFY |
syscall.IN_MOVE_SELF | syscall.IN_DELETE | syscall.IN_DELETE_SELF
Note: I updated to latest to confirm that this is still an issue, ae65d27.
One example is here: https://skia.googlesource.com/buildbot/+/master/perf/go/db/db.go
golint says:
perf/go/db/db.go:8:2: a blank import should be only in a main or test package, or have a comment justifying it
perf/go/db/db.go:10:2: a blank import should be only in a main or test package, or have a comment justifying it
Running golint on
package main
const kFoo = 1
now gives the error message
foo.go:3:7: const%!(EXTRA string=kFoo, string=foo)
instead of the expected "don't use leading k in Go names"
git bisect tells me the error was introduced in 7430178 , introducing lint problem categorization.
Note that testdata/names.go fails with a similar error
names.go:39:2: const%!(EXTRA string=kLeadingKay, string=leadingKay)
I would expect golint to also accept package names as arguments, like all the vanilla go test/vet tools do. Files and directories should be accepted as well (just like it is right now).
For example golint ./...
should check the current package and all packages below.
golint
could have a flag to output suggestions in a format that gorename
understands. ie:
$ golint -o=golint.ascii .
$ cat golint.ascii
file.go:#123 ID // id -> ID
another_file.go:#666 MyFunction // My_function -> MyFunction
(format of the ASCII file is of course just an example)
alternatively, golint
could have a mode to apply directly the changes but that seems a bit against the "suggestions" spirit of golint
.
what do you think ?
URL github.com/golang/lint/golint isn't exist anymore, so that I can not use go get to install golint.
Golint does not compile if I use go.tools repository 1.3 branch:
# github.com/golang/lint
../../../github.com/golang/lint/lint.go:237: p.typesInfo.TypeOf undefined (type *types.Info has no field or method TypeOf)
../../../github.com/golang/lint/lint.go:243: p.typesInfo.ObjectOf undefined (type *types.Info has no field or method ObjectOf)
It's a problem, because if you use Go 1.3, godoc requires go.tools 1.3 branch:
https://code.google.com/p/go/issues/detail?id=8769
I tried to use find
and xargs
with golint but it crashes. If I pass -L 1
to xargs
it runs just fine.
ericu@ericu-trusty-ubuntu:~/rtb/src/spiceworks.com/rtb$ find . -type f -name '*.go' | xargs golint
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x58 pc=0x50e064]
goroutine 16 [running]:
runtime.panic(0x657b80, 0x7d76d3)
/home/ericu/builds/go/src/pkg/runtime/panic.c:279 +0xf5
code.google.com/p/go.tools/go/types.(_Info).TypeOf(0xc208bc39f0, 0x7fd71cdcfc70, 0xc208b950c0, 0x0, 0x0)
/home/ericu/rtb/src/code.google.com/p/go.tools/go/types/api.go:219 +0x194
github.com/golang/lint.(_pkg).typeOf(0xc20801af00, 0x7fd71cdcfc70, 0xc208b950c0, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:231 +0x74
github.com/golang/lint.func·007(0x7fd71caf7838, 0xc208b8e870, 0xc208b8b501)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:827 +0x5c2
github.com/golang/lint.walker.Visit(0xc208ce67a0, 0x7fd71caf7838, 0xc208b8e870, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:1185 +0x48
go/ast.Walk(0x7fd71caf7750, 0xc208ce67a0, 0x7fd71caf7838, 0xc208b8e870)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:52 +0x58
go/ast.Walk(0x7fd71caf7750, 0xc208ce67a0, 0x7fd71caf77a8, 0xc208b92c80)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:329 +0x21e0
go/ast.walkDeclList(0x7fd71caf7750, 0xc208ce67a0, 0xc2083b0600, 0x13, 0x20)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:38 +0xd1
go/ast.Walk(0x7fd71caf7750, 0xc208ce67a0, 0x7fd71cdf99d0, 0xc208b74c80)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:351 +0x2cb6
github.com/golang/lint.(_file).walk(0xc208ba0140, 0xc208ce67a0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:1161 +0x82
github.com/golang/lint.(_file).lintVarDecls(0xc208ba0140)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:852 +0x8c
github.com/golang/lint.(_file).lint(0xc208ba0140)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:145 +0x6d
github.com/golang/lint.(_pkg).lint(0xc20801af00, 0x0, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:122 +0xf0
github.com/golang/lint.(*Linter).LintFiles(0xc208dd5c90, 0xc208026ba0, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:79 +0x3de
main.lintFiles(0xc20800e010, 0x7b, 0x7b)
/home/ericu/rtb/src/github.com/golang/lint/golint/golint.go:76 +0x235
main.main()
/home/ericu/rtb/src/github.com/golang/lint/golint/golint.go:50 +0x183
goroutine 19 [finalizer wait]:
runtime.park(0x4146d0, 0x7dbf90, 0x7daa89)
/home/ericu/builds/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0x7dbf90, 0x7daa89)
/home/ericu/builds/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
/home/ericu/builds/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
/home/ericu/builds/go/src/pkg/runtime/proc.c:1445
ericu@ericu-trusty-ubuntu:~/rtb/src/spiceworks.com/rtb$ find . -type f -name '*.go' | wc -l
123
One reason to have an underscore in a variable name is to simulate a decimal in a number, for example
case3_1
Golint suggests a correction to case31 which does not have the same feel. One could argue about the merits of case3_1 as a variable name, but in any event the correction should not be to elide the underscore.
Hi there. I'm new to Go and am trying to run go lint on a program I'm writing. I'd like clarification on the usage of this library from the command-line.
I've verified the installation went to the directory: go/src/github.com/golang/lint
If I'm in the directory of the code I'm working on (/go/src/github.com/jyaunches/my_program), should I be able to run lint with:
go lint filename.go
??
When I do this, I get:
go: unknown subcommand "lint"
I'm thinking maybe my Go installation isn't completely hooked up properly.. but as I can't find exact usage examples, I thought I would check.
Thanks!
Running golint over code like:
/* Package foo does some stuff
Extra notes about foo that I want in the godoc
*/
package foo
generates the warning:
package comment should not have leading space
Changing it to
/*Package foo ...
"solves" the problem but looks ugly.
Another workaround is to use
// Package foo does some stufff
/* Extra notes about foo I want in the godoc
*/
package foo
but neither of these are suggested. Perhaps a better comment or check should be "Package comment should start with //"
I have a function
TestMulti(t *testing.T)
in package test
golint says: "func name will be used as test.TestMulti by other packages, and that stutters; consider calling this Multi"
With that signature, the TestMulti function is clearly there to be able to be used by go test. I'm not exactly sure what the recommendation should be (tests should live in the same package as the function they're testing?), but the stutter is not the problem here.
I used to run golint on a directory and subdirectories with golint .
.
Currently, it only lints the current directory.
I also tried to run golint ./...
but I get:
golint ./...
import "./...": import relative to unknown directory
I've now been bitten by this about four times in the last couple of weeks; importing a package "package/noun", and then ending up with code that looks something like:
noun := GetCurrentNoun()
if noun == nil {
noun = noun.DefaultNoun()
}
which fails with a semi-bizarre error message about how DefaultNoun is undefined because type noun.Noun has no field or method DefaultNoun. Careful reading of the error message shows it is correct, but it is surprising.
Seems to fit into the style with HTML and URL there already.
It seems that vim setup documentation should be updated. Running :Lint produces error, while running :GoLint does the thing.
Hi,
I just try to compile your projet, I get the following error :
└─(1080)── go build
# _/home/g179197/perso/lint
./lint.go:734: function ends without a return statement
I believe it's a trivial missing return that can be easily fixed :
diff --git a/lint.go b/lint.go
index b63914b..8cacdc8 100644
--- a/lint.go
+++ b/lint.go
@@ -753,6 +753,7 @@ Loop:
}
return false
}
+ return true
}
Modern Java IDEs and Visual Studio can inspect the source code and indicate that boolean expression can be simplified.
It would be nice to see such feature for Go.
Given
type Interface interface {
//I don't mention the name.
F()
}
I would expect
comment on exported interface method F should be of the form "F ..."
Currently no warning is emitted.
(13:48) jnml@fsc-r550:~/src/tmp/golint$ cat main.go
package main
type b []byte
func foo() []byte { return nil }
func main() {
var x b = foo()
}
(13:49) jnml@fsc-r550:~/src/tmp/golint$ golint main.go
main.go:8:8: should omit type b from declaration of var x; it will be inferred from the right-hand side
(13:49) jnml@fsc-r550:~/src/tmp/golint$
This should be in the readme... but what's the difference between this and go fmt
?
ff22a87 causes golint to panic during execution. I tried removing the changes to lint.go
in this commit and then golint was able to properly execute without panicking.
Panic output:
$ $HOME/gopath/bin/golint **/*.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x58 pc=0x4ea5d5]
goroutine 1 [running]:
runtime.panic(0x6038a0, 0x8a8cc8)
/home/travis/.gvm/gos/go1.2.2/src/pkg/runtime/panic.c:266 +0xb6
code.google.com/p/go.tools/go/types.(*Info).TypeOf(0xc2103516e0, 0x7f84366b8690, 0xc210202ae0, 0x7, 0x0)
/home/travis/gopath/src/code.google.com/p/go.tools/go/types/api.go:219 +0x125
github.com/golang/lint.(*pkg).typeOf(0xc2100bc5a0, 0x7f84366b8690, 0xc210202ae0, 0x4, 0x6b33e0)
/home/travis/gopath/src/github.com/golang/lint/lint.go:231 +0x62
github.com/golang/lint.func·007(0x7f84366cf980, 0xc2101f9aa0, 0x20b36517a00)
/home/travis/gopath/src/github.com/golang/lint/lint.go:827 +0x4d3
github.com/golang/lint.walker.Visit(0xc21034e2c0, 0x7f84366cf980, 0xc2101f9aa0, 0x456086, 0x0)
/home/travis/gopath/src/github.com/golang/lint/lint.go:1185 +0x36
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf980, 0xc2101f9aa0)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:52 +0x58
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf710, 0xc210200b00)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:329 +0x2033
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cfb30, 0xc2101faad0)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:186 +0x358a
go/ast.walkStmtList(0x7f84366cf6b8, 0xc21034e2c0, 0xc2101ff580, 0x6, 0x8)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:32 +0x95
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf4a0, 0xc210205630)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:224 +0x3e8a
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf800, 0xc210205660)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:342 +0xbf4
go/ast.walkDeclList(0x7f84366cf6b8, 0xc21034e2c0, 0xc210200fc0, 0x4, 0x4)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:38 +0x95
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366ca580, 0xc2101ff700)
/home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:351 +0x2a52
github.com/golang/lint.(*file).walk(0xc210207640, 0xc21034e2c0)
/home/travis/gopath/src/github.com/golang/lint/lint.go:1161 +0x64
github.com/golang/lint.(*file).lintVarDecls(0xc210207640)
/home/travis/gopath/src/github.com/golang/lint/lint.go:852 +0x8c
github.com/golang/lint.(*file).lint(0xc210207640)
/home/travis/gopath/src/github.com/golang/lint/lint.go:145 +0x6d
github.com/golang/lint.(*pkg).lint(0xc2100bc5a0, 0xc2100ad7b0, 0x7fff0d67cd84, 0x12)
/home/travis/gopath/src/github.com/golang/lint/lint.go:122 +0xb6
github.com/golang/lint.(*Linter).LintFiles(0x7f8436518d38, 0xc21003ab40, 0x7fff0d67cea5, 0x17, 0xc2100a9000, ...)
/home/travis/gopath/src/github.com/golang/lint/lint.go:79 +0x309
main.lintFiles(0xc21000a010, 0x55, 0x55)
/home/travis/gopath/src/github.com/golang/lint/golint/golint.go:76 +0x1f1
main.main()
/home/travis/gopath/src/github.com/golang/lint/golint/golint.go:50 +0x17b
Source: https://travis-ci.org/natebrennand/twiliogo/builds/34879381
Currently, golint complains about a function containing an underscore because the established style for function names is CamelCase. However, the example functions for the testing
package sometimes need to have underscores in their names so they're displayed correctly by godoc. Is this worth fixing?
When invoked from the command line like golint *
, it would be useful to see names of the files that had the error. Lines 33 and 40 of golint.go could be changed to, for example:
log.Printf("Failed reading file %v: %v", filename, err)
The use of "ID" rather than "Id" breaks the rule about abbreviations vs initialisms. "ID" is an initialism for "Identifying Documents", whereas "Id" is an abbreviation for "identifier". Typically, in software engineering, we are referring to the latter.
I understand that in Google and with a lot of Go code, the use of "ID" is considered the correct style. However, there are cases where code cannot follow this convention, such as when avoiding API breakage.
It would be nice to have the ability to disable this rule, such that we continue using golint for some of its better advice, such as documentation.
In golint.el, please replace concat "golint " buffer-file-name
with combine-and-quote-strings (list "golint" buffer-file-name)
to allow file names that need quoting.
I know there's a TODO item for this
https://github.com/golang/lint/blob/master/golint/golint.go#L116
but after the switch to package mode, it's hard to lint the whole package at one go if tests include both pkg
and pkg_test
without seeing X is in package pkg, not pkg_test
, so IMO this is more of a necessity now.
golint flags LastInsertId
godrv/driver.go:160:18: func LastInsertId should be LastInsertID
'though I have to implement database/sql/Result interface, which has LastInsertId.
Can I suppress this flag?
Thanks,
GThomas
Hi,
Since the last commit (54857da) golint fails with a lot of "undeclared name: someIdentifier" errors.
Some examples:
database.go:14:35: undeclared name: config
dumper.go:51:43: undeclared name: adminSessionsByKey
someFile.go:12:21: undeclared name: dbShared
I'm running golint *.go
, but have also tried golint ./
; same results.
All the errors seem to be about package-wide globals defined in files other than the one being linted.
Is this a problem in golint, or am I using golint the wrong way?
When using golint at commit 4b1924a I get no errors.
The _POST
declaration in the following snippet gives me the error twitter.go:55:2: don't use ALL_CAPS in Go names; use CamelCase
const (
_GET = iota
_POST = iota
)
Full code: https://github.com/ChimeraCoder/anaconda/blob/master/twitter.go#L53-L57
(Interestingly, _GET
does not return an error, though it does if I add any characters to the name - I guess it is special-cased somehow).
I feel that this style (a capitalized constant, prepended with an underscore to prevent it from being exported) should not be considered ALL_CAPS
for the purposes of golint - I'm not sure what the alternative CamelCase would be, since this is a single word
I'm filing an issue rather than submitting a pull request in case there is a reason for this style suggestion that I'm not aware of, but as it stands, this error message seems either incorrect or misleadingly named.
Right now, the linter flags symbols like AutoISO14443_4
as not conforming to the Go naming conventions and suggests removing the underscore. I expect that removing an underscore between numbers is almost never a good suggestion as the underscore usually separates different numbers from one another. I request the linter to not issue a warning for such occurances of underscores.
Hey there! I hope I'm not just being stupid here.
go version
:
go version go1.2.2 darwin/amd64
Running on Yosemite public beta 3.
The results of go get github.com/golang/lint/golint
are:
../../src/github.com/golang/lint/lint.go:237: p.typesInfo.TypeOf undefined (type *types.Info has no field or method TypeOf)
../../src/github.com/golang/lint/lint.go:836: f.pkg.typesInfo.ObjectOf undefined (type *types.Info has no field or method ObjectOf)
EDIT
Looks like it might be an issue with my gopath. Hang on.
EDIT
Yep, it was a problem with my GOPATH. I had multiple paths in my gopath, including company tools with a package called types. I think that was causing confusion. Once I set the gopath to a different location go get
works just fine.
pubnubMessaging/pubnub.go:34:7: don't use underscores in Go names; const _invalidJson should be _invalidJSON
The _ wasn't removed, and the JSON was capitalized.
A minor issue to be sure, but hey, report early report often ..
function lines number > n(maybe 50) or single file lines > n(maybe 500) are bad smell, could you check this?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.