显然,那里的意见种类很多,其中包括" 永远!永远封装(即使它仅仅是一个宏!) "至" 这没什么大不了的 - 当它更方便时使用它们. "
所以.
具体,具体原因(最好以一个例子为准)
为什么全局变量是危险的
应使用全局变量代替替代方案
那些试图不恰当地使用全局变量的人存在哪些替代方案
虽然这是主观的,但我会选择一个答案(对我而言,这最能代表每个开发人员应该与全局人员建立的爱/恨关系),社区将投票给他们.
我相信新手有这样的参考是很重要的,但如果存在与你的答案基本相似的另一个答案,请不要混淆 - 添加评论或编辑其他人的答案.
-亚当
变量应始终具有较小的范围.这背后的论点是,每次增加范围时,您都会有更多可能修改变量的代码,从而在解决方案中引入更多复杂性.
因此很明显,如果设计和实现自然允许,则优选避免使用全局变量.因此,除非确实需要,否则我不喜欢使用全局变量.
我也不能同意"从不"的陈述,就像任何其他概念一样,全局变量是一个应该在需要时使用的工具.我宁愿使用全局变量而不是使用一些人工构造(比如传递指针),这只会掩盖真实的意图.使用全局变量的好例子是嵌入式系统中的单例模式实现或寄存器访问.
关于如何实际检测全局变量的过度使用:检查,检查,检查.每当我看到一个全局变量时,我都要问自己:全球范围内真的需要它吗？
使全局变量起作用的唯一方法是给它们命名,以确保它们是唯一的.
该名称通常具有与某些"模块"或全局变量特别关注或有意义的函数集合相关联的前缀.
这意味着变量"属于"那些函数 - 它是它们的一部分.实际上,全局通常可以"包装"一个与其他函数一起使用的小函数 - 在同一.h文件中使用相同的名称前缀.
奖金.
当你这样做时,突然间,它不再是真正的全球性.它现在是相关功能模块的一部分.
这总是可以做到的.稍微考虑一下,可以将每个以前的全局变量分配给某些函数集合,分配给特定.h文件,并使用允许您更改变量而不会破坏任何内容的函数进行隔离.
您可以说"将全局变量的职责分配给最有意义的模块",而不是说"从不使用全局变量".
考虑一下这个公案:"如果范围足够窄,一切都是全球性的".
在这个时代,仍然很可能需要编写一个非常快速的实用程序来完成一次性工作.
在这种情况下,创建安全访问变量所需的能量大于通过调试这种小型实用程序中的问题所节省的能量.
这是唯一可以在全局变量明智的情况下考虑的情况,而且这种情况相对较少.有用的,新颖的程序如此之小,可以完全保存在大脑的短期记忆中,这种程序越来越少,但它们仍然存在.
事实上,我可以大胆地声称如果程序不是那么小,那么全局变量应该是非法的.
如果变量永远不会改变,那么它是一个常数,而不是一个变量.
如果变量需要通用访问,那么应该存在两个子程序来获取和设置它们,并且它们应该是同步的.
如果程序从小开始,并且稍后可能更大,那么代码就好像程序今天很大,并且取消全局变量.并非所有计划都会增长!(当然,这假设程序员有时愿意丢弃代码.)
如果多个方法需要变量(而不是将变量传递给每个方法),C中的全局变量对于使代码更具可读性非常有用.但是,它们很危险,因为所有位置都能够修改该变量,因此很难找到错误.如果必须使用全局变量,请始终确保仅通过一种方法直接修改它,并让所有其他调用方使用该方法.这将使调试与该变量的变化相关的问题变得更加容易.
当你不担心线程安全的代码时:在任何有意义的地方使用它们,换句话说,将某些东西表达为全局状态是有意义的.
当您的代码可能是多线程的时:避免不惜一切代价.抽象的全局变量进入工作队列或其他一些线程安全的结构,或者如果绝对必要将它们包装在锁中,请记住这些可能是程序中的瓶颈.
京公网安备 11010802040832号 | 京ICP备19059560号-6 