c++ - valores - ¿Las variables globales son malas?

variables globales en c (28)

En C / C ++, ¿son las variables globales tan malas como mi profesor cree que son?

Absolutamente no. Mal uso de ellos sin embargo ... eso es malo.

Quitarlos sin pensar por el bien de eso es solo eso ... sin sentido. A menos que conozca las ventajas y desventajas, lo mejor es mantenerse claro y hacer lo que le enseñaron / aprender, pero no hay nada implícitamente incorrecto con las variables globales. Cuando comprendas los pros y los contras, toma tu propia decisión.

Al final del día, su programa o aplicación aún puede funcionar, pero es una cuestión de estar ordenado y tener una comprensión completa de lo que está sucediendo. Si comparte un valor variable entre todas las funciones, puede resultar difícil rastrear qué función está cambiando el valor (si la función lo hace) y hace que la depuración sea un millón de veces más difícil.

Como alguien dijo (estoy parafraseando) en otro hilo "Reglas como esta no deberían romperse, hasta que entiendas completamente las consecuencias de hacerlo".

Hay momentos en que las variables globales son necesarias, o al menos muy útiles (por ejemplo, trabajar con devoluciones de llamadas definidas por el sistema). Por otro lado, también son muy peligrosos por todas las razones por las que te han dicho.

Hay muchos aspectos de la programación que probablemente deberían dejarse en manos de los expertos. A veces NECESITAS un cuchillo muy afilado. Pero no puedes usar uno hasta que estés listo ...

Contestaré esta pregunta con otra pregunta: ¿ singeltons / Are singeltons bad?

Porque (casi todo) el uso de singelton es una variable global glorificada.

Creo que su profesor está tratando de detener un mal hábito antes de que comience.

Las variables globales tienen su lugar y, como muchas personas dijeron, saber dónde y cuándo usarlas puede ser complicado. Así que creo que en lugar de entrar en el meollo de la cuestión de por qué, cómo, cuándo y dónde de las variables globales, su profesor decidió simplemente prohibir. Quién sabe, él podría deshacerlos en el futuro.

El problema con las variables globales es que dado que cada función tiene acceso a ellas, se vuelve cada vez más difícil averiguar qué funciones realmente leen y escriben estas variables.

Para comprender cómo funciona la aplicación, es necesario tener en cuenta cada función que modifica el estado global. Se puede hacer, pero a medida que la aplicación crezca, se volverá más difícil hasta el punto de ser prácticamente imposible (o al menos una completa pérdida de tiempo).

Si no confía en las variables globales, puede pasar el estado entre diferentes funciones según sea necesario. De esa manera, tendrá una mejor oportunidad de entender lo que hace cada función, ya que no necesita tener en cuenta el estado global.

El problema es menos que son malos , y más que son peligrosos . Tienen su propio conjunto de ventajas y desventajas, y hay situaciones en las que son la forma más eficiente o la única para lograr una tarea en particular. Sin embargo, son muy fáciles de usar mal, incluso si tomas medidas para usarlos siempre correctamente.

Algunos pros:

Se puede acceder desde cualquier función.
Se puede acceder desde múltiples hilos.
Nunca saldrá de alcance hasta que el programa termine.

Algunos contras:

Se puede acceder desde cualquier función, sin necesidad de ser arrastrado explícitamente como parámetro y / o documentado.
No hilo seguro.
Contamina el espacio de nombres global y potencialmente causa colisiones de nombres, a menos que se tomen medidas para evitarlo.

Tenga en cuenta, si lo desea, que los dos primeros pros y los dos primeros contras que enumeré son exactamente lo mismo, solo que con una redacción diferente. Esto se debe a que las características de una variable global pueden ser útiles, pero las mismas características que las hacen útiles son la fuente de todos sus problemas.

Algunas posibles soluciones a algunos de los problemas:

Considere si son realmente la mejor solución o la más eficiente para el problema. Si hay soluciones mejores, usa eso en su lugar.
Póngalos en un espacio de nombres [C ++] o estructura singleton [C, C ++] con un nombre único (un buen ejemplo sería Globals o GlobalVars ), o use una convención de nomenclatura estandarizada para variables globales (como global_[name] o g_module_varNameStyle ( como se menciona por underscore_d en los comentarios)). Esto documentará su uso (puede encontrar el código que usa variables globales buscando el espacio de nombres / nombre de la estructura) y minimizar el impacto en el espacio de nombres global.
Para cualquier función que acceda a variables globales, documente explícitamente qué variables lee y escribe. Esto facilitará la resolución de problemas.
Póngalos en su propio archivo fuente y declare que son extern en el encabezado asociado, por lo que su uso puede limitarse a las unidades de compilación que necesitan acceder a ellos. Si su código se basa en una gran cantidad de variables globales, pero cada unidad de compilación solo necesita acceso a un puñado de ellas, podría considerar clasificarlas en múltiples archivos de origen, de modo que es más fácil limitar el acceso de cada archivo a las variables globales.
Configure un mecanismo para bloquearlos y desbloquearlos, y / o diseñe su código de modo que la menor cantidad posible de funciones necesite modificar realmente las variables globales. Leerlos es mucho más seguro que escribirlos, aunque las carreras de subprocesos aún pueden causar problemas en programas de múltiples subprocesos.
Básicamente, minimice el acceso a ellos y maximice la singularidad del nombre. Desea evitar las colisiones de nombres y tener la menor cantidad de funciones posibles que puedan modificar cualquier variable.

Si son buenos o malos depende de cómo los uses. La mayoría tiende a usarlos mal, de ahí la cautela general hacia ellos. Si se usan correctamente, pueden ser una gran ayuda; sin embargo, si se utilizan de forma deficiente, pueden y volverán a morderle cuando menos lo desee.

Una buena forma de verlo es que ellos mismos no son malos, pero permiten un mal diseño y pueden multiplicar exponencialmente los efectos de un mal diseño.

Incluso si no tiene la intención de usarlos, es mejor saber cómo usarlos de manera segura y elegir no hacerlo, que no usarlos porque no sabe cómo usarlos de manera segura. Si alguna vez se encuentra en una situación en la que necesita mantener un código preexistente que se basa en variables globales, es posible que tenga dificultades si no sabe cómo usarlas correctamente.

El problema que crean las variables globales para el programador es que expande la superficie de acoplamiento entre componentes entre los diversos componentes que utilizan las variables globales. Lo que esto significa es que a medida que aumenta el número de componentes que utilizan una variable global, también puede aumentar la complejidad de las interacciones. Este mayor acoplamiento generalmente hace que los defectos sean más fáciles de inyectar en el sistema cuando se realizan cambios y también hace que los defectos sean más difíciles de diagnosticar y corregir. Este aumento en el acoplamiento también puede reducir el número de opciones disponibles al realizar cambios y puede aumentar el esfuerzo requerido para los cambios, ya que a menudo se debe rastrear a través de los diversos módulos que también utilizan la variable global para determinar las consecuencias de los cambios.

El propósito de la encapsulation , que es básicamente lo opuesto al uso de variables globales, es disminuir el acoplamiento para hacer que la comprensión y el cambio de la fuente sea más fácil, más seguro y más fácil de probar. Es mucho más fácil usar la prueba unitaria cuando no se usan variables globales.

Por ejemplo, si tiene una variable de entero global simple que se está utilizando como un indicador enumerado que varios componentes usan como máquina de estado y luego realiza un cambio agregando un nuevo estado para un nuevo componente, entonces debe rastrear todos los demás Componentes para asegurar que el cambio no los afectará. Un ejemplo de un posible problema sería si se utiliza una declaración de switch para probar el valor de la variable global de enumeración con declaraciones de case para cada uno de los valores actuales en varios lugares y sucede que algunas de las declaraciones de switch no tienen una default caso default para manejar un valor inesperado para el global de repente tiene un comportamiento indefinido en lo que respecta a la aplicación.

Por otro lado, el uso de un área de datos compartidos se puede usar para contener un conjunto de parámetros globales a los que se hace referencia en toda la aplicación. Este enfoque se utiliza a menudo con aplicaciones integradas con pequeñas huellas de memoria.

Cuando se usan variables globales en este tipo de aplicaciones, la responsabilidad de escribir en el área de datos se asigna a un solo componente y todos los demás componentes ven el área como const y leen, nunca escriben en ella. Tomar este enfoque limita los problemas que pueden desarrollarse.

Aquí hay algunos problemas con el uso de variables globales que necesitan ser resueltos.

Cuando se modifica el origen de una variable global, como una estructura, todo lo que se use debe volver a compilarse para que todo lo que use la variable sepa su tamaño real y la plantilla de memoria.

Si más de un componente puede modificar la variable global, puede tener problemas con datos inconsistentes en la variable global. Con una aplicación de subprocesos múltiples, probablemente necesitará agregar algún tipo de bloqueo o región crítica para proporcionar una manera de que solo un subproceso a la vez pueda modificar la variable global y cuando un subproceso esté modificando la variable, todos los cambios están completos y confirmado antes de que otros subprocesos puedan consultar la variable o modificarla.

Depurar una aplicación de subprocesos múltiples que utiliza una variable global puede ser más difícil. Puedes correr en condiciones de carrera que pueden crear defectos difíciles de replicar. Con varios componentes que se comunican a través de una variable global, especialmente en una aplicación de múltiples subprocesos, poder saber qué componente está cambiando la variable cuándo y cómo está cambiando la variable puede ser muy difícil de entender.

El choque de nombres puede ser un problema con el uso de variables globales. Una variable local que tiene el mismo nombre que una variable global puede ocultar la variable global. También se encuentra con el problema de la convención de nombres al utilizar el lenguaje de programación C. Una solución alternativa es dividir el sistema en subsistemas con las variables globales para un subsistema en particular, comenzando con las mismas primeras tres letras (vea esto sobre la resolución de colisiones de espacio de nombres en el objetivo C ). C ++ proporciona espacios de nombres y con C puede solucionar esto creando una estructura visible a nivel mundial cuyos miembros son varios elementos de datos y punteros a datos y funciones que se proporcionan en un archivo como estático, por lo tanto, con visibilidad de archivos solo para que solo puedan ser referenciados La estructura visible a nivel mundial.

En algunos casos, la intención de la aplicación original se cambia para que las variables globales que proporcionaron el estado para un solo hilo se modifiquen para permitir que se ejecuten varios subprocesos duplicados. Un ejemplo sería una aplicación simple diseñada para un solo usuario que usa variables globales para el estado y luego una solicitud viene de la administración para agregar una interfaz REST para permitir que las aplicaciones remotas actúen como usuarios virtuales. Así que ahora tiene que duplicar las variables globales y su información de estado para que tanto el usuario individual como cada uno de los usuarios virtuales de aplicaciones remotas tengan su propio conjunto único de variables globales.

El uso de variables globales en realidad depende de los requisitos. Su ventaja es que reduce la sobrecarga de pasar los valores repetidamente.

Pero su profesor tiene razón porque plantea problemas de seguridad, por lo que el uso de variables globales debe evitarse tanto como sea posible. Las variables globales también crean problemas que a veces son difíciles de depurar .

Por ejemplo:-

Situaciones en las que los valores de las variables se modifican en tiempo de ejecución . En ese momento es difícil identificar qué parte del código lo está modificando y en qué condiciones.

En una aplicación de subprocesos múltiples, use variables locales en lugar de variables globales para evitar una condición de carrera.

Una condición de carrera se produce cuando varios subprocesos acceden a un recurso compartido, con al menos un subproceso que tiene acceso de escritura a los datos. Entonces, el resultado del programa no es predecible y depende del orden de acceso a los datos por diferentes subprocesos.

Más sobre esto aquí, https://software.intel.com/en-us/articles/use-intel-parallel-inspector-to-find-race-conditions-in-openmp-based-multithreaded-code

Las aplicaciones web dentro de una empresa pueden utilizarse para mantener datos específicos de sesión / ventana / hilo / usuario en el servidor por razones de optimización y para evitar la pérdida de trabajo donde la conexión es inestable. Como se mencionó, las condiciones de la carrera deben ser manejadas. Utilizamos una sola instancia de una clase para esta información y se administra con cuidado.

Las variables globales están bien en programas pequeños, pero horribles si se usan de la misma manera en programas grandes.

Esto significa que puedes adquirir fácilmente el hábito de usarlos mientras aprendes. Esto es de lo que tu profesor está tratando de protegerte.

Cuando tengas más experiencia, será más fácil aprender cuando estén bien.

Las variables globales solo deben usarse cuando no tenga otra alternativa. Y sí, eso incluye a Singletons. El 90% de las veces, se introducen variables globales para ahorrar el costo de pasar un parámetro. Y luego ocurre la codificación de subprocesos / pruebas unitarias / mantenimiento, y tiene un problema.

Entonces sí, en el 90% de las situaciones las variables globales son malas. Es probable que no veas las excepciones en tus años universitarios. Una excepción que se me ocurre es tratar con objetos intrínsecamente globales, como las tablas de interrupciones. Cosas como la conexión de DB parecen ser globales, pero no lo son.

Las variables globales son generalmente malas, especialmente si otras personas están trabajando en el mismo código y no quieren gastar 20 minutos en buscar todos los lugares a los que se hace referencia a la variable. Y agregar hilos que modifican las variables trae un nuevo nivel de dolores de cabeza.

Las constantes globales en un espacio de nombres anónimo utilizado en una sola unidad de traducción son finas y ubicuas en aplicaciones profesionales y bibliotecas. Pero si los datos son mutables y / o tienen que ser compartidos entre múltiples TU, es posible que desee encapsularlos: si no fuera por el diseño, entonces, por el bien de cualquiera, depurando o trabajando con su código.

Las variables globales son malas, si te permiten manipular aspectos de un programa que solo deberían modificarse localmente. En OOP, los globales a menudo entran en conflicto con la idea de encapsulación.

Las variables globales son tan malas como las haces, nada menos.

Si está creando un programa totalmente encapsulado, puede usar globales. Es un "pecado" usar globos globales, pero la programación de los pecados es muy antigua y filosófica.

Si revisa L.in.oleum , verá un idioma cuyas variables son únicamente globales. No es escalable porque las bibliotecas no tienen más remedio que usar globales.

Dicho esto, si tiene opciones y puede ignorar la filosofía del programador, los globales no son tan malos.

Tampoco los Gotos, si los usas bien.

El gran "mal" problema es que, si los usas mal, la gente grita, el vehículo de aterrizaje de Mars se estrella y el mundo explota ... o algo así.

Lo importante es recordar el objetivo general: claridad.

La regla "no hay variables globales" está ahí porque la mayoría de las veces, las variables globales hacen que el significado del código sea menos claro.

Sin embargo, como muchas reglas, las personas recuerdan la regla, y no lo que la regla pretendía hacer.

He visto programas que parecen duplicar el tamaño del código al pasar una enorme cantidad de parámetros simplemente para evitar el mal de las variables globales. Al final, el uso de globales habría aclarado el programa a quienes lo leen. Al adherirse sin pensar a la palabra de la regla, el programador original había fallado en la intención de la regla.

Entonces, sí, los globales son a menudo malos. Pero si siente que al final, la intención del programador se hace más clara mediante el uso de variables globales, y luego siga adelante. Sin embargo, recuerde la disminución de la claridad que se produce automáticamente cuando obliga a alguien a acceder a una segunda parte del código (los globales) para comprender cómo funciona la primera parte.

Me gustaría argumentar contra el punto que se está haciendo a lo largo de este hilo que hace que los subprocesos sean más difíciles o imposibles per se. Las variables globales son estados compartidos, pero las alternativas a las globales (por ejemplo, pasar punteros) también pueden compartir el estado. El problema con los subprocesos múltiples es cómo usar correctamente el estado compartido, no si ese estado se comparte a través de una variable global o algo más.

La mayoría de las veces, cuando haces subprocesos múltiples, necesitas compartir algo. En un patrón de productor-consumidor, por ejemplo, puede compartir una cola segura para subprocesos que contiene las unidades de trabajo. Y puedes compartirlo porque esa estructura de datos es segura para subprocesos. Si esa cola es global o no es completamente irrelevante cuando se trata de seguridad de subprocesos.

La esperanza implícita expresada a lo largo de este hilo de que la transformación de un programa de subproceso único a multiproceso será más fácil cuando no se utilizan globales es ingenuo. Sí, los globales facilitan dispararte a ti mismo en el pie, pero hay muchas formas de dispararte a ti mismo.

No estoy defendiendo a los globales, ya que los otros puntos siguen en pie, mi punto es simplemente que el número de subprocesos en un programa no tiene nada que ver con el alcance variable.

Mi profesor solía decir algo como: usar variables globales está bien si las usas correctamente. No creo que alguna vez sea bueno usándolos correctamente, por lo que rara vez los uso en absoluto.

No, no son para nada malos. Necesitas mirar el código (de la máquina) producido por el compilador para hacer esta determinación, a veces es mucho peor usar un local que global. También tenga en cuenta que poner "estática" en una variable local básicamente lo hace un global (y crea otros problemas feos que un verdadero global resolvería). Los "globales locales" son particularmente malos.

Los Globals también te dan un control limpio sobre el uso de tu memoria, algo mucho más difícil de hacer con los locales. Estos días eso solo importa en entornos integrados donde la memoria es bastante limitada. Algo que debe saber antes de asumir que incrustado es lo mismo que en otros entornos y que las reglas de programación son las mismas en todos los ámbitos.

Es bueno que cuestione las reglas que se enseñan, la mayoría de ellas no son por las razones por las que se les dice. Sin embargo, la lección más importante no es que esta es una regla que debes llevar contigo para siempre, sino que es una regla que se debe cumplir para pasar esta clase y seguir adelante. En la vida encontrará que para la compañía XYZ tendrá otras reglas de programación que al final tendrá que cumplir para poder recibir un cheque de pago. En ambas situaciones, puedes discutir la regla, pero creo que tendrás mucha mejor suerte en un trabajo que en la escuela. Tú eres solo otro de muchos estudiantes, tu asiento será reemplazado pronto, los profesores no, en un trabajo eres uno de un pequeño equipo de jugadores que tienen que ver este producto hasta el final y en ese entorno las reglas desarrolladas son para el beneficio de los miembros del equipo, así como del producto y la compañía, por lo que si todos tienen una mentalidad similar o si para el producto en particular hay una buena razón de ingeniería para violar algo que aprendió en la universidad o algún libro sobre programación genérica, entonces venda su idea a El equipo y escríbalo como válido si no es el método preferido. Todo es juego limpio en el mundo real.

Si sigue todas las reglas de programación que le enseñaron en la escuela o en los libros, su carrera de programación será extremadamente limitada. Es probable que puedas sobrevivir y tener una carrera fructífera, pero la amplitud y la amplitud de los entornos disponibles serán extremadamente limitadas. Si sabes cómo y por qué la regla está ahí y puedes defenderla, eso es bueno, si solo la razón es "porque mi maestro lo dijo", eso no es tan bueno.

Tenga en cuenta que los temas como este a menudo se discuten en el lugar de trabajo y continuarán siéndolo, a medida que los compiladores y procesadores (y los idiomas) evolucionen, también lo hacen este tipo de reglas y sin defender su posición y, posiblemente, recibir una lección de alguien con otra opinión, no lo harán. avanzar hacia adelante

Mientras tanto, simplemente haz lo que diga el que diga más fuerte o que lleve el palo más grande (hasta que sea el momento en que tú eres el que grita más fuerte y lleva el palo más grande).

Por lo general, uso valores globales para valores que rara vez se cambian como singletons o punteros de función a funciones en la biblioteca cargada dinámicamente. El uso de elementos globales mutables en aplicaciones de multiproceso tiende a dificultar el seguimiento de errores, así que trato de evitar esto como una regla general.

El uso de un argumento global en lugar de pasar un argumento suele ser más rápido, pero si está escribiendo una aplicación de multiproceso, como lo hace a menudo en la actualidad, generalmente no funciona muy bien (puede usar subprocesos, pero la ganancia de rendimiento es cuestionable). .

Sí, pero no incurres en el costo de las variables globales hasta que dejas de trabajar en el código que usa las variables globales y comienza a escribir otra cosa que usa el código que usa las variables globales. Pero el costo sigue ahí.

En otras palabras, es un costo indirecto a largo plazo y, como tal, la mayoría de la gente piensa que no está mal.

Sí, porque si dejas que los programadores incompetentes los usen (leen 90% especialmente a científicos) terminas con más de 600 variables globales distribuidas en más de 20 archivos y un proyecto de 12,000 líneas donde el 80% de las funciones se anulan, devuelven y operan enteramente en el estado global.

Rápidamente se vuelve imposible entender lo que está sucediendo en cualquier punto a menos que conozca todo el proyecto.

Si es posible que su código termine bajo una revisión intensiva durante un juicio de la Corte Suprema , entonces debe asegurarse de evitar las variables globales.

Vea este artículo: El código de alcoholímetro de Buggy refleja la importancia de la revisión de la fuente

Hubo algunos problemas con el estilo del código que se identificaron en ambos estudios. Uno de los problemas estilísticos que preocupaban a los revisores era el uso extensivo de variables globales desprotegidas . Esto se considera una forma deficiente porque aumenta el riesgo de que el estado del programa se vuelva inconsistente o que los valores se modifiquen o sobrescriban inadvertidamente. Los investigadores también expresaron cierta preocupación por el hecho de que la precisión decimal no se mantiene constantemente en todo el código.

Hombre, ¡apuesto a que los desarrolladores desean que no hayan usado variables globales!

Tarde o temprano, deberá cambiar la forma en que se establece esa variable o lo que sucede cuando se accede a ella, o simplemente debe buscar dónde se modifica.

Prácticamente siempre es mejor no tener variables globales. Simplemente escriba los métodos de obtención y configuración de la presa, y sea glándula cuando los necesite un día, una semana o un mes después.

Usar variables globales es como barrer la suciedad debajo de una alfombra. Es una solución rápida y mucho más fácil a corto plazo que conseguir un recipiente para el polvo o una aspiradora para limpiarlo. Sin embargo, si alguna vez terminas moviendo la alfombra más adelante, tendrás un gran lío sorpresa debajo.

la seguridad es menos significa que cualquiera puede manipular las variables si se declaran globales, para explicar esto tome este ejemplo si tiene el equilibrio como variable global en su programa bancario, la función del usuario puede manipular esto, así como el oficial del banco también puede manipular esto significa que hay un problema. al usuario solo se le debe otorgar la función de solo lectura y retiro, pero el empleado del banco puede agregar la cantidad cuando el usuario entregue personalmente el efectivo en el escritorio. Esta es la forma en que funciona.

Los globales son buenos cuando se trata de configuración . Cuando queremos que nuestra configuración / cambios tengan un impacto global en todo el proyecto .

Así que podemos cambiar una configuración y los cambios se dirigen a todo el proyecto . Pero debo advertir que tendrías que ser muy inteligente para usar globales.