Golang: Understanding Variables

Now that we understand Golang’s project structure and how to write our own packages and commands, it’s time to get to the language basics and learn about variables. We will learn them in a very practical way – by writing code 🙂

The keyword var is the basic form to define variables. A var statement can be at package or function level. Also, Golang puts the variable type after the variable name unlike in languages like C/C++ where the variable type is written before the variable name

int a;

var a int


There are multiple syntax that can be used to define variables in Go

Define single variable

var variable_name variable_type
var variable_name variable_type = value

Define multiple variables

var variable_name1, variable_name2 type
var variable_name1, variable_name2 type = value1, value2

While defining initial values, you can choose to omit the type and can say

var variable_name1, variable_name2 = value1, value2

Group form

Variables can also be declared in a group form like

    variable_name1 = 10
    variable_name2 = “abc”

Short assignment

Now using var and type can be laborious and boring at times. Golang has a short assignment operator := too. This is how it is used:

variable_name1, variable_name2 := value1, value2

It is important to note that short assignments can also be used in function scope. Try using it in the global scope and you will notice errors.

Special variable _

When we want to ignore value of a return statement or discard a value in general, then the special variable name _ is used

_, x = “abc”, 123

Here value “abc” is ignored and x is assigned value of 123.

Unused variables

Also note if a variable is declared in the program but is never used then the Go compiler considers this an error and throws it

./addition.go:11:6: i declared and not used

Variable scopes

Scope is a region of the program where a variable can exist and can’t be accessed outside it. Golang has three different scopes:

  1. Local variables: defined in a function or a block
  2. Global variables: defined outside of all the functions
  3. Formal parameters: used in definition of function parameters (treated as local variables inside the function and take precedence over global variables)

Let’s look at them in a code snippet, we will learn more about the function scope when we talk about functions in detail

package main

import "fmt"

/* global variable declaration */
var a int = 20;

/* local variable declaration in main function */
func main() {
    var a int = 10
    var b int = 20
    var c int = 0

    fmt.Printf("Value of a in main() = %d\n", a);
    c = sum( a, b);
    fmt.Printf("Value of c in main() = %d\n", c);

/* function to add two integers */
func sum(a, b int) int {
    fmt.Printf("Value of a in sum() = %d\n", a);
    fmt.Printf("Value of b in sum() = %d\n", b);
    return a + b;


Value of a in main() = 10
Value of a in sum() = 10
Value of b in sum() = 20
Value of c in main() = 30


Constant values are defined at compile time and can’t be changed during run time. They can be of any data type; some of the examples of constants are shown below:

const abc = “123”;
const evelocity float32 = 11.1


Great, hope you got a fair idea about using variables in Golang. Let us look at the data types supported by Golang in the next blog 🙂

Performance for testing memberships: list vs tuples vs sets

Sets in Python are often used for two purposes:

1. Removing the duplicate entries in a collection

2. For membership testing.

By membership, here we mean to find existence of element in a collection

The focus of this post is to evaluate performance of list, tuple and set data structures with respect to each other on the basis of membership testing.

How do I do it? Well, some code, some data collection and some analysis

from datetime import datetime
listA = range(10000000)
setA = set(listA)
tupA = tuple(listA)

def calc(data, type):
    start = datetime.now()
    if data in type:
        print ""
    end = datetime.now()
    print end-start

calc(9999, listA)
calc(9999, tupA)
calc(9999, setA)

Below is the average of 10 iterations for the time taken by lists/tuples and sets for testing membership of 9999, 99999, 999999 in 10000000

Search 9999 in  10000000
list tuple set
0.8 0.8 1.9
Search 99999 in  10000000
list tuple set
2.6 2.8 1.7
Search 999999 in  10000000
list tuple set
21.4 21.6 0.8


1. for testing membership of elements at the beginning of the collection, lists or tuples perform more than 100% better than sets

2. As soon as you start testing membership of elements that are in the middle or end of the collection, sets perform 40% – 1800% better than lists or tuples

You now have a fair idea why you should think of using sets for large collections…


Hardware I used: windows 7, x64, 4GB RAM

Python version: 2.7.2

Advocating Code Review for Testers

Author: Chetan Giridhar

Published at: testingexperience, September 2010 Edition


                                   image courtesy: http://testingexperience.com


According to Wikipedia, “Code review is systematic examination(often as peer review) of computer source code intended to find andfix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers‘ skills.”

 Code Review has been a good practice featuring as an important part of the software development life cycle. Not only has the practice helped in finding or rather preventing critical defects early in the cycle (thereby reducing the bug fixing costs), but it has also been instrumental in improving developers’ knowledge and build exposure to the other components of the software.

However, have we ever seen QA professionals participating actively in code reviews? With Quality Assurance being a proactive process aimed at preventing defects, wouldn’t code review feature in the QA realm as well? Would it make sense to make code reviews an integral part of QA processes? Are there any risks associated with doing so?

This article aims at breaking the myth, or at least triggering a thought process, of why testers couldn’t be or shouldn’t be an imperative part of code reviews. During the course of this article, the author substantiates the merits of the thought and also throws light on the flip side of it. At the end, the author hopes that the readers (independent of their role in the software industry) give this philosophy sufficient thought and evaluate whether including testers in code reviews would be beneficial as a process and if it would be helpful for their team context or not.

Click to download the article – Advocating Code Review For Testers