当前位置:  开发笔记 > 编程语言 > 正文

你什么时候使用"this"关键字?

如何解决《你什么时候使用"this"关键字?》经验,为你挑选了11个好方法。

我很好奇其他人如何使用this关键字.我倾向于在构造函数中使用它,但我也可以在其他方法中使用它.一些例子:

在构造函数中:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

别处

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

Scott Wisnie.. 243

我并不是说听起来很讽刺,但这并不重要.

认真.

看看重要的事情:你的项目,你的代码,你的工作,你的个人生活.他们中的任何一个都不会取决于您是否使用"this"关键字来限定对字段的访问权限.this关键字无法帮助您准时发货.它不会减少错误,它不会对代码质量或可维护性产生任何明显的影响.它不会让你加薪,或者让你在办公室花更少的时间.

这真的只是一个风格问题.如果你喜欢"这个",那就用吧.如果你不这样做,那就不要了.如果你需要它来获得正确的语义,那么使用它.事实是,每个程序员都有自己独特的编程风格.这种风格反映了特定程序员关于"最美观的代码"应该是什么样子的概念.根据定义,读取代码的任何其他程序员将具有不同的编程风格.这意味着总会有一些你做的事,而另一个人不喜欢,或者会做出不同的事情.在某些时候,有些人会阅读你的代码并抱怨某事.

我不会担心它.我会根据你自己的口味确保代码尽可能美观.如果你问10个程序员如何格式化代码,你将获得大约15种不同的意见.关注的一个更好的方法是如何将代码考虑在内.事情抽象得对吗?我选择了有意义的名字吗?是否有很多代码重复?有什么方法可以简化内容吗?我认为,将这些事情做好,将对您的项目,代码,工作和生活产生最大的积极影响.巧合的是,它可能也会让另一个人抱怨最少.如果您的代码有效,易于阅读,并且考虑周全,那么另一个人就不会仔细检查如何初始化字段.他只是要使用你的代码,惊叹于它的伟大,



1> Scott Wisnie..:

我并不是说听起来很讽刺,但这并不重要.

认真.

看看重要的事情:你的项目,你的代码,你的工作,你的个人生活.他们中的任何一个都不会取决于您是否使用"this"关键字来限定对字段的访问权限.this关键字无法帮助您准时发货.它不会减少错误,它不会对代码质量或可维护性产生任何明显的影响.它不会让你加薪,或者让你在办公室花更少的时间.

这真的只是一个风格问题.如果你喜欢"这个",那就用吧.如果你不这样做,那就不要了.如果你需要它来获得正确的语义,那么使用它.事实是,每个程序员都有自己独特的编程风格.这种风格反映了特定程序员关于"最美观的代码"应该是什么样子的概念.根据定义,读取代码的任何其他程序员将具有不同的编程风格.这意味着总会有一些你做的事,而另一个人不喜欢,或者会做出不同的事情.在某些时候,有些人会阅读你的代码并抱怨某事.

我不会担心它.我会根据你自己的口味确保代码尽可能美观.如果你问10个程序员如何格式化代码,你将获得大约15种不同的意见.关注的一个更好的方法是如何将代码考虑在内.事情抽象得对吗?我选择了有意义的名字吗?是否有很多代码重复?有什么方法可以简化内容吗?我认为,将这些事情做好,将对您的项目,代码,工作和生活产生最大的积极影响.巧合的是,它可能也会让另一个人抱怨最少.如果您的代码有效,易于阅读,并且考虑周全,那么另一个人就不会仔细检查如何初始化字段.他只是要使用你的代码,惊叹于它的伟大,


`this`关键字在语义上是有意义的.请参阅下面的@JasonBunting评论.你把"this"的风格过度使用与其实际目的相混淆.你的话不只是轻率,这是错的!
如果你有机会,你可能想重新阅读我的答案.我谈到在需要正确语义的情况下使用它.您可能还想查看原始问题.它显示了在语义上不必要的示例中的用法.所以,我不确定我所说的"错误".我的回答当然不是轻率的.
你知道你的回答对我来说怎么样?在这两行之间,我读到"你怎么敢问这样的问题?" - 在我看来,这真的不具有建设性.没有人知道一切 - 这就是为什么我们有Stackoverflow:帮助他人并获得帮助.你知道一些话题,有些人了解其他话题.互相帮助,不要互相争斗.请考虑一下.
我并不是说听起来很讽刺,但这是迄今为止最糟糕的答案之一.我不认为将这与你的工作或个人生活进行比较是有用的.仅仅因为某些事情不如其他事情重要并不意味着它们不重要*.具有一致的编程风格并不是不重要的(阅读一本关于代码可读性/可选性的可维护性的书).
我想你可能误解了我的观点.并非"具有一致的风格"是不好的.我没有说那个效果.这就是"我的风格指南要求'这个问题"的操作问题.作为所有现场访问的前缀?" 是任意和反复无常的.
实际上,你和OP都没有提到风格指南.事实上,你说*"如果你喜欢"这个",那么就使用它.如果你不喜欢,那就不要."*和*"每个程序员都有自己独特的编程风格"*.每次我阅读时,这个答案都会变得越来越糟.我认为你应该面对这样一个事实:它有18个downvotes并考虑完全重写(虽然这对已经投票的人不公平)或删除它.

2> Jakub Šturc..:

有几种用法这个关键字在C#.

    限定隐藏类似名称的成员

    让对象将自身作为参数传递给其他方法

    让对象从方法返回自己

    声明索引器

    声明扩展方法

    在构造函数之间传递参数

    要在内部重新分配值类型(struct)值.

    在当前实例上调用扩展方法

    将自己投射到另一种类型

    链接在同一个类中定义的构造函数

您可以通过不在作用域中使用具有相同名称的成员和局部变量来避免第一次使用,例如通过遵循常见的命名约定并使用属性(Pascal case)而不是字段(camel case)来避免与局部变量(也是camel)发生冲突案件).在C#3.0中,可以使用自动实现的属性轻松地将字段转换为属性.


8.在当前实例上调用扩展方法(`this.Foo();`将起作用,但``Foo()`不会)
只有遵守样式约定,即属性不能与参数具有相同的名称,才能通过属性*访问字段来避免第一个问题.*恰好,流行的C#样式约定符合该要求.然而,并非所有C#都是根据该约定编写的.属性本身没有什么固有的东西会使`this`关键字变得不必要; 一个名为`x`的构造函数参数将隐藏一个名为`x`的成员,无论该成员是字段,属性还是事件.
也可以将自己转换为另一种类型,例如,显式实现的方法将被称为`((ICollection )this).Add(bla)`.
将构造链接到同一类型中定义的另一个构造函数.`public ClassName(...):this(...)`.

3> Corey..:

我只在绝对必要时使用它,即当另一个变量影响另一个变量时.如:

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

或者正如Ryan Fox指出的那样,当你需要将此作为参数传递时.(局部变量优先于成员变量)


在这种情况下,为什么不只是给构造函数的输入变量赋予不同的名称?

4> Brandon Wood..:

就个人而言,我尝试在引用成员变量时始终使用.它有助于澄清代码并使其更具可读性.即使没有歧义,有人第一次阅读我的代码并不知道,但如果他们看到这种情况一直使用,他们就会知道他们是否正在查看成员变量.


但如果你有时忘记使用它们,他们会感到困惑
大多数人似乎从不阅读,优化或重写别人的代码!预选赛是节省时间和动力的!如果你看到任何任意代码行,没有限定符就像魔法一样.因此,您只需检查这些变量来自哪里就浪费所有时间.
@surfen好像你在模棱两可的情况下忘了它.我可以通过说"但如果你忘了......"来打破任何争论.
@surfen可以通过额外的样式检查来避免,例如在Java中你可以使用Checkstyle并在完整构建后运行它(在任何流行的迭代/ OO语言中都会有类似的工具)
我知道这是一篇很老的文章,但是我不得不对此评论的讽刺之处发表评论(我恰好同意)。在反对邪恶的匈牙利符号的圣战中,任何敢于为成员变量加上“ m_”前缀的人都被嘲笑,因为区分成员变量只是没有用或不需要。

5> Thomas Owens..:

我每次引用实例变量时都会使用它,即使我不需要.我认为它使代码更清晰.



6> Jason Buntin..:

我无法相信所有使用它的人总是一个"最佳实践"等等.

当存在歧义时使用"this",如Corey的示例中或当您需要将对象作为参数传递时,如Ryan的示例中所示.没有理由使用它,否则因为能够根据范围链解析变量应该足够清楚,以及使用它的限定变量应该是不必要的.

编辑:关于"this"的C#文档表示除了我提到的两个用于"this"关键字的另一个用途 - 用于声明索引器

编辑:@Juan:嗯,我没有看到我的陈述中有任何不一致 - 有三个实例我会使用"this"关键字(如C#文档中所述),而那些是你真正需要的时候.当没有阴影时,在构造函数中的变量前面粘贴"this"只是浪费击键而浪费我的时间阅读它,它没有任何好处.


@ [JasonBunting](http://stackoverflow.com/questions/23250/when-do-you-use-the-this-keyword#23306):有时你不能做某事而不是其他人...这令人困惑...***我希望我永远不会在你的***代码中工作你不能总是认为将来读你的代码的人会理解你写的东西,你需要像尽可能清楚,实现它的一种方法是保持一致
@ScottAdams我仍然相信连贯性和清晰度,是的

7> Ian Nelson..:

每当StyleCop告诉我时,我都会使用它.必须遵守StyleCop.哦,是的.



8> Ryan Fox..:

任何时候您需要对当前对象的引用.

一个特别方便的场景是当你的对象调用一个函数并希望将自己传递给它时.

例:

void onChange()
{
    screen.draw(this);
}



9> Philippe..:

我倾向于在任何地方使用它,只是为了确保它是我们正在处理的实例成员.



10> TheSmurf..:

我在任何可能存在歧义的地方使用它(显然).不仅仅是编译器歧义(在这种情况下需要它),而且对于看到代码的人来说也是模棱两可的.



11> Paul Batum..:

this关键字的另一个有点罕见的用途是当您需要从实现类中调用显式接口实现时.这是一个人为的例子:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

推荐阅读
郑谊099_448
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有