Five reasons why not to use global variables?

Introduction
Global variables are those variables which can be accessed and modified by any module.
They are declared in outermost scope so that they are visible to every inner scope module.

They are usually considered as bad practice because of their non locality.They create mutual dependencies and increase complexity of program.However, there are some places where global variables are suitable to use.When one wants to avoid frequent passing of parameters form one function to another, global variables can be of use. They are used to pass information
between modules that do not share called / caller relationship such as concurrent threads and signal handlers or interrupt routines.

Why they should be avoided when unnecessary

As explained in the introduction section, global variables induce interdependency between modules thus increasing complexity of the code making it hard to analyze it.Here I give you other reason for not to use global variable unless absolutely necessary.

Reason 1: Non locality

Global variables are declared in the outmost scope. So if a function uses it in the innermost scope we have to keep track that whether that variable have been modified before that is been used in the function. Functions are easy to analyze when their variables are localized and have minimum influence of other modules over them. If you code is large enough, then another problem called thrashing (related to paging in OS) may occur (only if there is no spare memory left) while executing your code as the variable and code may be on different pages.

Reason 2: Implicit coupling
Coupling between modules of the code should be as low as possible in order to make it maintainable in future. When you use global variables in code,they induce coupling between modules.

Reason 3: Concurrency issues

This case arises when your application is multithreaded. If more than one thread try to access the same variable at the same time, which might result in deadlock situations. Special precaution should be taken to avoid such situation resulting in extra code. We have to implement lock and unlock functions to ensure single thread access to the global variable. There may
be a possibility that threads get obsolete values.

Reason 4: No access control or constraint checking
Global variables can be get or set in any part of the program without worrying about the rules to access them as there are no rules. This greatly hinders security when you are using third party tools.

Reason 5: Difficult to test
Code which use global variables are difficult to test as there is no easy method to set a clean environment between run. It will be very difficult to test modules in isolation as Unit test suggests. There will be some implicit effect of other modules on the module in form of global variables, so it will be difficult to pin point and debug code.

These are five reasons why you should avoid global variables as far as possible.

Confusing testing techniques :(

There are a plenty of testing techniques ranging from ad hoc monkey testing to moral formal unit testing. White box testing, black box testing, Grey box testing and so on so forth. Being under graduate in software engineering or fresher in software industry, you may always confuse between one testing and other.
So let’s explore some of the most confusing and interrelated terms used in testing terminology;
1) Sanity testing and smoke testing
Sanity testing is a testing technique in which you take a specialized functionality of the whole system and travel deep into that and try to find out if the that functionality is working correctly in every aspect. Actually it follows depth first approach.
Smoke testing is testing technique in which you just check broadly whether the system in question worth testing. The scope of the test is whole system and follows breadth first approach.
Smoke testing is generally used in hardware testing, if hardware component produces smoke as soon as it is put in test that means that the component is not yet ready for testing and require more time. Same principle is applied to software too.
2) Regression testing and Retesting
When you fix a bug in code and you want to be sure that this fixing has not affected any other part of the program you re run all existing test case again
This is called regression testing.
Retesting is process in which we write different or more test cases for the same functionality in order to test it completely and satisfactorily after there has been testing with existing test case.
3) Load testing and stress testing
When you test a system for its robustness, giving inputs within the allowed range this is called load testing. For example if an application has to support 500 users, load testing will be done with simulating 500 users and noting the performance degradation of the application.
When you test a system for its robustness, giving inputs which are out of bound or beyond the scope of the system, it’s called stress testing. Like if your system supports only 100 users, and you simulate 110 users and see how the performance of the system degrades.
4) Integration testing and interface testing
When you combine two components that are independently developed you need to test that these two components work correctly together and perform the task assign to the integrated component in seamless manner. To test this you do integration testing.
When there is communication between two components, protocols and message formats are define to communicate. Interface testing confirms that the data passing from one component to another is in the correct and in specified format and follows the protocol decided upon. Whether two components perform the correct task is none of the concern of interface testing.
Hope after reading this post your doubts, about slightly different and confusing testing techniques, may have vanished.