Is the convention for naming slices in Go? Specifically, do you use plurals?
I've noticed that Go App Engine doesn't (eg. it uses key not keys):
func GetMulti(c appengine.Context, key []*Key, dst interface{}) error
I haven't seen anything equivalent in the standard packages or docs I've read. Is singular or plural normal?
That should be a typo, I guess.
Names of slices and arrays are plural. It's not hard to find some samples in the standard library: function SetCookies in CookieJar, Readdirnames, or Args variable in the variables of os package.
But for any variable use a name that better explains its purpose.
A clear exception to this all-plural approach is argv which had its name for decades.
#Mostafa is right. Names of slices and arrays in Go should be a plural. fns is the plural of fn in this example from #Ainar-G. See https://stackoverflow.com/a/35648660/12817546..
package main
import "fmt"
func main() {
var fns []func()
fns = append(fns, beeper)
fns = append(fns, pinger)
for _, fn := range fns {
fn() //beep-beep ping-ping
}
}
func beeper() { fmt.Println("beep-beep") }
func pinger() { fmt.Println("ping-ping") }
#Mostafa is also right that names should explain their purpose. To add to this, self-evident names make code more readable. Self-evident names comment on and document their code.
Self-evident names are consistent. That is they are easy to guess.beeper matches "beep-beep". Self-evident names are accurate. That is they are easy to understand.fns matches fn which denotes a func.
Self-evident names are short. That is they are easy to type. Short names require a short distance between their declaration and their use. Arguments such as fn can be one or two characters-long. For everything else a short one word noun can be used. But sometimes if the distance is great more explanation is needed. A multi-word name mixedCaps can be used. But don't use an under_score_name.
The names used may not be as self-evident as they could be. As a result code may have too many // line comments. Comments can make code less readable. Rename your identifiers so they become more self-evident. And then the number of // can be reduced without loss of explanation.
There are other limits to the use of names. Go keywords cannot be used. Canonical Read, Write, Close, Flush, String etc words should not be used. The first character of a name must be a Unicode letter or a _. Remember capitalized names such as MixedCaps can be exported and type identifiers are typically uppercase.
To find out more have a look at https://talks.golang.org/2014/names.slide, https://blog.golang.org/package-names, https://talks.golang.org/2013/bestpractices.slide, https://golang.org/ref/spec#Identifiers and https://golang.org/doc/effective_go.html#names.
Related
With syntax highlighting enabled, it's distracting while reading code like answer to this question with new used as a variable name.
I'm trying to think of a reason why only a subset of keywords would be reserved and can't come up with a good one.
Edit: Alternate title for this question:
Why are Go's predeclared identifiers not reserved ?
That's because new and make aren't really keywords, but built-in functions.
If you examine the full list of the reserved keywords, you won't see len or cap either...
In short: because using predeclared identifiers in your own declarations don't make your code ambiguous.
new and make are builtin functions, amongst many others. See the full list in the doc of the builtin package.
Keywords are a carefully chosen small set of reserved words. You cannot use keywords as identifiers because that could make interpreting your source ambiguous.
Builtin functions are special functions: you can use them without any imports, and they may have varying parameter and return list. You are allowed to declare functions or variables with the names of the builtin functions because your code will still remain unambiguous: your identifier in scope will "win".
If you would use a keyword as an identifier, you couldn't reach your entity because an attempt to refer to it by its name would always mean the keyword and not your identifier.
See this dirty example of using the predeclared identifiers of the builtin function make and the builtin type int (not recommended for production code) (try it on the Go Playground):
make := func() string {
return "hijacked"
}
int := make() // Completely OK, variable 'int' will be a string
fmt.Println(int) // Prints "hijacked"
If you could use keywords as identifiers, even interpreting declarations would cause headache to the compiler: what would the following mean?
func() - is it calling your function named func or is it a function type with no params and no return types?
import() - is it a grouped import declaration (and importing nothing) or calling our function named import?
...
The below snippet works fine.
In this case, what "int32" is? A func?
I know there is a type named "int32"
This could be a stupid question. I've just finished A Tour of Go but I could not find the answer.(it's possible I'm missing something.)
package main
import "fmt"
func main() {
var number = int32(5)
fmt.Println(number) //5
}
It is a type conversion, which is required for numeric types.
Conversions are required when different numeric types are mixed in an expression or assignment. For instance, int32 and int are not the same type even though they may have the same size on a particular architecture.
Since you do a variable declaration, you need to specify the type of '5'.
Another option, as mentioned by rightfold in the comments is: var number int32 = 5
(as opposed to a short variable declaration like number := 5)
See also Go FAQ:
The convenience of automatic conversion between numeric types in C is outweighed by the confusion it causes.
When is an expression unsigned? How big is the value? Does it overflow? Is the result portable, independent of the machine on which it executes?
It also complicates the compiler; “the usual arithmetic conversions” are not easy to implement and inconsistent across architectures.
For reasons of portability, we decided to make things clear and straightforward at the cost of some explicit conversions in the code. The definition of constants in Go—arbitrary precision values free of signedness and size annotations—ameliorates matters considerably, though.
A related detail is that, unlike in C, int and int64 are distinct types even if int is a 64-bit type.
The int type is generic; if you care about how many bits an integer holds, Go encourages you to be explicit.
I am new to type safe, and can't figure out how to do following
package main
func test(){
print("In Test")
}
func main(){
a := "test"
a()
}
You might get better answers if you state what you're trying to achieve, as reflection is usually not the best way. But reflect will help if the functions are methods on a type (net/rpc is an example of this).
package main
import (
"fmt"
"reflect"
)
type T struct {}
func (T) Add(x, y int) int {
return x + y
}
func main() {
t := reflect.ValueOf(T{})
m := t.MethodByName("Add")
args := []reflect.Value{reflect.ValueOf(1), reflect.ValueOf(2)}
fmt.Println(m.Call(args)[0].Int())
}
If you were wondering how tools like godoc work, they parse the source rather than use reflection.
Edit: Playground version
A function can not be resolved from a string. However, you can assign a function to a variable.
a := test
a()
You can also put functions (assuming they all have the same signature) into a map:
var func_map := map[string]func() {
"test": test,
}
a := func_map["test"]
a()
Response to first comment by OP (too long to make another comment):
A function is not a "literal". "Literal" has a separate meaning.
Second, Go's runtime reflection does not have a lookup table mapping strings to functions. Even if it did, functions are not linked into the binary unless linked to by other code. Code only called in this method would not be in the binary.
Third, making a mapping manually is not that hard. It provides compile time type safety checks as well as security.
This is not something you should be doing in any language. It is like eval(), you really should not use it because it can be incredibly dangerous and cause unpredictable things to happen.
They don't all have the same signature
If they don't all have the same signature, how do you plan to call them? You could use the reflect package, but that is normally an indication that you are doing something wrong.
This is not a dynamic language and some things can not be done in Go. Although, they are mostly things you should not do in most languages anyways.
There's no way to dynamically look up a function by name, but I think it's worth mentioning why. Basically, the reason is so that the compiler and/or linker can eliminate unused functions.
Consider that if you were able to get a function by name, then every function in every imported package (recursively) would have to be linked into the final executable, even if it was never used, just in case someone wanted to look it up by name. People already complain about the large size of Go binaries, but this would cause them to be much larger still.
Ok, I have to admit, I don't really use Go very much at all, but I did just observe something that strikes me as odd for a language that strives for minimality and all that good stuff as Go does. I would be surprised if there isn't a legitimate rationale behind it, so that's what I'm looking for.
So when you have a method, you define it like this:
func (s *SomeStruct) Foo(x int) { }
but why have an extra parameter list just for the "receiver", as I think it's called? Would it not be a simpler and more elegant design to just do
func Foo(s *SomeStruct, x int) { }
and then have s.Foo(5) just be translated to a call to a function Foo(s, 5)?
Methods are fundamentally special and different from regular functions.
Methods must live in the same package as the receiver type.
Methods are used to satisfy interfaces.
Receiver parameters are the only parameters which may be overloaded.
When anonymous struct fields have methods, those methods are "inherited".
With your proposal, the line between a function and a method becomes very blurry and it's difficult to figure out how to resolve the above issues.
That said, I think it would be really interesting to design a language with multimethods and interfaces. However, that language would not be Go.
Your question correctly points out that any method is a function. However, the Go language needs to be able to explicitly distinguish between methods and functions. The reason for this is that methods have features that functions do not have. The choice of whether Foo is a function or a method needs to be made by the programmer.
Go's minimalism means that the language defines only a small set of keywords. The Go authors could have chosen a new keyword, such as method, to distinguish methods from functions:
method Foo(receiver *T, arg1 int) {} // 'Foo' is a method, not a function
Looking around the Go programming language, we can see that the philosophy is to reuse already existing keywords rather than to have a separate keyword for each occasion. The for keyword is a good example of this approach:
for {} // Infinite loop
for a>0 {a--} // A while-do loop
for i := range channel {} // Receive values from a channel
for i:=0; i<N; i++ {} // C-style for loop
The basic idea is that for the parser (and Go programmers) to distinguish the various types of for loops from each other, there is no need to introduce a new keyword if the options can be distinguished by the syntax of what comes after the for keyword: ; := range identifier ..., their sequential order, and their presence/absence.
The func keyword follows the same pattern. It can be used in multiple contexts:
function definitions: func f() {}
function types: type F func(int) int
method definitions: func (t T) SomeMethod() {}
closures: { ...; go func(){c<-1}(); ...}
From minimalism viewpoint, a single func keyword is both simpler and more elegant than having multiple keywords.
The extra parameter list just for the receiver
func (t *T) Foo(x int) {}
enables the parser to distinguish methods and functions:
func IDENTIFIER ... This is going to be a function
func ( ... This is going to be a method
Thus, the parser (as well as Go programmers) can make the distinction based on whether the func keyword is followed by an identifier or by (.
The proposed replacement is not semantically identical to the current state, i.e. it's not a syntactic change only. It will [attempt to] automagically create methods of any [local package] type that happens to be the first parameter of a function. Considering how fundamental method sets are wrt to Go's concept of automatic interface satisfaction rules, this will quite probably lead to a big big mess.
In short, I think such change to the Go language improves nothing while damaging a lot of it's nice features related to methods and interfaces.
Probably because go isn't Python.
Also, because a function declared this way is not a method.
You cannot declare a method outside the object package. So I guess the main rationale in the syntax difference between methods and functions is to be able to differentiate them.
I'm trying to create a map in Go that is keyed by big integers. Effective Go explicitly says that:
Structs, arrays and slices cannot be used as map keys, because equality is not defined on those types.
which makes sense. I could of course convert the big integers to strings and use the string as a key, but I'm looking for a more general solution here. Can I wrap my structure into something (an interface?) that implements an equality function and use that instead?
Example code that, of course, doesn't work:
package main
import (
"big"
"fmt"
)
func main() {
one1 := big.NewInt(1)
one2 := big.NewInt(1)
hmap := make(map[*big.Int] int)
hmap[one1] = 2
_, exists := hmap[one2]
fmt.Printf("Exists=%v\n", exists)
}
The rules about equality are going to change soon. From the Go 1 plan:
Go 1 will define equality on struct and array values composed from
fields on which equality is also defined (element-wise comparison).
It will remove equality on function and map values except for
comparison with nil. Go 1 will continue to exclude equality for
slices. (In the general case it is infeasible.)
However, even with this rules, you can not use *BigInt as key, since it contains a slice. Also note, that it is not possible in Go to write a custom equality operator (neither it is possible to override any other operator). But that's actually a strength of Go in my opinion - things are just simpler without it.
So, you will have to use strings for your keys. The strings however do not need to be formatted in decimal (or any other format) as long as you do not want to print them. So the fastest way is probably to use the Bytes() method (which will also discard the sign, make sure to include that separately in your string).