将 null 传递给方法是否可接受

发布于 2024-10-27 19:08:02 字数 319 浏览 1 评论 0 原文

Null 对我来说是一种奇怪的数据类型,似乎使用它是错误的,也许是我作为初学者经常遇到的空指针错误,现在让我将任何 null 实例与某种邪恶联系起来!

无论如何,我的问题是

在某些情况下可以使用 null 作为参数吗?例如,一个方法可能需要a和b来完成一项任务,但在某些情况下它可能只需要a。在这些奇怪的实例中,对 b 进行 null 解析并检查 if(b==null) 是否可行,然后我们知道它是什么?

还是我在这里的方式?

我必须承认,让我想知道这是否可以接受的是,所讨论的方法可能被过度使用,但整个方法可能会有 5 或 6 行的差异。这让我担心代码重复。

Null is an odd data type for me, it seems as though it is wrong to ever use, maybe its the null pointer errors i got so often as a beginner that now have me associating any instance of null to some kind of evil!

Anyway my question is

in some cases is it ok to use null as a parameter? for example, a method may need a and b to do a task, but in some cases it may only need a. Is parsing in null ok for b in those odd instances and checking if(b==null) then we know what called it?

Or am i way of the mark here?

i must admit, what got me wondering whether this was acceptable was, the method in question could be overlaoded, but it would have a difference of possibly 5 or 6 lines out of the whole method. This made me worried about code duplication.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

影子的影子 2024-11-03 19:08:02

null 传递给方法绝对没问题。但是,如果您的 csae 可能不需要传递变量,请考虑 重载

您可能传递 null 的原因是因为您可能有一个带有相当多参数的方法,并且您不想实现所有可能的重载。

我个人不会不会使用可选参数 - 关于这个主题有很多讨论,因为方法作为合同的问题超出了这个问题的范围。


更新

正确的方法不是重复代码,而是让重载互相调用:

public void Foo(A a)
{
    Foo(a, null);
}
public void Foo(A a, B b)
{
        // .......
}

这将告诉客户端此代码:

  • 您只能使用 A 调用方法
  • 您可以使用 A 和 B 调用方法

如果我只有第二种方法,< strong>客户端不知道是否可以传递null

It is absolutely fine to pass null to methods. However, if you have a csae where you might not need to pass a variable, consider overloading.

The reason why you might pass a null is because you might have a method with quite a few parameters and you do not wan to implement all possible overloads.

I personally would not use optional parameters - there are many discussions on this very subject because of the issue with the method as Contract which is outside the scope of this question.


UPDATE

Correct way to do it is not to duplicate code but let overloads call each other:

public void Foo(A a)
{
    Foo(a, null);
}
public void Foo(A a, B b)
{
        // .......
}

This will tell client of this code:

  • You can call method with A only
  • You can call method with A and B

If I have only the second method, the client would not know if it is OK to pass null.

追风人 2024-11-03 19:08:02

我认为这是不行的。传递 null 从来都不是一个好的做法,在我看来,每当一个值具有 null 时,它都应该是一个例外。您可能并不总是能够控制数据的传递方式,在这种情况下,您应该检查 null 以防万一它发生。但是,如果您可以选择自己控制参数,则应该重载该方法,而不是传入 null。

考虑以下场景:

public string DoSomething(string a, string b)
{
   // Returns something after a and b is processed.
}

在此示例中,我们指示 a 和 b 是字符串。它们是 char[] 类型的对象,或者您想要定义的字符串。
在此方法中传递 null 根本没有任何意义,因为我们需要字符串。 null 是什么都没有——它不是一个空字符串——它只是空的。

我之所以说我不认为将 null 发送到方法中更好,是因为 null 从来没有任何用途。它只是留在那里的一个空白,作为未能实例化的东西的占位符。因此,像这样调用上面的方法:

DoSomething("whatever", null) 根本没有任何意义。

我们可能会说我们可以这样做:

/// <summary>
/// Does something with string a or b
/// </summary>
/// <param name="a">The first string. If it's null, nothing is done with it</param>
/// <param name="b">The second string. If it's null, nothing is done with it</param>
/// <returns></returns>
public string DoSomething(string a, string b)
{
    // Returns something after a and b is processed.
}

但这也会降低代码的可读性。为什么不重载 DoSomething(string a) ?或者可能完全重构该方法,因为它可以使用 anull 执行某些操作,并且仍然返回有效值。 null 不是有效值,因此包含 null 作为参数的操作结果不应返回有效值。

这就像在数学中使用无穷大一样。如果你用它加/减/乘或除某些东西,你总是会得到无穷大。

免责声明

这些是我自己的观点,绝不是“正确”的编程方式。但既然这个问题没有正确答案,我会实践我的言论自由权利:)

I would argue that this is not ok. Passing null around is never a good practice, and in my opinion whenever a value has null it should be an exception. You might not always have control over how your data is passed, and in those cases you should check for null just in case it could occur. However if you have the option to control the arguments yourself, you should rather overload the method, instead of passing in null.

Consider the following scenario:

public string DoSomething(string a, string b)
{
   // Returns something after a and b is processed.
}

In this example we're indicating that a and b are strings. They are objects of type char[] or however you would like to define a string.
Passing in a null in this method makes no sense at all, since we're expecting strings. A null is nothing - it's not an empty string - it's simply void.

The reason why I say that I don't think it's preferable to send in null into a method is because there are never any uses for null. It's simply a void left there as a placeholder for something that failed to instansiate. Therefore, calling the method above like this:

DoSomething("whatever", null) makes no sense at all.

We could argue that we could do something like this:

/// <summary>
/// Does something with string a or b
/// </summary>
/// <param name="a">The first string. If it's null, nothing is done with it</param>
/// <param name="b">The second string. If it's null, nothing is done with it</param>
/// <returns></returns>
public string DoSomething(string a, string b)
{
    // Returns something after a and b is processed.
}

But that also makes the code less readable. Why not make an overload DoSomething(string a) ? Or maybe refactor the method completely since it can do something with a and null and still return a valid value. null is not a valid value, so hence the result of an operation including null as an argument should not return a valid value.

It's like using infinity in maths. You will always get infinity as a result if you add/subtract/multiply or divide something with it.

Disclaimer

These are my own opinions, and by no means the 'right' way of programming. But since the question has no right answer, I'll practice my right to free speech :)

旧伤还要旧人安 2024-11-03 19:08:02

如果您不使用某些参数,可以使用 重载可选参数 在 C# 4.0 中

If you don't use some parameters you can use Overloading or Optional Parameters in C# 4.0

药祭#氼 2024-11-03 19:08:02

您是在说“可以将 null 作为参数传递给方法吗?”

如果是这样的话——是的——这是完全可以接受的。

然而,在.Net 4.0世界中,您可能需要考虑使用可选参数,这样您甚至不需要传入null,您可以省略它。

在 .Net 4.0 之前的世界中,如果将此 null 传递到方法中是常见情况,您可能需要创建一个根本不接受参数的重载。

Are you saying "is it ok to pass a null in as a parameter to a method?"

If so - yes - it is perfectly acceptable.

However, in the .Net 4.0 world, you may want to consider using optional parameters so that you don't even need to pass the null in, you can just omit it.

In the pre .Net 4.0 world, if it is a common scenario to pass this null into a method, you may want to create an overload that doesn't take the argument at all.

残月升风 2024-11-03 19:08:02

这是完全可以接受的。如果您使用的是 C# 4.0,还可以将参数设为可选,以便调用者不需要指定默认值。

That is perfectly acceptable. If you are using C# 4.0 you can also make the parameter optional so that the caller doesn't need to specify the default value.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文