Are global variables bad

Question

In C C    are global variables as bad as my professor thinks they are

User · Answer

Yes  but you don t incur the cost of global variables until you stop working in the code that uses global variables and start writing something else that uses the code that uses global variables  But the cost is still there   In other words  it s a long term indirect cost and as such most people think it s not bad

User · Answer

In a multi-threaded application  use local variables in place of global variables to avoid a race condition    A race condition occurs when multiple thread access a shared resource  with at least one thread having a write access to the data  Then  the result of the program is not predictable  and depends on the order of accesses to the data by different threads   More on this here  https   software intel com en-us articles use-intel-parallel-inspector-to-find-race-conditions-in-openmp-based-multithreaded-code

User · Answer

Global variables are bad  if they allow you to manipulate aspects of a program that should be only modified locally  In OOP globals often conflict with the encapsulation-idea

User · Answer

Use of Global variables actually depends on the requirements  Its advantage is that it reduces the overhead of passing the values repeatedly   But your professor is right because it raises security issues so use of global variables should be avoided as much as possible  Global variables also create problems which are sometimes  difficult to debug    For example -   Situations when the variables values is getting modified on runtime  At that moment its difficult to identify which part of code is modifying it and on what conditions

User · Answer

The problem with global variables is that since every function has access to these  it becomes increasingly hard to figure out which functions actually read and write these variables    To understand how the application works  you pretty much have to take into account every function which modifies the global state  That can be done  but as the application grows it will get harder to the point of being virtually impossible  or at least a complete waste of time     If you don t rely on global variables  you can pass state around between different functions as needed  That way you stand a much better chance of understanding what each function does  as you don t need to take the global state into account

User · Answer

Global variables are as bad as you make them  no less   If you are creating a fully encapsulated program  you can use globals   It s a  sin  to use globals  but programming sins are laregly philosophical   If you check out L in oleum  you will see a language whose variables are solely global   It s unscalable because libraries all have no choice but to use globals   That said  if you have choices  and can ignore programmer philosophy  globals aren t all that bad   Neither are Gotos  if you use them right   The big  bad  problem is that  if you use them wrong  people scream  the mars lander crashes  and the world blows up    or something like that

User · Answer

I usually use globals for values that are rarely changed like singletons or function pointers to functions in dynamically loaded library  Using mutable globals in multithreaded applications tends to lead to hard to track bug so I try to avoid this as a general rule   Using a global instead of passing an argument is often faster but if you re writing a multithreaded application  which you often do nowadays  it generally doesn t work very well  you can use thread-statics but then the performance gain is questionable

User · Answer

In web applications within an enterprize can be used for holding session window thread user specific data on the server for reasons of optimization and to preserve against loss of work where connection are unstable  As mentioned  race conditions need to be handled  We use a single instance of a class for this information and it is carefully managed

User · Answer

In a multi-threaded application  use local variables in place of global variables to avoid a race condition    A race condition occurs when multiple thread access a shared resource  with at least one thread having a write access to the data  Then  the result of the program is not predictable  and depends on the order of accesses to the data by different threads   More on this here  https   software intel com en-us articles use-intel-parallel-inspector-to-find-race-conditions-in-openmp-based-multithreaded-code

User · Answer

Global variables should only be used when you have no alternative  And yes  that includes Singletons  90  of the time  global variables are introduced to save the cost of passing around a parameter  And then multithreading unit testing maintenance coding happens  and you have a problem   So yes  in 90  of the situations global variables are bad  The exceptions are not likely to be seen by you in your college years  One exception I can think off the top of my head is dealing with inherently global objects such as interrupt tables  Things like DB connection seem to be global  but ain t

User · Answer

Global are good when it comes to configuration   When we want our configuration changes to have a global impact on entire project    So we can change one configuration and the changes are directed to entire project   But I must warn you would have to be very smart to use globals

User · Answer

My professor used to say something like   using global variables are okay if you use them correctly   I don t think I ever got good at using them correctly  so I rarely used them at all

User · Answer

I think your professor is trying to stop a bad habit before it even starts     Global variables have their place and like many people said knowing where and when to use them can be complicated   So I think rather than get into the nitty gritty of the why  how  when  and where of global variables your professor decided to just ban  Who knows  he might un-ban them in the future

User · Answer

I think your professor is trying to stop a bad habit before it even starts     Global variables have their place and like many people said knowing where and when to use them can be complicated   So I think rather than get into the nitty gritty of the why  how  when  and where of global variables your professor decided to just ban  Who knows  he might un-ban them in the future

User · Answer

No they are not bad at all   You need to look at the  machine  code produced by the compiler to make this determination  sometimes it is far far worse to use a local than a global    Also note that putting  static  on a local variable is basically making it a global  and creates other ugly problems that a real global would solve    local globals  are particularly bad   Globals give you clean control over your memory usage as well  something far more difficult to do with locals   These days that only matters in embedded environments where memory is quite limited   Something to know before you assume that embedded is the same as other environments and assume the programming rules are the same across the board   It is good that you question the rules being taught  most of them are not for the reasons you are being told   The most important lesson though is not that this is a rule to carry with you forever  but this is a rule required to honor in order to pass this class and move forward   In life you will find that for company XYZ you will have other programming rules that you in the end will have to honor in order to keep getting a paycheck   In both situations you can argue the rule  but I think you will have far better luck at a job than at school   You are just another of many students  your seat will be replaced soon  the professors wont  at a job you are one of a small team of players that have to see this product to the end and in that environment the rules developed are for the benefit of the team members as well as the product and the company  so if everyone is like minded or if for the particular product there is good engineering reason to violate something you learned in college or some book on generic programming  then sell your idea to the team and write it down as a valid if not the preferred method   Everything is fair game in the real world   If you follow all of the programming rules taught to you in school or books your programming career will be extremely limited   You can likely survive and have a fruitful career  but the breadth and width of the environments available to you will be extremely limited   If you know how and why the rule is there and can defend it  thats good  if you only reason is  because my teacher said so   well thats not so good     Note that topics like this are often argued in the workplace and will continue to be  as compilers and processors  and languages  evolve so do these kinds of rules and without defending your position and possibly being taught a lesson by someone with another opinion you wont move forward    In the mean time  then just do whatever the one that speaks the loudest or carries the biggest stick says  until such a time as you are the one that yells the loudest and carries the biggest stick

User · Answer

Global variables are generally bad  especially if other people are working on the same code and don t want to spend 20mins searching for all the places the variable is referenced  And adding threads that modify the variables brings in a whole new level of headaches   Global constants in an anonymous namespace used in a single translation unit are fine and ubiquitous in professional apps and libraries   But if the data is mutable  and or it has to be shared between multiple TUs  you may want to encapsulate it--if not for design s sake  then for the sake of anybody debugging or working with your code

User · Answer

The important thing is to remember the overall goal  clarity  The  no global variables  rule is there because most of the time  global variables make the meaning of code less clear   However  like many rules  people remember the rule  and not what the rule was intended to do    I ve seen programs that seem to double the size of the code by passing an enormous number of parameters around simply to avoid the evil of global variables   In the end  using globals would have made the program clearer to those reading it   By mindlessly adhering to the word of the rule  the original programmer had failed the intent of the rule   So  yes  globals are often bad   But if you feel that in the end  the intent of the programmer is made clearer by the use of global variables  then go ahead   However  remember the drop in clarity that automatically ensues when you force someone to access a second piece of code  the globals  to understand how the first piece works

User · Answer

My professor used to say something like   using global variables are okay if you use them correctly   I don t think I ever got good at using them correctly  so I rarely used them at all

User · Answer

Yes  but you don t incur the cost of global variables until you stop working in the code that uses global variables and start writing something else that uses the code that uses global variables  But the cost is still there   In other words  it s a long term indirect cost and as such most people think it s not bad

User · Answer

No they are not bad at all   You need to look at the  machine  code produced by the compiler to make this determination  sometimes it is far far worse to use a local than a global    Also note that putting  static  on a local variable is basically making it a global  and creates other ugly problems that a real global would solve    local globals  are particularly bad   Globals give you clean control over your memory usage as well  something far more difficult to do with locals   These days that only matters in embedded environments where memory is quite limited   Something to know before you assume that embedded is the same as other environments and assume the programming rules are the same across the board   It is good that you question the rules being taught  most of them are not for the reasons you are being told   The most important lesson though is not that this is a rule to carry with you forever  but this is a rule required to honor in order to pass this class and move forward   In life you will find that for company XYZ you will have other programming rules that you in the end will have to honor in order to keep getting a paycheck   In both situations you can argue the rule  but I think you will have far better luck at a job than at school   You are just another of many students  your seat will be replaced soon  the professors wont  at a job you are one of a small team of players that have to see this product to the end and in that environment the rules developed are for the benefit of the team members as well as the product and the company  so if everyone is like minded or if for the particular product there is good engineering reason to violate something you learned in college or some book on generic programming  then sell your idea to the team and write it down as a valid if not the preferred method   Everything is fair game in the real world   If you follow all of the programming rules taught to you in school or books your programming career will be extremely limited   You can likely survive and have a fruitful career  but the breadth and width of the environments available to you will be extremely limited   If you know how and why the rule is there and can defend it  thats good  if you only reason is  because my teacher said so   well thats not so good     Note that topics like this are often argued in the workplace and will continue to be  as compilers and processors  and languages  evolve so do these kinds of rules and without defending your position and possibly being taught a lesson by someone with another opinion you wont move forward    In the mean time  then just do whatever the one that speaks the loudest or carries the biggest stick says  until such a time as you are the one that yells the loudest and carries the biggest stick

User · Answer

Global are good when it comes to configuration   When we want our configuration changes to have a global impact on entire project    So we can change one configuration and the changes are directed to entire project   But I must warn you would have to be very smart to use globals

User · Answer

I think your professor is trying to stop a bad habit before it even starts     Global variables have their place and like many people said knowing where and when to use them can be complicated   So I think rather than get into the nitty gritty of the why  how  when  and where of global variables your professor decided to just ban  Who knows  he might un-ban them in the future

User · Answer

My professor used to say something like   using global variables are okay if you use them correctly   I don t think I ever got good at using them correctly  so I rarely used them at all

User · Answer

Using global variables is kind of like sweeping dirt under a rug  It s a quick fix  and a lot easier in the short term than getting a dust-pan or vacuum to clean it up  However  if you ever end up moving the rug later  you re gonna have a big surprise mess underneath

User · Answer

No they are not bad at all   You need to look at the  machine  code produced by the compiler to make this determination  sometimes it is far far worse to use a local than a global    Also note that putting  static  on a local variable is basically making it a global  and creates other ugly problems that a real global would solve    local globals  are particularly bad   Globals give you clean control over your memory usage as well  something far more difficult to do with locals   These days that only matters in embedded environments where memory is quite limited   Something to know before you assume that embedded is the same as other environments and assume the programming rules are the same across the board   It is good that you question the rules being taught  most of them are not for the reasons you are being told   The most important lesson though is not that this is a rule to carry with you forever  but this is a rule required to honor in order to pass this class and move forward   In life you will find that for company XYZ you will have other programming rules that you in the end will have to honor in order to keep getting a paycheck   In both situations you can argue the rule  but I think you will have far better luck at a job than at school   You are just another of many students  your seat will be replaced soon  the professors wont  at a job you are one of a small team of players that have to see this product to the end and in that environment the rules developed are for the benefit of the team members as well as the product and the company  so if everyone is like minded or if for the particular product there is good engineering reason to violate something you learned in college or some book on generic programming  then sell your idea to the team and write it down as a valid if not the preferred method   Everything is fair game in the real world   If you follow all of the programming rules taught to you in school or books your programming career will be extremely limited   You can likely survive and have a fruitful career  but the breadth and width of the environments available to you will be extremely limited   If you know how and why the rule is there and can defend it  thats good  if you only reason is  because my teacher said so   well thats not so good     Note that topics like this are often argued in the workplace and will continue to be  as compilers and processors  and languages  evolve so do these kinds of rules and without defending your position and possibly being taught a lesson by someone with another opinion you wont move forward    In the mean time  then just do whatever the one that speaks the loudest or carries the biggest stick says  until such a time as you are the one that yells the loudest and carries the biggest stick

User · Answer

As someone said  I m paraphrasing  in another thread  Rules like this should not be broken  until you fully understand the consequences of doing so     There are times when global variables are necessary  or at least very helpful  Working with system defined call-backs for example   On the other hand  they re also very dangerous for all of the reasons you ve been told    There are many aspects of programming that should probably be left to the experts  Sometimes you NEED a very sharp knife  But you don t get to use one until you re ready

User · Answer

I d answer this question with another question   Do you use singeltons  Are singeltons bad     Because  almost all  singelton usage is a glorified global variable

User · Answer

I think your professor is trying to stop a bad habit before it even starts     Global variables have their place and like many people said knowing where and when to use them can be complicated   So I think rather than get into the nitty gritty of the why  how  when  and where of global variables your professor decided to just ban  Who knows  he might un-ban them in the future

User · Answer

Global variables are fine in small programs  but horrible if used the same way in large ones   This means that you can easily get in the habit of using them while learning   This is what your professor is trying to protect you from   When you are more experienced it will be easier to learn when they are okay

User · Answer

security is less means any one can manipulate the variables if they are declared global   for this one to explain take this example if you have balance as a global variable in your bank program the user function can manipulate this as well as bank officer can also manipulate this so there is a problem  only user should be given the read only and withdraw function but the clerk of the bank can add the amount when the user personally gives the cash in the desk this is the way it works

User · Answer

Sooner or later you will need to change how that variable is set or what happens when it is accessed  or you just need to hunt down where it is changed   It is practically always better to not have global variables  Just write the dam get and set methods  and be gland you when you need them a day  week or month later

User · Answer

No they are not bad at all   You need to look at the  machine  code produced by the compiler to make this determination  sometimes it is far far worse to use a local than a global    Also note that putting  static  on a local variable is basically making it a global  and creates other ugly problems that a real global would solve    local globals  are particularly bad   Globals give you clean control over your memory usage as well  something far more difficult to do with locals   These days that only matters in embedded environments where memory is quite limited   Something to know before you assume that embedded is the same as other environments and assume the programming rules are the same across the board   It is good that you question the rules being taught  most of them are not for the reasons you are being told   The most important lesson though is not that this is a rule to carry with you forever  but this is a rule required to honor in order to pass this class and move forward   In life you will find that for company XYZ you will have other programming rules that you in the end will have to honor in order to keep getting a paycheck   In both situations you can argue the rule  but I think you will have far better luck at a job than at school   You are just another of many students  your seat will be replaced soon  the professors wont  at a job you are one of a small team of players that have to see this product to the end and in that environment the rules developed are for the benefit of the team members as well as the product and the company  so if everyone is like minded or if for the particular product there is good engineering reason to violate something you learned in college or some book on generic programming  then sell your idea to the team and write it down as a valid if not the preferred method   Everything is fair game in the real world   If you follow all of the programming rules taught to you in school or books your programming career will be extremely limited   You can likely survive and have a fruitful career  but the breadth and width of the environments available to you will be extremely limited   If you know how and why the rule is there and can defend it  thats good  if you only reason is  because my teacher said so   well thats not so good     Note that topics like this are often argued in the workplace and will continue to be  as compilers and processors  and languages  evolve so do these kinds of rules and without defending your position and possibly being taught a lesson by someone with another opinion you wont move forward    In the mean time  then just do whatever the one that speaks the loudest or carries the biggest stick says  until such a time as you are the one that yells the loudest and carries the biggest stick

User · Answer

Global variables are generally bad  especially if other people are working on the same code and don t want to spend 20mins searching for all the places the variable is referenced  And adding threads that modify the variables brings in a whole new level of headaches   Global constants in an anonymous namespace used in a single translation unit are fine and ubiquitous in professional apps and libraries   But if the data is mutable  and or it has to be shared between multiple TUs  you may want to encapsulate it--if not for design s sake  then for the sake of anybody debugging or working with your code

User · Answer

The issue is less that they re bad  and more that they re dangerous   They have their own set of pros and cons  and there are situations where they re either the most efficient or only way to achieve a particular task   However  they re very easy to misuse  even if you take steps to always use them properly   A few pros    Can be accessed from any function  Can be accessed from multiple threads  Will never go out of scope until the program ends    A few cons    Can be accessed from any function  without needing to be explicitly dragged in as a parameter and or documented  Not thread-safe  Pollutes the global namespace and potentially causes name collisions  unless measures are taken to prevent this    Note  if you will  that the first two pros and the first two cons I listed are the exact same thing  just with different wording   This is because the features of a global variable can indeed be useful  but the very features that make them useful are the source of all their problems   A few potential solutions to some of the problems    Consider whether they re actually the best or most efficient solution for the problem   If there are any better solutions  use that instead  Put them in a namespace  C    or singleton struct  C  C    with a unique name  a good example would be Globals or GlobalVars   or use a standardised naming convention for global variables  such as global  name  or g module varNameStyle  as mentioned by underscore d in the comments     This will both document their use  you can find code that uses global variables by searching for the namespace struct name   and minimise the impact on the global namespace  For any function that accesses global variables  explicitly document which variables it reads and which it writes   This will make troubleshooting easier  Put them in their own source file and declare them extern in the associated header  so their use can be limited to compilation units that need to access them   If your code relies on a lot of global variables  but each compilation unit only needs access to a handful of them  you could consider sorting them into multiple source files  so it s easier to limit each file s access to global variables  Set up a mechanism to lock and unlock them  and or design your code so that as few functions as possible need to actually modify global variables   Reading them is a lot safer than writing them  although thread races may still cause problems in multithreaded programs  Basically  minimise access to them  and maximise name uniqueness   You want to avoid name collisions and have as few functions as possible that can potentially modify any given variable    Whether they re good or bad depends on how you use them   The majority tend to use them badly  hence the general wariness towards them   If used properly  they can be a major boon  if used poorly  however  they can and will come back to bite you when and how you least expect it   A good way to look at it is that they themselves aren t bad  but they enable bad design  and can multiply the effects of bad design exponentially     Even if you don t intend to use them  it is better to know how to use them safely and choose not to  than not to use them because you don t know how to use them safely   If you ever find yourself in a situation where you need to maintain pre-existing code that relies on global variables  you may be in for difficulty if you don t know how to use them properly

User · Answer

Global variables are fine in small programs  but horrible if used the same way in large ones   This means that you can easily get in the habit of using them while learning   This is what your professor is trying to protect you from   When you are more experienced it will be easier to learn when they are okay

User · Answer

The problem with global variables is that since every function has access to these  it becomes increasingly hard to figure out which functions actually read and write these variables    To understand how the application works  you pretty much have to take into account every function which modifies the global state  That can be done  but as the application grows it will get harder to the point of being virtually impossible  or at least a complete waste of time     If you don t rely on global variables  you can pass state around between different functions as needed  That way you stand a much better chance of understanding what each function does  as you don t need to take the global state into account

User · Answer

The problem with global variables is that since every function has access to these  it becomes increasingly hard to figure out which functions actually read and write these variables    To understand how the application works  you pretty much have to take into account every function which modifies the global state  That can be done  but as the application grows it will get harder to the point of being virtually impossible  or at least a complete waste of time     If you don t rely on global variables  you can pass state around between different functions as needed  That way you stand a much better chance of understanding what each function does  as you don t need to take the global state into account

User · Answer

Use of Global variables actually depends on the requirements  Its advantage is that it reduces the overhead of passing the values repeatedly   But your professor is right because it raises security issues so use of global variables should be avoided as much as possible  Global variables also create problems which are sometimes  difficult to debug    For example -   Situations when the variables values is getting modified on runtime  At that moment its difficult to identify which part of code is modifying it and on what conditions

User · Answer

My professor used to say something like   using global variables are okay if you use them correctly   I don t think I ever got good at using them correctly  so I rarely used them at all

User · Answer

Yes  because if you let incompetent programmers use them  read 90  especially scientists  you end up with 600  global variable spread over 20  files and a project of 12 000 lines where 80  of the functions take void  return void  and operate entirely on global state    It quickly becomes impossible to understand what is going on at any one point unless you know the entire project

User · Answer

As someone said  I m paraphrasing  in another thread  Rules like this should not be broken  until you fully understand the consequences of doing so     There are times when global variables are necessary  or at least very helpful  Working with system defined call-backs for example   On the other hand  they re also very dangerous for all of the reasons you ve been told    There are many aspects of programming that should probably be left to the experts  Sometimes you NEED a very sharp knife  But you don t get to use one until you re ready

User · Answer

Absolutely not  Misusing them though    that is bad   Mindlessly removing them for the sake of  is just that    mindless  Unless you know the advanatages and disadvantages  it is best to steer clear and do as you have been taught learned  but there is nothing implicitly wrong with global variables  When you understand the pros and cons better make your own decision

User · Answer

In web applications within an enterprize can be used for holding session window thread user specific data on the server for reasons of optimization and to preserve against loss of work where connection are unstable  As mentioned  race conditions need to be handled  We use a single instance of a class for this information and it is carefully managed

User · Answer

I would like to argue against the point being made throughout this thread that it makes multi-threading harder or impossible per se  Global variables are shared state  but the alternatives to globals  e  g  passing pointers around  might also share state  The problem with multi-threading is how to properly use shared state  not whether that state happens to be shared through a global variable or something else   Most of the time when you do multi-threading you need to share something  In a producer-consumer pattern for example  you might share some thread-safe queue that contains the work units  And you are allowed to share it because that data structure is thread-safe  Whether that queue is global or not is completely irrelevant when it comes to thread-safety   The implied hope expressed throughout this thread that transforming a program from single-threaded to multi-threaded will be easier when not using globals is naive  Yes  globals make it easier to shoot yourself in the foot  but there s a lot of ways to shoot yourself   I m not advocating globals  as the other points still stand  my point is merely that the number of threads in a program has nothing to do with variable scope

User · Answer

Yes  because if you let incompetent programmers use them  read 90  especially scientists  you end up with 600  global variable spread over 20  files and a project of 12 000 lines where 80  of the functions take void  return void  and operate entirely on global state    It quickly becomes impossible to understand what is going on at any one point unless you know the entire project

User · Answer

Absolutely not  Misusing them though    that is bad   Mindlessly removing them for the sake of  is just that    mindless  Unless you know the advanatages and disadvantages  it is best to steer clear and do as you have been taught learned  but there is nothing implicitly wrong with global variables  When you understand the pros and cons better make your own decision

User · Answer

I d answer this question with another question   Do you use singeltons  Are singeltons bad     Because  almost all  singelton usage is a glorified global variable

User · Answer

The problem with global variables is that since every function has access to these  it becomes increasingly hard to figure out which functions actually read and write these variables    To understand how the application works  you pretty much have to take into account every function which modifies the global state  That can be done  but as the application grows it will get harder to the point of being virtually impossible  or at least a complete waste of time     If you don t rely on global variables  you can pass state around between different functions as needed  That way you stand a much better chance of understanding what each function does  as you don t need to take the global state into account

User · Answer

Using global variables is kind of like sweeping dirt under a rug  It s a quick fix  and a lot easier in the short term than getting a dust-pan or vacuum to clean it up  However  if you ever end up moving the rug later  you re gonna have a big surprise mess underneath

User · Answer

Yes  but you don t incur the cost of global variables until you stop working in the code that uses global variables and start writing something else that uses the code that uses global variables  But the cost is still there   In other words  it s a long term indirect cost and as such most people think it s not bad

User · Answer

Global variables are bad  if they allow you to manipulate aspects of a program that should be only modified locally  In OOP globals often conflict with the encapsulation-idea

User · Answer

The important thing is to remember the overall goal  clarity  The  no global variables  rule is there because most of the time  global variables make the meaning of code less clear   However  like many rules  people remember the rule  and not what the rule was intended to do    I ve seen programs that seem to double the size of the code by passing an enormous number of parameters around simply to avoid the evil of global variables   In the end  using globals would have made the program clearer to those reading it   By mindlessly adhering to the word of the rule  the original programmer had failed the intent of the rule   So  yes  globals are often bad   But if you feel that in the end  the intent of the programmer is made clearer by the use of global variables  then go ahead   However  remember the drop in clarity that automatically ensues when you force someone to access a second piece of code  the globals  to understand how the first piece works

User · Answer

In the end of the day  your program or app can still work but its a matter of being tidy and having a complete understanding of whats going on  If you share a variable value among all functions  it may become difficult to trace what function is changing the value if the function does so  and makes debugging a million times harder

User · Answer

If it s possible your code will end up under intensive review during a Supreme Court trial  then you want to make sure to avoid global variables   See this article   Buggy breathalyzer code reflects importance of source review     There were some problems with the   style of the code that were identified   by both studies  One of the stylistic   issues that concerned the reviewers   was the extensive use of unprotected   global variables  This is considered   poor form because it increases the   risk that the program state will   become inconsistent or that values   will be inadvertently modified or   overwritten  The researchers also   expressed some concern about the fact   that decimal precision is not   maintained consistently throughout the   code    Man  I bet those developers are wishing they hadn t used global variables

User · Answer

Sooner or later you will need to change how that variable is set or what happens when it is accessed  or you just need to hunt down where it is changed   It is practically always better to not have global variables  Just write the dam get and set methods  and be gland you when you need them a day  week or month later

User · Answer

Global variables are bad  if they allow you to manipulate aspects of a program that should be only modified locally  In OOP globals often conflict with the encapsulation-idea

User · Answer

Global variables should only be used when you have no alternative  And yes  that includes Singletons  90  of the time  global variables are introduced to save the cost of passing around a parameter  And then multithreading unit testing maintenance coding happens  and you have a problem   So yes  in 90  of the situations global variables are bad  The exceptions are not likely to be seen by you in your college years  One exception I can think off the top of my head is dealing with inherently global objects such as interrupt tables  Things like DB connection seem to be global  but ain t

User · Answer

As someone said  I m paraphrasing  in another thread  Rules like this should not be broken  until you fully understand the consequences of doing so     There are times when global variables are necessary  or at least very helpful  Working with system defined call-backs for example   On the other hand  they re also very dangerous for all of the reasons you ve been told    There are many aspects of programming that should probably be left to the experts  Sometimes you NEED a very sharp knife  But you don t get to use one until you re ready

User · Answer

Sooner or later you will need to change how that variable is set or what happens when it is accessed  or you just need to hunt down where it is changed   It is practically always better to not have global variables  Just write the dam get and set methods  and be gland you when you need them a day  week or month later

User · Answer

security is less means any one can manipulate the variables if they are declared global   for this one to explain take this example if you have balance as a global variable in your bank program the user function can manipulate this as well as bank officer can also manipulate this so there is a problem  only user should be given the read only and withdraw function but the clerk of the bank can add the amount when the user personally gives the cash in the desk this is the way it works

User · Answer

Using global variables is kind of like sweeping dirt under a rug  It s a quick fix  and a lot easier in the short term than getting a dust-pan or vacuum to clean it up  However  if you ever end up moving the rug later  you re gonna have a big surprise mess underneath

User · Answer

Yes  but you don t incur the cost of global variables until you stop working in the code that uses global variables and start writing something else that uses the code that uses global variables  But the cost is still there   In other words  it s a long term indirect cost and as such most people think it s not bad

User · Answer

Using global variables is kind of like sweeping dirt under a rug  It s a quick fix  and a lot easier in the short term than getting a dust-pan or vacuum to clean it up  However  if you ever end up moving the rug later  you re gonna have a big surprise mess underneath

User · Answer

Global variables are fine in small programs  but horrible if used the same way in large ones   This means that you can easily get in the habit of using them while learning   This is what your professor is trying to protect you from   When you are more experienced it will be easier to learn when they are okay

User · Answer

The problem that global variables create for the programmer is that it expands the inter-component coupling surface between the various components that are using the global variables   What this means is that as the number of components using a global variable increases  the complexity of the interactions can also increase   This increased coupling usually makes defects easier to inject into the system when making changes and also makes defects harder to diagnose and correct   This increase coupling can also reduce the number of available options when making changes and it can increase the effort required for changes as often one must trace through the various modules that are also using the global variable in order to determine the consequences of changes   The purpose of encapsulation  which is basically the opposite of using global variables  is to decrease coupling in order to make understanding and changing the source easier and safer and more easily tested   It is much easier to use unit testing when global variables are not used    For example if you have a simple global integer variable that is being used as an enumerated indicator that various components use as a state machine and you then make a change by adding a new state for a new component  you must then trace through all the other components to ensure that the change will not affect them   An example of a possible problem would be if a switch statement to test the value of the enumeration global variable with case statements for each of the current values is being used in various places and it so happens that some of the switch statements do not have a default case to handle an unexpected value for the global all of a sudden you have undefined behavior so far as the application is concerned   On the other hand the use of a shared data area might be used to contain a set of global parameters which are referenced throughout the application   This approach is often used with embedded applications with small memory footprints   When using global variables in these sort of applications typically the responsibility for writing to the data area is allocated to a single component and all other components see the area as const and read from it  never writing to it   Taking this approach limits the problems that can develop   A few problems from global variables which need to be worked around  When the source for a global variable such as a struct is modified  everything using it must be recompiled so that everything using the variable knows its true size and memory template   If more than one component can modify the global variable you can run into problems with inconsistent data being in the global variable   With a multi-threading application  you will probably need to add some kind of locking or critical region to provide a way so that only one thread at a time can modify the global variable and when a thread is modifying the variable  all changes are complete and committed before other threads can query the variable or modify it   Debugging a multi-threaded application that uses a global variable can be more difficult   You can run into race conditions that can create defects that are difficult to replicate   With several components communicating through a global variable  especially in a multi-threaded application  being able to know what component is changing the variable when and how it is changing the variable can be very difficult to understand   Name clash can be a problem with using of global variables   A local variable that has the same name as a global variable can hide the global variable   You also run into the naming convention issue when using the C programming language   A work around is to divide the system up into sub-systems with the global variables for a particular sub-system all beginning with the same first three letters  see this on resolving name space collisions in objective C    C   provides namespaces and with C you can work around this by creating a globally visible struct whose members are various data items and pointers to data and functions which are provided in a file as static hence with file visibility only so that they can only be referenced through the globally visible struct   In some cases the original application intent is changed so that global variables that provided the state for a single thread is modified to allow several duplicate threads to run   An example would be a simple application designed for a single user using global variables for state and then a request comes down from management to add a REST interface to allow remote applications to act as virtual users   So now you run into having to duplicate the global variables and their state information so that the single user as well as each of the virtual users from remote applications have their own  unique set of global variables   Using C   namespace and the struct Technique for C  For the C   programming language the namespace directive is a huge help in reducing the chances of a name clash  namespace along with class and the various access keywords  private  protected  and public  provide most of the tools you need to encapsulate variables  However the C programming language doesn t provide this directive  This stackoverflow posting  Namespaces in C   provides some techniques for C   A useful technique is to have a single memory resident data area that is defined as a struct which has global visibility and within this struct are pointers to the various global variables and functions that are being exposed  The actual definitions of the global variables are given file scope using the static keyword  If you then use the const keyword to indicate which are read only  the compiler can help you to enforce read only access   Using the struct technique can also encapsulate the global so that it becomes a kind of package or component that happens to be a global  By having a component of this kind it becomes easier to manage changes that affect the global and the functionality using the global   However while namespace or the struct technique can help manage name clashes  the underlying problems of inter-component coupling which the use of globals introduces especially in a modern multi-threaded application  still exist

User · Answer

Global variables are as bad as you make them  no less   If you are creating a fully encapsulated program  you can use globals   It s a  sin  to use globals  but programming sins are laregly philosophical   If you check out L in oleum  you will see a language whose variables are solely global   It s unscalable because libraries all have no choice but to use globals   That said  if you have choices  and can ignore programmer philosophy  globals aren t all that bad   Neither are Gotos  if you use them right   The big  bad  problem is that  if you use them wrong  people scream  the mars lander crashes  and the world blows up    or something like that

User · Answer

Global variables should only be used when you have no alternative  And yes  that includes Singletons  90  of the time  global variables are introduced to save the cost of passing around a parameter  And then multithreading unit testing maintenance coding happens  and you have a problem   So yes  in 90  of the situations global variables are bad  The exceptions are not likely to be seen by you in your college years  One exception I can think off the top of my head is dealing with inherently global objects such as interrupt tables  Things like DB connection seem to be global  but ain t

User · Answer

The issue is less that they re bad  and more that they re dangerous   They have their own set of pros and cons  and there are situations where they re either the most efficient or only way to achieve a particular task   However  they re very easy to misuse  even if you take steps to always use them properly   A few pros    Can be accessed from any function  Can be accessed from multiple threads  Will never go out of scope until the program ends    A few cons    Can be accessed from any function  without needing to be explicitly dragged in as a parameter and or documented  Not thread-safe  Pollutes the global namespace and potentially causes name collisions  unless measures are taken to prevent this    Note  if you will  that the first two pros and the first two cons I listed are the exact same thing  just with different wording   This is because the features of a global variable can indeed be useful  but the very features that make them useful are the source of all their problems   A few potential solutions to some of the problems    Consider whether they re actually the best or most efficient solution for the problem   If there are any better solutions  use that instead  Put them in a namespace  C    or singleton struct  C  C    with a unique name  a good example would be Globals or GlobalVars   or use a standardised naming convention for global variables  such as global  name  or g module varNameStyle  as mentioned by underscore d in the comments     This will both document their use  you can find code that uses global variables by searching for the namespace struct name   and minimise the impact on the global namespace  For any function that accesses global variables  explicitly document which variables it reads and which it writes   This will make troubleshooting easier  Put them in their own source file and declare them extern in the associated header  so their use can be limited to compilation units that need to access them   If your code relies on a lot of global variables  but each compilation unit only needs access to a handful of them  you could consider sorting them into multiple source files  so it s easier to limit each file s access to global variables  Set up a mechanism to lock and unlock them  and or design your code so that as few functions as possible need to actually modify global variables   Reading them is a lot safer than writing them  although thread races may still cause problems in multithreaded programs  Basically  minimise access to them  and maximise name uniqueness   You want to avoid name collisions and have as few functions as possible that can potentially modify any given variable    Whether they re good or bad depends on how you use them   The majority tend to use them badly  hence the general wariness towards them   If used properly  they can be a major boon  if used poorly  however  they can and will come back to bite you when and how you least expect it   A good way to look at it is that they themselves aren t bad  but they enable bad design  and can multiply the effects of bad design exponentially     Even if you don t intend to use them  it is better to know how to use them safely and choose not to  than not to use them because you don t know how to use them safely   If you ever find yourself in a situation where you need to maintain pre-existing code that relies on global variables  you may be in for difficulty if you don t know how to use them properly

User · Answer

If it s possible your code will end up under intensive review during a Supreme Court trial  then you want to make sure to avoid global variables   See this article   Buggy breathalyzer code reflects importance of source review     There were some problems with the   style of the code that were identified   by both studies  One of the stylistic   issues that concerned the reviewers   was the extensive use of unprotected   global variables  This is considered   poor form because it increases the   risk that the program state will   become inconsistent or that values   will be inadvertently modified or   overwritten  The researchers also   expressed some concern about the fact   that decimal precision is not   maintained consistently throughout the   code    Man  I bet those developers are wishing they hadn t used global variables

User · Answer

Global variables are bad  if they allow you to manipulate aspects of a program that should be only modified locally  In OOP globals often conflict with the encapsulation-idea

User · Answer

In the end of the day  your program or app can still work but its a matter of being tidy and having a complete understanding of whats going on  If you share a variable value among all functions  it may become difficult to trace what function is changing the value if the function does so  and makes debugging a million times harder

User · Answer

The problem that global variables create for the programmer is that it expands the inter-component coupling surface between the various components that are using the global variables   What this means is that as the number of components using a global variable increases  the complexity of the interactions can also increase   This increased coupling usually makes defects easier to inject into the system when making changes and also makes defects harder to diagnose and correct   This increase coupling can also reduce the number of available options when making changes and it can increase the effort required for changes as often one must trace through the various modules that are also using the global variable in order to determine the consequences of changes   The purpose of encapsulation  which is basically the opposite of using global variables  is to decrease coupling in order to make understanding and changing the source easier and safer and more easily tested   It is much easier to use unit testing when global variables are not used    For example if you have a simple global integer variable that is being used as an enumerated indicator that various components use as a state machine and you then make a change by adding a new state for a new component  you must then trace through all the other components to ensure that the change will not affect them   An example of a possible problem would be if a switch statement to test the value of the enumeration global variable with case statements for each of the current values is being used in various places and it so happens that some of the switch statements do not have a default case to handle an unexpected value for the global all of a sudden you have undefined behavior so far as the application is concerned   On the other hand the use of a shared data area might be used to contain a set of global parameters which are referenced throughout the application   This approach is often used with embedded applications with small memory footprints   When using global variables in these sort of applications typically the responsibility for writing to the data area is allocated to a single component and all other components see the area as const and read from it  never writing to it   Taking this approach limits the problems that can develop   A few problems from global variables which need to be worked around  When the source for a global variable such as a struct is modified  everything using it must be recompiled so that everything using the variable knows its true size and memory template   If more than one component can modify the global variable you can run into problems with inconsistent data being in the global variable   With a multi-threading application  you will probably need to add some kind of locking or critical region to provide a way so that only one thread at a time can modify the global variable and when a thread is modifying the variable  all changes are complete and committed before other threads can query the variable or modify it   Debugging a multi-threaded application that uses a global variable can be more difficult   You can run into race conditions that can create defects that are difficult to replicate   With several components communicating through a global variable  especially in a multi-threaded application  being able to know what component is changing the variable when and how it is changing the variable can be very difficult to understand   Name clash can be a problem with using of global variables   A local variable that has the same name as a global variable can hide the global variable   You also run into the naming convention issue when using the C programming language   A work around is to divide the system up into sub-systems with the global variables for a particular sub-system all beginning with the same first three letters  see this on resolving name space collisions in objective C    C   provides namespaces and with C you can work around this by creating a globally visible struct whose members are various data items and pointers to data and functions which are provided in a file as static hence with file visibility only so that they can only be referenced through the globally visible struct   In some cases the original application intent is changed so that global variables that provided the state for a single thread is modified to allow several duplicate threads to run   An example would be a simple application designed for a single user using global variables for state and then a request comes down from management to add a REST interface to allow remote applications to act as virtual users   So now you run into having to duplicate the global variables and their state information so that the single user as well as each of the virtual users from remote applications have their own  unique set of global variables   Using C   namespace and the struct Technique for C  For the C   programming language the namespace directive is a huge help in reducing the chances of a name clash  namespace along with class and the various access keywords  private  protected  and public  provide most of the tools you need to encapsulate variables  However the C programming language doesn t provide this directive  This stackoverflow posting  Namespaces in C   provides some techniques for C   A useful technique is to have a single memory resident data area that is defined as a struct which has global visibility and within this struct are pointers to the various global variables and functions that are being exposed  The actual definitions of the global variables are given file scope using the static keyword  If you then use the const keyword to indicate which are read only  the compiler can help you to enforce read only access   Using the struct technique can also encapsulate the global so that it becomes a kind of package or component that happens to be a global  By having a component of this kind it becomes easier to manage changes that affect the global and the functionality using the global   However while namespace or the struct technique can help manage name clashes  the underlying problems of inter-component coupling which the use of globals introduces especially in a modern multi-threaded application  still exist

User · Answer

As someone said  I m paraphrasing  in another thread  Rules like this should not be broken  until you fully understand the consequences of doing so     There are times when global variables are necessary  or at least very helpful  Working with system defined call-backs for example   On the other hand  they re also very dangerous for all of the reasons you ve been told    There are many aspects of programming that should probably be left to the experts  Sometimes you NEED a very sharp knife  But you don t get to use one until you re ready

User · Answer

Global variables are generally bad  especially if other people are working on the same code and don t want to spend 20mins searching for all the places the variable is referenced  And adding threads that modify the variables brings in a whole new level of headaches   Global constants in an anonymous namespace used in a single translation unit are fine and ubiquitous in professional apps and libraries   But if the data is mutable  and or it has to be shared between multiple TUs  you may want to encapsulate it--if not for design s sake  then for the sake of anybody debugging or working with your code

User · Answer

Global variables are generally bad  especially if other people are working on the same code and don t want to spend 20mins searching for all the places the variable is referenced  And adding threads that modify the variables brings in a whole new level of headaches   Global constants in an anonymous namespace used in a single translation unit are fine and ubiquitous in professional apps and libraries   But if the data is mutable  and or it has to be shared between multiple TUs  you may want to encapsulate it--if not for design s sake  then for the sake of anybody debugging or working with your code

User · Answer

Global variables are fine in small programs  but horrible if used the same way in large ones   This means that you can easily get in the habit of using them while learning   This is what your professor is trying to protect you from   When you are more experienced it will be easier to learn when they are okay

User · Answer

Global variables should only be used when you have no alternative  And yes  that includes Singletons  90  of the time  global variables are introduced to save the cost of passing around a parameter  And then multithreading unit testing maintenance coding happens  and you have a problem   So yes  in 90  of the situations global variables are bad  The exceptions are not likely to be seen by you in your college years  One exception I can think off the top of my head is dealing with inherently global objects such as interrupt tables  Things like DB connection seem to be global  but ain t

User · Answer

Global variables are as bad as you make them  no less   If you are creating a fully encapsulated program  you can use globals   It s a  sin  to use globals  but programming sins are laregly philosophical   If you check out L in oleum  you will see a language whose variables are solely global   It s unscalable because libraries all have no choice but to use globals   That said  if you have choices  and can ignore programmer philosophy  globals aren t all that bad   Neither are Gotos  if you use them right   The big  bad  problem is that  if you use them wrong  people scream  the mars lander crashes  and the world blows up    or something like that

User · Answer

Global variables are as bad as you make them  no less   If you are creating a fully encapsulated program  you can use globals   It s a  sin  to use globals  but programming sins are laregly philosophical   If you check out L in oleum  you will see a language whose variables are solely global   It s unscalable because libraries all have no choice but to use globals   That said  if you have choices  and can ignore programmer philosophy  globals aren t all that bad   Neither are Gotos  if you use them right   The big  bad  problem is that  if you use them wrong  people scream  the mars lander crashes  and the world blows up    or something like that

User · Answer

I d answer this question with another question   Do you use singeltons  Are singeltons bad     Because  almost all  singelton usage is a glorified global variable

User · Answer

Sooner or later you will need to change how that variable is set or what happens when it is accessed  or you just need to hunt down where it is changed   It is practically always better to not have global variables  Just write the dam get and set methods  and be gland you when you need them a day  week or month later

User · Answer

I d answer this question with another question   Do you use singeltons  Are singeltons bad     Because  almost all  singelton usage is a glorified global variable

User · Answer

I would like to argue against the point being made throughout this thread that it makes multi-threading harder or impossible per se  Global variables are shared state  but the alternatives to globals  e  g  passing pointers around  might also share state  The problem with multi-threading is how to properly use shared state  not whether that state happens to be shared through a global variable or something else   Most of the time when you do multi-threading you need to share something  In a producer-consumer pattern for example  you might share some thread-safe queue that contains the work units  And you are allowed to share it because that data structure is thread-safe  Whether that queue is global or not is completely irrelevant when it comes to thread-safety   The implied hope expressed throughout this thread that transforming a program from single-threaded to multi-threaded will be easier when not using globals is naive  Yes  globals make it easier to shoot yourself in the foot  but there s a lot of ways to shoot yourself   I m not advocating globals  as the other points still stand  my point is merely that the number of threads in a program has nothing to do with variable scope

User · Answer

I usually use globals for values that are rarely changed like singletons or function pointers to functions in dynamically loaded library  Using mutable globals in multithreaded applications tends to lead to hard to track bug so I try to avoid this as a general rule   Using a global instead of passing an argument is often faster but if you re writing a multithreaded application  which you often do nowadays  it generally doesn t work very well  you can use thread-statics but then the performance gain is questionable

[c++] Are global variables bad?

Examples related to c++

Examples related to c

Examples related to global-variables