When would you use Variables And Short Declaration in a real project

In a real Go project, I use := for most new local values because it keeps ordinary function code compact. A statement such as user, err := repository.Find(id) introduces both results and lets the compiler infer their types from the function signature. Writing the types again would usually add noise without adding information.

I use var when the variable must exist before a useful value is available. For example, var result Result clearly says that result begins with its zero value and will be filled by one of several branches. The declaration also makes the variable available after those branches.

Package-level state must use var because short declarations are not valid outside function bodies. A package declaration such as var buildVersion = "dev" may later be replaced during the build. I still avoid unnecessary mutable package state because it complicates testing and concurrency.

An explicit type is another good reason to use var. var reader io.Reader = file communicates that the code depends on the interface rather than the concrete file type. Similarly, an untyped numeric literal may need an explicit int64, float32, or domain-specific named type.

The mixed short-declaration rule is useful in error-handling code. count, err := strconv.Atoi(value) is valid when err already exists but count is new. If both names already exist, the statement must use = instead.

I choose between the forms based on scope and clarity, not speed; both produce normal statically typed variables after compilation. I also keep declarations close to their first use, unless a wider scope is genuinely required.

My practical default is := for obvious local initialization. I switch to var when I need package scope, a deliberate zero value, a wider scope, or an explicit type that makes the design easier to understand.