C# 如何声明全局变量?

C# 如何声明全局变量?,c#,C#,我对变量声明中的内存管理有疑问 在我的类中,我有大约20个方法,我在整个类中使用了大约50个变量 我在类的开头全局声明了所有变量 这是正确的做法吗?或者哪一个更好。。。使用结构或任何其他东西 下面是一个基本的例子,我需要使用优化我的内存 class Program { static int a, b, c, d; //----> Here am declaring , i need any other way static

我对变量声明中的内存管理有疑问

在我的类中,我有大约20个方法,我在整个类中使用了大约50个变量

我在类的开头全局声明了所有变量

这是正确的做法吗?或者哪一个更好。。。使用结构或任何其他东西

下面是一个基本的例子,我需要使用优化我的内存

  class Program
    {
        static  int a, b, c, d;           //----> Here am declaring , i need any other way
        static void Main(string[] args)
        {
            a = 10;
            b = 20;
            c = 30;
            d = 40;

            int result = add(a, b, c, d);
            Console.WriteLine(result);
            Console.ReadLine();
        }
        public static int add(int w, int x, int y, int z)
        {
            return w + x + y + z;
        }
    }

您的类级别变量仅在单个方法中使用,因此仅在该方法的范围内声明它们:

static void Main(string[] args)
{
    var a = 10;
    var b = 20;
    var c = 30;
    var d = 40;

    int result = add(a, b, c, d);
    Console.WriteLine(result);
    Console.ReadLine();
}
根据经验,尽量使变量接近其用途。任何时候,范围必须增加,请后退一步,考虑结构。不要盲目地将变量向上移动

您试图优化代码的资源消耗有什么原因吗?很可能,特别是在如此简单的情况下,编译器已经在这方面做得很好了。除非你看到了实际问题,否则不要过早地优化。这通常会导致代码无法管理


另外,这是一个旁注,因为我知道这是一个人为的例子。。。有意义的变量名非常重要。有意义的名称还可以帮助您理解和识别所需的变量范围。如果一个变量被称为
a
,那么它不会给你任何关于它的含义的上下文。但是,如果名称告诉您它的含义,那么您可以更容易地可视化代码中实际负责该值的上下文,从而得到更好的范围定义。

使用全局变量通常被认为是不好的做法。什么使你认为你需要全局范围?这50个变量是什么?你能说得更清楚吗?不要过早地优化。“我需要优化我的记忆”不,你可能不需要。您的程序/机器是否因为占用太多内存而崩溃?您应该根据使程序更易于阅读、理解、管理等来确定变量的范围,而不是根据程序消耗的内存量,直到您知道它使用的内存超出了可接受的范围。内存中额外的一两个整数(或50)实际上永远不会成为问题。也就是说,出于设计原因,您应该尽可能避免使用全局变量。而不是每次在方法中定义变量时,我都在全局中声明它……这不是一个好做法吗???如果是,你能建议哪一个更好吗?你的全局变量实际上是常数,还是你必须修改它们?声明常量全局(使用const而不是static)是一种不错的做法。使用静态变量只是为了避免局部声明是一种糟糕的做法,但是在下面的例子中,我在方法1和方法2中使用了变量a和b,所以u人建议在局部声明它们。。。。。。。公共静态int-Method1(inta1){var a=15;var b=10;int-res=a*b;return res*a1;}公共静态int-Method2(inta1){var a=100;var b=10;int-res=a*b;return res*a1;}@YUG:同样,这个例子太做作了。关于这些变量的含义、这些方法的作用、对象是什么等等,没有上下文。如果没有任何有意义的上下文,我会偏向于局部范围而不是全局范围。在您上面的评论中,我看不出有任何令人信服的理由将
a
b
res
转移到一个更全球化的范围。仅仅因为方法实现做了非常相似的事情并不意味着它们的内部实现应该对外公开。与微观优化相比,更喜欢单一责任。