que - ¿Por qué son malas las variables globales, en una aplicación incrustada de un solo hilo, sin sistema operativo?
variables locales y globales ejemplos (13)
Aquí hay un buen artículo que explica por qué las variables globales son malas.
¿Por qué las variables globales deberían evitarse cuando no son necesarias?
No localidad: el código fuente es más fácil de entender cuando el alcance de sus elementos individuales es limitado. Las variables globales pueden ser leídas o modificadas por cualquier parte del programa, haciendo que sea difícil de recordar o razonar acerca de cada uso posible. Sin control de acceso o verificación de restricciones: cualquier parte del programa puede obtener o establecer una variable global, y cualquier regla relacionada con su uso se puede romper u olvidar fácilmente.
Acoplamiento implícito: un programa con muchas variables globales a menudo tiene acoplamientos ajustados entre algunas de esas variables y acoplamientos entre variables y funciones. Agrupar elementos acoplados en unidades cohesivas generalmente conduce a mejores programas.
Problemas de asignación de memoria: algunos entornos tienen esquemas de asignación de memoria que hacen que la asignación de globales sea difícil. Esto es especialmente cierto en los idiomas en los que los "constructores" tienen efectos secundarios distintos de la asignación (porque, en ese caso, puede expresar situaciones inseguras en las que dos globales dependen mutuamente). Además, al vincular dinámicamente los módulos, puede no estar claro si las diferentes bibliotecas tienen sus propias instancias de globales o si se comparten los globales.
Pruebas y confinamiento: la fuente que utiliza globales es algo más difícil de probar porque uno no puede configurar fácilmente un entorno "limpio" entre ejecuciones. Más generalmente, la fuente que utiliza servicios globales de cualquier tipo que no se proporcionan explícitamente a esa fuente es difícil de probar por la misma razón.
Agregar globales es realmente fácil. Es fácil acostumbrarse a declararlos. Es mucho más rápido que pensar en un buen diseño.
Las variables globales no son tan malas como puede pensar, solo deben evitarse cuando sea innecesario. Las variables globales pueden tener un buen uso para una variable que se usaría en todo el programa, asegurándose de tener en cuenta que siempre hay que hacer un seguimiento de dónde la variable realiza cambios; pero para las variables que tienden a ser utilizadas solo en partes limitadas del programa es una buena razón para evitar que sea global.
La mayoría de las objeciones que veo al uso de variables globales tienen sentido, ya que se refieren a problemas de múltiples subprocesos, seguridad de subprocesos, etc.
Pero en un caso pequeño, de un solo hilo, sin sistema operativo, ¿qué objeciones tiene? En mi caso, estoy escribiendo mi sistema embebido en "C", si importa. También soy el único desarrollador en el producto.
¿Por qué la eliminación de variables globales mejoraría mi código?
(Después de leer varias respuestas, me doy cuenta de que también debería haber señalado que este sistema no tiene una asignación de memoria dinámica (por ejemplo, malloc). Toda la memoria está asignada estáticamente en tiempo de compilación).
Con las variables globales, a menudo es difícil saber dónde o cuándo se actualizan y qué parte del código actualiza esa variable. No hay control sobre quién puede actualizarlo o de qué manera se actualiza la variable.
No es tan difícil hacer un seguimiento de si su aplicación es pequeña, pero cuanto más grande se vuelve su aplicación y cuanto más variables globales tiene, más se ve el código de la aplicación como espagueti.
En resumen, se convierte en una pesadilla de mantenimiento y depuración.
El código que usa variables globales es más difícil de mantener. Dado que la mantenedora debe encontrar cada uso de la variable en el sistema antes de que pueda saber con precisión qué hace la variable. Dado que este mantenimiento lento debe evitarse tanto como sea posible. Eso es todo
El problema es rastrear qué parte de tu último código modificó el estado del global. En general, desea mantener las variables dentro del alcance más pequeño posible para poder razonar más fácilmente sobre ellas.
Es una cuestión de alcance. Tenemos desarrolladores que aman hacer variables globales para hacer conceptos locales. Hace que el uso de estas variables sea mucho más difícil de seguir, por lo que es más fácil cometer errores en el uso de estas variables.
También puede mantener su billetera en el porche delantero, pero entonces tiene mucho menos control sobre quién accede a ella.
Dicho esto, hay algunos usos válidos para la variable Global, pero como cualquier otra regla que valga la pena seguir. Esta es la excepción, no el caso normal. Su propia existencia señala que tienen un uso.
Si decides usar una variable global, intenta comentarlos bien y dales buenos nombres. Realmente me molesta cuando la gente crea variables globales como "bool bIsFound;"
Nos esforzamos por evaluar cada nueva variable global en la revisión del código y ver si hay un mejor enfoque.
La respuesta corta es que las variables globales han sido históricamente la fuente de errores sutiles. Pero entonces (poniendo en mi sombrero de programador funcional) todas las variables han sido fuentes de errores sutiles.
Básicamente, una variable global significa que no puede mirar un fragmento de código utilizando el valor de la variable, y saber qué va a hacer sin saber qué otra configuración de código de valor de esa variable ha hecho en el pasado.
Las variables globales no son necesariamente malas, al igual que las macros no son necesariamente malas y el uranio enriquecido no es necesariamente malo. Siempre que tome una decisión consciente sobre los pros y los contras de una elección de diseño determinada, debería estar bien.
Algunos de los argumentos en contra de las variables globales son:
- Violan el buen diseño orientado a objetos.
- Hacen que su código sea difícil de probar, ya que no puede probar bloques individuales de código sin configurar todas las variables globales que el código espera ver.
- Aumentan el acoplamiento en su código: las acciones en un bloque de código pueden afectar las cosas en otro bloque de código de manera impredecible a través de una variable global compartida
Algunos de los argumentos para variables globales:
- Facilitan el compartir un único recurso entre muchas funciones.
- Pueden hacer que el código sea más fácil de leer.
Si, en su diseño, las variables globales tienen sentido, y pueden usarse para hacer que su código sea más fácil de leer o mantener, sin configurarse para errores aleatorios y probar dolores de cabeza, entonces, por supuesto, utilícelos.
Escribo mucho código C para microcontroladores integrados y uso variables globales todo el tiempo. En un sistema tan rígido, las variables globales tienen sentido. Soy consciente de los posibles inconvenientes, pero he analizado los pros y los contras y escribo mi código para protegerme contra los principales escollos.
En pocas palabras: no hay una regla dura y rápida. Simplemente tome la mejor decisión para su proyecto o plataforma en particular, en función de la mejor información que tenga.
Las variables globales son necesarias en una pequeña aplicación incrustada escrita en C. Por ejemplo, necesita usar una variable global para pasar información entre una rutina de servicio de interrupción y otro módulo. Estos son algunos consejos que le ayudarán a hacer un uso efectivo de las variables globales en aplicaciones integradas:
Hacer una distinción entre variables estáticas y variables globales. Se pueden usar variables estáticas de todas las funciones en el mismo archivo C. Son el equivalente de miembros privados en una clase de C ++. En C tienes que hacer tú mismo el trabajo del compilador. Use la palabra clave estática para evitar el uso accidental de la variable fuera del módulo y hacer evidente su alcance. Es posible que desee prefijar la variable con el nombre del módulo.
Siga una convención de nomenclatura para variables globales (utilizada por muchos archivos C). Hacer evidente que son globales.
Si necesita muchas variables globales, considere agruparlas en una estructura.
Utilice la palabra clave volátil, cuando sea necesario. Esto es necesario si una variable global es modificada por un ISR.
Mantener la mayoría de las variables localmente y reducir su alcance ayuda a promover mejores prácticas de programación. También reduce el riesgo de cambiar una variable por error y tener que rastrear las funciones en busca de consecuencias no intencionadas o no obvias. Creo que también hace que el código sea más fácil de leer y mantener, ya que la mayoría de las variables relevantes para una sección particular del código se definen y se inician en las cercanías. De lo contrario, parece que me estoy refiriendo constantemente a la sección del código que define a todos los golbals. Utilizo algunas variables globales, pero principalmente para pasar información de configuración a submódulos.
No lo haria
Los dos problemas fundamentales con las variables globales son simplemente saturar el espacio de nombres, y el hecho de que "nadie" tiene "control" sobre ellos (por lo tanto, las posibles colisiones y conflictos con múltiples subprocesos).
Los "globales son malos", como casi todos los demás lenguajes de programación de computadoras son una guía, no una regla dura y rápida. Cuando se hacen este tipo de "reglas", es mejor en lugar de simplemente adoptar la regla de memoria para entender las circunstancias y motivaciones detrás de la creación de la regla. No se los tome a ciegas.
En su caso, parece entender la naturaleza de su sistema y los argumentos en torno a la regla y decidió que no se aplica en este caso. Tienes razón, no lo hace.
Entonces, no te preocupes por eso.
Porque minimiza el acoplamiento. Su sistema puede ser pequeño ahora, pero si sigue trabajando, puede que no lo sea.
Quizás las variables globales no son malas en tu caso. Por otro lado, ¿los necesitas? ¿Qué ganas usándolos?
Incluso en su caso, las variables globales hacen que sea más difícil averiguar el estado de la aplicación. Esto puede dificultar la depuración y puede dar lugar a errores sutiles.
Las variables globales también hacen que las pruebas sean más difíciles. Agregan dependencias en el código externo que tal vez desee evitar durante las pruebas.
Pero, por último, es difícil evitar los elementos globales cuando se programa en C. En un lenguaje más avanzado, los elementos globales simplemente carecen de sentido la mayor parte del tiempo. Usarlos simplemente no hace que tu código sea más claro.
En C, hay muchos casos en los que las redes globales son la mejor, la más simple y la solución más limpia.
Así que en tu caso, tómalo caso por caso. Probablemente termine teniendo algunos globales, pero no haga una variable global a menos que esté seguro de que es realmente la mejor solución, no solo ahora, sino también dentro de un año cuando tenga que depurar el código o hacer la aplicación. multihilo
Una razón que viene a la mente es la revisión futura. Es posible que ahora sea el único desarrollador de su producto, pero es posible que otros lo mantengan más adelante. Por supuesto, esto podría no ser cierto en su caso particular.
Si bien su producto puede ser pequeño y ordenado en este momento, donde el uso de variables globales no complica el diseño general ni compromete la legibilidad, ¿quién dice que el producto no será mucho más grande o se incorporará a otro producto? Y Dios no quiera que venga otro mantenedor / desarrollador, tienen que resolver su uso de variables globales.
Por supuesto, podría decidir usar variables globales ahora y cuando el proyecto parezca cada vez más complejo, regrese y reescriba partes de él, pero ¿por qué forzar ese trabajo extra en usted mismo? Es más probable (si recuerdas las variables globales) que decidir hacer ese trabajo es demasiado esfuerzo, y dejar el diseño: ¡en este punto estás en problemas!
Entonces , ahórrese el dolor de cabeza y el diseño con la vista puesta en el futuro. El trabajo requerido ahora probablemente facilitará la vida en el futuro.
Si eso no lo convenció, imagine que son los desarrolladores que trabajaron en este proyecto y que su código fue encontrado culpable de malas prácticas de programación ante el Tribunal Supremo: el código de alcoholímetro de Buggy refleja la importancia de la revisión de la fuente