글로벌 변수가 나쁜가요?

글로벌 변수가 나쁜가요?

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

5년 전에 문을 닫았어요

이 질문을 개선하다

C/C++에서는 글로벌 변수가 교수님 생각만큼 나쁜가요?

글로벌 변수의 문제는 모든 함수가 이러한 변수에 액세스할 수 있기 때문에 실제로 어떤 함수가 이러한 변수를 읽고 쓰는지 파악하는 것이 점점 더 어려워진다는 것입니다.

응용 프로그램의 동작을 이해하려면 글로벌 상태를 변경하는 모든 기능을 고려해야 합니다.그렇게 할 수는 있지만, 애플리케이션이 커짐에 따라 사실상 불가능할 정도로(또는 적어도 시간 낭비) 어려워질 것입니다.

글로벌 변수에 의존하지 않으면 필요에 따라 다른 함수 간에 상태를 전달할 수 있습니다.그러면 글로벌 상태를 고려할 필요가 없기 때문에 각 기능의 기능을 이해할 수 있는 가능성이 높아집니다.

중요한 것은 전체적인 목표를 기억하는 것입니다: 명확성

"글로벌 변수 없음" 규칙은 대부분의 경우 글로벌 변수가 코드의 의미를 덜 명확하게 하기 때문에 적용됩니다.

하지만, 많은 규칙들처럼, 사람들은 규칙이 무엇을 의도했는지가 아니라 규칙을 기억한다.

단순히 글로벌 변수의 악화를 피하기 위해 엄청난 수의 매개 변수를 전달함으로써 코드 크기를 두 배로 늘리는 프로그램을 본 적이 있습니다.결국, 지구본을 사용한다면 프로그램을 읽는 사람들에게 더 명확하게 만들 수 있었을 것이다.무심코 규칙을 지켰기 때문에 원래 프로그래머는 규칙의 취지를 지키지 못했다.

그래서, 그래, 글로벌은 종종 나쁘다.하지만 결국 프로그래머의 의도가 글로벌 변수를 사용함으로써 명확해진다고 느낀다면 그렇게 하세요.단, 첫 번째 조각이 어떻게 동작하는지 이해하기 위해 두 번째 코드 조각(글로벌)에 강제로 액세스하면 자동으로 나타나는 선명도 저하를 기억하십시오.

프로그래머에게 글로벌 변수가 가져오는 문제는 글로벌 변수를 사용하는 다양한 컴포넌트 간에 컴포넌트 간 결합면이 확장된다는 것입니다.즉, 글로벌 변수를 사용하는 성분의 수가 증가함에 따라 교호작용의 복잡성도 증가할 수 있습니다.이렇게 커플링이 증가하면 일반적으로 변경 시 시스템에 결함을 주입하기가 쉬워지고 결함을 진단 및 수정하기가 어려워집니다.이 증가 결합은 또한 변경 시 사용 가능한 옵션의 수를 줄일 수 있으며 변경의 결과를 판단하기 위해 글로벌 변수를 사용하는 다양한 모듈을 추적해야 하는 경우가 많기 때문에 변경에 필요한 노력을 증가시킬 수 있습니다.

캡슐화의 목적은 기본적으로 글로벌 변수를 사용하는 것과는 정반대로, 소스의 이해와 변경을 보다 쉽고 안전하게, 보다 쉽게 테스트하기 위해 커플링을 줄이는 것입니다.글로벌 변수를 사용하지 않을 경우 단위 테스트를 사용하는 것이 훨씬 쉽습니다.

예를 들어, 다양한 컴포넌트가 상태 머신으로 사용하는 열거형 인디케이터로 사용되는 단순한 글로벌 정수 변수가 있는 경우 새 컴포넌트의 새 상태를 추가하여 변경을 하는 경우 변경사항이 영향을 미치지 않도록 다른 모든 컴포넌트를 추적해야 합니다.생각할 수 있는 문제의 예로는 다음과 같은 것이 있습니다.switch를 사용하여 열거 글로벌 변수 값을 테스트하는 스테이트먼트case각 현재 값에 대한 문장이 다양한 장소에서 사용되고 있습니다. 그래서 일부의 경우switch스테이트먼트에는,default어플리케이션에 관한 동작은 정의되어 있지 않습니다.

한편, 공유 데이터 영역의 사용은 애플리케이션 전체에서 참조되는 글로벌 파라미터 세트를 포함하기 위해 사용될 수 있습니다.이 접근방식은 메모리 설치 공간이 작은 임베디드 애플리케이션에 자주 사용됩니다.

이러한 종류의 애플리케이션에서 글로벌 변수를 사용하는 경우 일반적으로 데이터 영역에 쓰는 책임은 단일 구성 요소에 할당되며 다른 모든 구성 요소는 영역을 다음과 같이 간주합니다.const읽으면서도 절대 쓰지 않는 거죠.이 방법을 사용하면 발생할 수 있는 문제를 제한할 수 있습니다.

대처해야 할 글로벌 변수의 몇 가지 문제

구조체 등의 글로벌 변수의 소스가 변경되면 변수를 사용하는 모든 것이 실제 크기와 메모리 템플릿을 알 수 있도록 해당 변수를 사용하는 모든 것을 다시 컴파일해야 합니다.

둘 이상의 구성 요소가 글로벌 변수를 수정할 수 있는 경우 글로벌 변수에 일관성 없는 데이터가 있는 문제가 발생할 수 있습니다.멀티스레딩 어플리케이션에서는 한 번에 하나의 스레드만 글로벌 변수를 변경할 수 있도록 하기 위해 어떤 종류의 잠금 또는 크리티컬 영역을 추가해야 합니다.또한 스레드가 변수를 수정하고 있을 때는 모든 변경이 완료되어 다른 스레드가 변수를 쿼리하거나 수정할 수 없게 됩니다.

글로벌 변수를 사용하는 멀티 스레드응용 프로그램의 디버깅은 더욱 어려워질 수 있습니다.반복하기 어려운 결점을 만들 수 있는 경주 조건이 발생할 수 있습니다.여러 컴포넌트가 글로벌 변수를 통해 통신하기 때문에, 특히 멀티 스레드 애플리케이션에서는 변수가 언제 어떻게 변경되는지 파악하는 것이 매우 어려울 수 있습니다.

글로벌 변수 사용 시 이름 충돌 문제가 발생할 수 있습니다.글로벌 변수와 이름이 같은 로컬 변수는 글로벌 변수를 숨길 수 있습니다.C 프로그래밍 언어를 사용할 때도 명명 규칙 문제가 발생합니다.회피책은 시스템을 특정 서브시스템의 글로벌 변수를 가진 서브시스템으로 분할하는 것입니다.모두 같은 첫 번째 3글자로 시작합니다(객관 C의 네임스페이스 충돌 해결 방법은 이 항목을 참조하십시오).C++는 네임스페이스를 제공하며, C를 사용하면 글로벌하게 볼 수 있는 구조를 만들 수 있습니다.이 구조체의 구성원은 다양한 데이터 항목과 정적 데이터 및 함수에 대한 포인터이며, 파일 가시성은 글로벌하게 볼 수 있는 구조체를 통해서만 참조할 수 있도록 합니다.

경우에 따라서는 단일 스레드의 상태를 제공한 글로벌 변수가 여러 개의 중복 스레드를 실행할 수 있도록 변경되도록 원래 응용 프로그램의 의도가 변경됩니다.예를 들어, 단일 사용자용으로 설계된 단순한 애플리케이션으로, 스테이트의 글로벌 변수를 사용하고, 관리측으로부터 REST 인터페이스를 추가해 리모트애플리케이션을 가상 유저로서 동작시킬 필요가 있습니다.따라서 리모트 어플리케이션의 가상 사용자뿐만 아니라 각 사용자가 고유한 글로벌 변수 세트를 가질 수 있도록 글로벌 변수와 해당 상태 정보를 복제해야 합니다.

C++ 사용namespace및 그structC의 기술

C++ 프로그래밍 언어의 경우namespace디렉티브는 이름 충돌 가능성을 줄이는 데 큰 도움이 됩니다. namespace와 함께class다양한 액세스 키워드(private,protected,그리고.public)는 변수를 캡슐화하는 데 필요한 대부분의 도구를 제공합니다.그러나 C 프로그래밍 언어는 이 명령을 제공하지 않습니다.이 스택오버플로우 게시물(C의 네임스페이스)은 C에 대한 몇 가지 기술을 제공합니다.

유용한 기술은 단일 메모리 상주 데이터 영역을 갖는 것입니다.struct글로벌 가시성을 갖추고 있으며, 그 안에struct는 공개되는 다양한 글로벌 변수 및 함수에 대한 포인터입니다.글로벌 변수의 실제 정의는 파일 범위로 지정됩니다.static키워드를 지정합니다.이 경우,const어떤 것이 읽기 전용인지 나타내는 키워드를 지정하면, 컴파일러는 읽기 전용 액세스를 강제할 수 있습니다.

사용방법struct또, 글로벌하게 캡슐화할 수 있기 때문에, 글로벌한 패키지나 컴포넌트의 일종으로 할 수 있습니다.이러한 종류의 컴포넌트가 있으면 글로벌을 사용하여 글로벌 및 기능에 영향을 미치는 변경을 관리하기 쉬워집니다.

단,namespace또는struct기술은 이름 충돌을 관리하는 데 도움을 줄 수 있습니다. 특히 현대의 멀티 멀티 캐리어 애플리케이션에서 글로벌 사용이 도입된 구성요소 간 결합의 근본적인 문제는 여전히 존재합니다.

교수님은 글로벌 변수를 올바르게 사용한다면 괜찮다고 말씀하셨습니다.제대로 된 사용을 할 수 없게 된 것 같아서 거의 사용하지 않았습니다.

문제는 그들이 나쁘다는 것이 아니라 위험하다는 것이다.그들은 그들만의 장단점을 가지고 있고, 그들이 특정한 일을 성취하는 가장 효율적인 혹은 유일한 방법인 상황들이 있다.그러나 항상 올바르게 사용하기 위한 조치를 취해도 오용되기 쉽습니다.

몇 가지 장점:

• 모든 기능에서 액세스할 수 있습니다.
• 여러 스레드에서 액세스할 수 있습니다.
• 프로그램이 종료될 때까지 범위를 벗어나지 않습니다.

몇 가지 단점:

• 매개 변수로 명시적으로 끌어다 놓거나 문서화할 필요 없이 모든 함수에서 액세스할 수 있습니다.
• 스레드 세이프가 아닙니다.
• 이를 방지하기 위한 조치가 취해지지 않는 한 글로벌 네임스페이스를 오염시켜 이름 충돌을 일으킬 수 있습니다.

참고로, 제가 나열한 첫 번째 두 가지 장점과 첫 번째 두 가지 단점은 서로 다른 표현만 있을 뿐 완전히 동일합니다.이는 글로벌 변수의 기능이 실제로 유용할 수 있지만, 이러한 변수를 유용하게 만드는 바로 그 기능이 모든 문제의 근원이기 때문입니다.

몇 가지 문제에 대한 몇 가지 잠재적인 해결 방법:

• 이러한 솔루션이 실제로 문제에 대한 최선의 솔루션인지 아니면 가장 효율적인 솔루션인지를 고려하십시오.더 나은 해결책이 있다면 대신 그것을 사용하세요.
• 네임스페이스 [C++]또는 싱글톤 구조체 [C, C++]에 고유 이름을 지정합니다(좋은 예:Globals또는GlobalVars또는 글로벌 변수(예:global_[name]또는g_module_varNameStyle(댓글에서 언더스코어_d에 기재되어 있습니다).이렇게 하면 둘 다 사용법을 문서화하고(네임스페이스/구조명을 검색하여 글로벌 변수를 사용하는 코드를 찾을 수 있음) 글로벌 네임스페이스에 미치는 영향을 최소화할 수 있습니다.
• 글로벌 변수에 액세스하는 함수의 경우 읽은 변수와 쓴 변수를 명시적으로 기록합니다.이것에 의해, 트러블 슈팅이 용이하게 됩니다.
• 자체 소스 파일에 저장하여 선언합니다.extern관련 헤더에 저장하기 때문에 이러한 사용은 액세스해야 하는 컴파일 유닛으로 제한될 수 있습니다.코드가 많은 글로벌 변수에 의존하고 있지만 각 컴파일 유닛에 필요한 액세스 권한이 몇 개뿐이라면 여러 소스 파일로 정렬하여 각 파일의 액세스를 글로벌 변수에 더 쉽게 제한할 수 있습니다.
• 글로벌 변수를 실제로 수정할 필요가 있는 함수가 가능한 한 적도록 코드를 잠그고 잠금 해제하는 메커니즘을 설정하거나 코드를 설계합니다.스레드 레이스는 멀티 스레드 프로그램에서 여전히 문제를 일으킬 수 있지만, 그것들을 읽는 것이 그것들을 쓰는 것보다 훨씬 더 안전하다.
• 기본적으로, 이러한 사용자들에 대한 액세스를 최소화하고 이름 고유성을 극대화합니다.이름 충돌을 피하고 특정 변수를 수정할 수 있는 함수는 가능한 한 적게 보유해야 합니다.

좋은지 나쁜지는 당신이 어떻게 쓰느냐에 달려 있어요.대부분은 그것들을 나쁘게 사용하는 경향이 있고, 따라서 그들에 대한 전반적인 경계심이 있다.적절하게 사용한다면, 그것들은 큰 이익이 될 수 있다. 하지만, 만약 잘못 사용한다면, 그들은 여러분이 가장 기대하지 않았던 때에, 그리고 어떻게 여러분을 물게 될 것이다.

그 자체는 나쁘지 않지만 나쁜 디자인을 가능하게 하고 나쁜 디자인의 영향을 기하급수적으로 늘릴 수 있습니다.

---

사용할 생각이 없더라도 안전하게 사용하는 방법을 모르기 때문에 사용하지 않는 것보다는 안전하게 사용하는 방법을 알고 사용하지 않는 것이 좋습니다.글로벌 변수에 의존하는 기존 코드를 유지해야 하는 상황에 처하게 되면 적절한 사용법을 모르면 곤란해질 수 있습니다.

네, 하지만 글로벌 변수를 사용하는 코드로 작업을 중단하고 글로벌 변수를 사용하는 코드를 사용하는 다른 코드를 쓰기 시작할 때까지는 글로벌 변수의 비용이 발생하지 않습니다.하지만 그 비용은 그대로다.

즉, 그것은 장기적인 간접비용이기 때문에 대부분의 사람들은 나쁘지 않다고 생각한다.

전역 변수는 대안이 없는 경우에만 사용해야 합니다.네, 싱글톤도 포함되어 있습니다.90%의 경우 파라미터 전달 비용을 절감하기 위해 글로벌 변수가 도입됩니다.그 후 멀티스레딩/유닛 테스트/유지관리 코딩이 발생하여 문제가 발생합니다.

따라서 90%의 상황에서는 글로벌 변수가 좋지 않습니다.대학 시절에는 이런 예외들이 눈에 띄지 않을 것이다.즉석에서 생각할 수 있는 예외 중 하나는 인터럽트 테이블과 같은 본질적으로 글로벌한 오브젝트를 다루는 것입니다.DB Connection과 같은 것은 글로벌한 것처럼 보이지만 그렇지 않습니다.

글로벌 변수는 여러분이 만드는 것만큼 나쁘지는 않습니다.

완전히 캡슐화된 프로그램을 만드는 경우 글로벌을 사용할 수 있습니다.글로벌을 사용하는 것은 죄악이지만, 죄악을 프로그래밍하는 것은 철학적으로 드물다.

L.in.olum을 체크하면 변수가 글로벌한 언어만 표시됩니다.도서관은 모두 지구본을 사용할 수밖에 없기 때문에 그것은 납득할 수 없다.

즉, 선택권이 있고 프로그래머의 철학을 무시할 수 있다면 글로벌은 그리 나쁘지 않다.

Gotos도, 만약 제대로 쓴다면.

가장 큰 '나쁜' 문제는 잘못 사용하면 사람들이 소리를 지르고, 화성 착륙선이 추락하고, 세상이 폭발한다는 것입니다.

설정에 관해서는 global이 적합합니다.구성/변경이 프로젝트 전체에 글로벌하게 영향을 미치기를 원하는 경우.

그래서 우리는 하나의 구성을 변경할 수 있고 변경은 프로젝트 전체로 향합니다. 그러나 나는 당신이 글로벌을 사용하기 위해서는 매우 똑똑해야 할 것입니다.

대법원의 재판 중에 코드가 집중적인 검토를 받게 될 가능성이 있다면 글로벌 변수를 피해야 합니다.

다음 문서를 참조하십시오. 버기 음주 측정기 코드는 소스 검토의 중요성을 반영한다.

두 연구 모두 확인된 코드의 스타일에 몇 가지 문제가 있었다.검토자들이 우려했던 스타일상의 문제 중 하나는 보호되지 않은 글로벌 변수의 광범위한 사용이었다.이는 프로그램 상태가 일관되지 않거나 값이 실수로 변경되거나 덮어쓰게 될 위험을 증가시키기 때문에 잘못된 형식으로 간주됩니다.연구원들은 또한 십진법 정밀도가 코드 전반에 걸쳐 일관되게 유지되지 않는다는 사실에 대해 우려를 표했다.

이런, 개발자들은 분명 글로벌 변수를 사용하지 않았기를 바랄 거예요!

저는 이 스레드 전체에서 멀티 스레드 자체가 더 어렵거나 불가능하다는 점을 논하고 싶습니다.글로벌 변수는 공유 상태이지만 글로벌 대체 변수(예: 포인터 전달)도 공유 상태를 가질 수 있습니다.멀티스레딩의 문제는 공유 상태를 글로벌 변수를 통해 공유하는지 여부가 아니라 공유 상태를 적절하게 사용하는 방법입니다.

대부분의 경우 멀티스레딩을 할 때는 무언가를 공유해야 합니다.예를 들어 생산자-소비자 패턴에서는 작업 단위를 포함하는 스레드 세이프 큐를 공유할 수 있습니다.데이터 구조가 스레드 세이프하기 때문에 공유할 수 있습니다.이 큐가 글로벌한지 아닌지는 스레드의 안전성에 관해서는 전혀 관계가 없습니다.

글로벌을 사용하지 않을 때 프로그램을 싱글 스레드에서 멀티 스레드로 변환하는 것이 더 쉬울 것이라는 것을 이 스레드 전체에 암시하는 희망은 암시되어 있습니다.그래, 지구대회는 자기 발에 총을 쏘는 걸 더 쉽게 만들어 주지만 자기 자신을 쏘는 방법은 많아

저는 글로벌을 옹호하는 것이 아닙니다.다른 점들이 그렇듯이, 제 요점은 프로그램의 스레드 수가 가변 범위와는 무관하다는 것입니다.

네, 무능한 프로그래머(특히 90%의 과학자를 읽음)가 그것들을 사용하게 되면, 20개 이상의 파일에 600개 이상의 글로벌 변수가 분산되고 함수의 80%가 무효화, 무효화, 글로벌 상태에서 완전히 동작하는 12,000줄의 프로젝트가 생기기 때문입니다.

프로젝트 전체를 알지 못하면 어느 시점에서 무슨 일이 일어나고 있는지 이해하는 것은 금방 불가능해집니다.

글로벌 변수를 사용하는 것은 깔개 밑의 먼지를 쓸어내는 것과 같다.이것은 빠른 수정이며, 청소용 먼지받이나 진공청소기를 사용하는 것보다 단기적으로는 훨씬 쉽습니다.하지만 나중에 양탄자를 옮기게 되면, 그 안이 엉망진창이 될 거야.

아니요, 그들은 전혀 나쁘지 않아요.컴파일러가 작성한 (머신) 코드를 보고 판단해야 합니다.로컬을 사용하는 것이 글로벌보다 훨씬 나쁜 경우도 있습니다.또한 로컬 변수에 "static"을 붙이는 것은 기본적으로 로컬 변수를 글로벌하게 만드는 것입니다(그리고 실제 글로벌이 해결할 수 있는 다른 추악한 문제를 발생시킵니다)."지역 지구대회의"는 특히 좋지 않다.

글로벌은 또한 당신이 당신의 기억력을 깨끗하게 관리할 수 있게 해주며, 이것은 현지인들과 함께 하기 훨씬 더 어려운 것이다.오늘날에는 메모리가 상당히 제한된 임베디드 환경에서만 문제가 됩니다.임베디드된 환경이 다른 환경과 동일하다고 가정하고 프로그래밍 규칙이 전체적으로 동일하다고 가정하기 전에 알아야 할 사항입니다.

가르침을 받고 있는 규칙에 의문을 제기하는 것은 좋은 일입니다.대부분의 규칙은 당신이 듣고 있는 이유 때문이 아닙니다.하지만 가장 중요한 교훈은 이것이 영원히 가지고 다니는 규칙이 아니라 이 수업을 통과하고 앞으로 나아가기 위해 지켜야 할 규칙이라는 것입니다.XYZ사의 경우 급여를 계속 받기 위해 최종적으로 지켜야 할 다른 프로그래밍 규칙이 있다는 것을 알게 될 것입니다.두 경우 모두 규칙을 주장할 수 있지만, 학교보다 직장에서 훨씬 더 운이 좋다고 생각합니다.당신은 많은 학생 중 한 명일 뿐이며, 곧 자리가 교체될 것입니다.교수님은 이 제품을 끝까지 봐야 하는 작은 팀의 한 사람일 것입니다.그리고 그 환경에서 개발된 규칙은 팀원뿐만 아니라 제품 및 회사의 이익을 위해서입니다.따라서 모두가 마음에 들면, 혹은 회사를 위해서도 마찬가지입니다.특정한 제품은 당신이 대학에서 배운 어떤 것 또는 일반 프로그래밍에 관한 책을 위반할 수 있는 좋은 공학적인 이유가 있습니다. 그리고 나서 당신의 아이디어를 팀에 팔고 선호되는 방법이 아니라면 유효한 방법으로 적습니다.현실 세계에서는 모든 것이 공정한 게임이다.

만약 당신이 학교에서 가르친 모든 프로그래밍 규칙을 따르거나 책을 읽으면 당신의 프로그래밍 경력은 극도로 제한될 것입니다.당신은 살아남아 보람 있는 경력을 쌓을 수 있지만, 당신이 이용할 수 있는 환경의 폭과 폭은 매우 제한적일 것입니다.규칙이 어떻게, 왜 존재하는지 알고 그것을 옹호할 수 있다면, 그것은 좋은 일이다. 만약 당신이 "선생님이 그렇게 말씀하셨기 때문"이라면, 그것은 좋지 않다.

이러한 토픽은 직장에서 자주 논의되며 컴파일러나 프로세서(및 언어)가 진화함에 따라 앞으로도 계속 논의될 것입니다.이러한 규칙도 자신의 입장을 옹호하지 않고, 나아가고 싶지 않은 다른 의견을 가진 사람에게서 교훈을 얻을 수 있습니다.

그 사이에, 가장 큰 소리를 지르거나 가장 큰 막대기를 든 사람이 말하는 대로 하세요.

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.

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

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.

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.

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.

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

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.

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.

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

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...

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.

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.

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.

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).

ReferenceURL : https://stackoverflow.com/questions/484635/are-global-variables-bad