1 min read
Are you maintaining dead code?
I’m taking a break from the Go spec today to talk about a new tool I just discovered, that saved me a bunch of work. One of the clients I’m working with has a rather old codebase, filled with a bunch of retired features. It was a laborious task to go through all the thousands of files in the project to see which functions and types were no longer being used.
2 min read
Constant types
Long-time readers may recall that constants may be typed or untyped. Today we expore the details of how such constants are declared. Constant declarations … If the type is present, all constants take the type specified, and the expressions must be assignable to that type, which must not be a type parameter. If the type is omitted, the constants take the individual types of the corresponding expressions. If the expression values are untyped constants, the declared constants remain untyped and the constant identifiers denote the constant values.
2 min read
Constant declarations
I’m live streaming again! You’ll probably read this after the fact, but if not, come join me live, or catch the replay! I’ll be building a real-world linter from scratch, picking up from the tutorial I did 2 weeks ago. If you’ve been reading me for a while, you’ll recall we’ve already talked about constants in Go. However, we’ve done it in a slightly more abstract sense; constant literals, and they’re types.
1 min read
Uniqueness of identifiers
Uniqueness of identifiers Given a set of identifiers, an identifier is called unique if it is different from every other in the set. Two identifiers are different if they are spelled differently, or if they appear in different packages and are not exported. Otherwise, they are the same. This is pretty simple stuff, but it’s obviously worth being explicit. foo and bar are obviously different identifiers. Further, a in package foo, and a in package bar are different identifiers, because although they are spelled the same, they are not exported, and are in different packages.
Subscribe to Boldly Go: Daily
Every day I'll send you advice to improve your understanding of Go. Don't miss out! I will respect your inbox, and honor my privacy policy.
Unsure? Browse the archive.
2 min read
Exported identifiers
Exported identifiers An identifier may be exported to permit access to it from another package. An identifier is exported if both: the first character of the identifier’s name is a Unicode uppercase letter (Unicode character category Lu); and the identifier is declared in the package block or it is a field name or method name. All other identifiers are not exported. The main surprising thing to take out of this section is that an exported field or method may be accessible outside of the package even if the type it’s defined on is not!
1 min read
Predeclared identifiers
Predeclared identifiers The following identifiers are implicitly declared in the universe block: Types: any bool byte comparable complex64 complex128 error float32 float64 int int8 int16 int32 int64 rune string uint uint8 uint16 uint32 uint64 uintptr Constants: true false iota Zero value: nil Functions: append cap close complex copy delete imag len make new panic print println real recover Perhaps confusingly, any of these can be shadowed. That is, you can bind these names to your own variables, constants, functions, etc.
1 min read
Blank identifier
Blank identifier The blank identifier is represented by the underscore character _. It serves as an anonymous placeholder instead of a regular (non-blank) identifier and has special meaning in declarations, as an operand, and in assignment statements. Ah, the blank identifier! We’ve talked about it in a few contexts already. Namely, struct field names, as well as binding variables. But it can be used in many places… Including a few surprising places, where it never serves a purpose.
3 min read
Label scopes
Last Monday we had a great time on the Boldly Go: Live livestream, as we built a simple linter by following an online tutorial. For the next live stream, I intend to build a real linter, to solve some real world problems on one of my open source projects. Normally, I would do that today, but my office is undergoing some serious rennovation (three walls and the ceiling are being removed and replaced), so I don’t have anywhere to record from.
3 min read
Scope of the package clause
If you’ve written any code in Go, you’ve seen the package clause: package main So what is the scope of this clause? Declarations and scope … The package clause is not a declaration; the package name does not appear in any scope. Its purpose is to identify the files belonging to the same package and to specify the default package name for import declarations. If it has no scope, why is it needed?
1 min read
Shadowing
The concept of shadowing should be familiar to many readers. But here we see how Go defines it… Declarations and scope … An identifier declared in a block may be redeclared in an inner block. While the identifier of the inner declaration is in scope, it denotes the entity declared by the inner declaration. Notice that shadowing is not limited to variables. You can shadow function names, types, constants, or variables.
1 min read
Scope within functions
Today we’re rounding out the list of scoping rules, with two more: Declarations and scope … The scope of a constant or variable identifier declared inside a function begins at the end of the ConstSpec or VarSpec (ShortVarDecl for short variable declarations) and ends at the end of the innermost containing block. The scope of a type identifier declared inside a function begins at the identifier in the TypeSpec and ends at the end of the innermost containing block.