blocks|key|4849696|text|就像你说的，(几乎)从来不需要return+None。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4849697|但是您应该考虑到，使用显式的return+None，您的代码的意图要清晰得多。记住:一段代码也需要是人类可读的，而显式通常是有帮助的。|4849698|entityMap^0|F|B|0|E|B|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Like you said, <code>return None</code> is (almost) never needed.

But you should consider that the intention of your code is much clearer with an explicit <code>return None</code>. Remember: a piece of code also needs to be readable by human-beings, and being explicit usually helps.

blocks|key|1238666|text|为了解释别人所说的话，如果函数应该返回一个值，我就使用return+None。在Python中，所有函数都返回值，但我们编写的函数通常只返回None，因为它们的返回值被忽略了。在某些语言中，这些被称为过程。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1238667|因此，如果一个函数应该返回值，那么我要确保所有代码路径都有一个返回值，并且该返回值也有一个值，即使它是None。|1238668|如果一个函数“没有”返回值，也就是说，如果从来没有人使用它的返回值来调用它，那么结束时不返回也没问题，如果我需要提前返回，我会使用最简单的形式，return。|1238669|entityMap^0|R|B|0|0|20|6|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

To expound on what others have said, I use a <code>return None</code> if the function is supposed to return a value. In Python, all functions return a value, but often we write functions that only ever return None, because their return value is ignored. In some languages, these would be called procedures.

So if a function is supposed to return a value, then I make sure all code paths have a return, and that the return has a value, even if it is None.

If a function "doesn't" return a value, that is, if it is never called by someone using its return value, then it's ok to end without a return, and if I need to return early, I use the bare form, <code>return</code>.

blocks|key|1985556|text|是和否。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1985557|在最简单的情况下，可以跳过+"return+None“，因为它只在一个负的条件下返回None。|1985558|但是，如果有嵌套的条件计算和多个场景，其中一个函数可能返回None。我倾向于将它们包含在场景的可视化文档中。|offset|length|style|BOLD|1985559|编辑:基于下面的评论|1985560|1985561|返回或返回None|blockquote|1985562|1985563|1985564|我更喜欢"return+None“而不是"+return+"，因为它是显式的，后来，没有人会怀疑return是否意味着返回None，或者它是一个错误，因为缺少一些东西。|1985565|entityMap^0|0|0|1B|7|0|0|A|0|0|0|9|0|0|0|0|2C|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@$F|Y|G|Z|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@$F|11|G|12|H|I]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|14|8|@$F|15|G|16|H|I]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|19|8|@$F|1A|G|1B|H|I]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|U|$]]

Yes and No.

In the simplest case, it is ok to skip "return None" because it returns None in only single negative condition. 

But if there are nested condition evaluation and multiple scenarios where a function could return None. I tend to include them as visual documentation of the scenarios.

[Editing: Based on comment below]

<blockquote>
 return or return None 
</blockquote>

I prefer "return None" to bare "return" as It is explicit and later, no one will be in doubt if the return meant returning None or was it an error as something was missing.

blocks|key|1981177|text|是的，如果您没有从Python函数返回任何值，它将返回None。因此，是否显式返回None是一个风格上的决定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1981178|就我个人而言，为了清晰起见，我更喜欢总是返回值。|1981179|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Yes, if you do not return any value from a Python function, it returns None. So, whether to explicitly return None is a stylistic decision.

Personally, I prefer to always return a value for clarity.

blocks|key|1236170|text|我想得越多，我就越不认为你描述的案例显示出良好的实践。它迫使客户端进行区分，因此客户端代码几乎总是如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1236171|b+=+foo1(123)
if+b+is+not+None:
++++...|code-block|syntax|javascript|1236172|你甚至不能写：|1236173|if+b:
++++...|1236174|因为，如果Baz.__nonzero__被覆盖，b可能会计算为False，即使它不是None。最好有一个Null-Baz实例(也就是Null+Object)，例如：|offset|length|style|CODE|1236175|class+Baz(object):
++++def+some_method(self):
++++++++"""some+action:"""
++++++++...
++++...

class+BazNull(Baz):
++++def+some_method(self):
++++++++"""nothing+happens+here"""
++++...

Baz.Null+=+BazNull()

...

def+foo1(x):
++++if+some_condition:
++++++++return+Baz(x)
++++else:
++++++++return+Baz.Null

...

b+=+foo1(123)
b.some_method()|1236176|重点是:帮助客户(可能是你自己！)让Cyclomatic+Complexity保持在低水平。分支越少越好。|1236177|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Null_Object_pattern|1|http://en.wikipedia.org/wiki/Cyclomatic_complexity^0|0|0|0|0|5|F|1G|8|1U|B|0|0|0|I|L|1|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|18|8|@$M|19|N|1A|O|P]|$M|1B|N|1C|O|P]]|9|@$M|1D|N|1E|1|1F]]|A|$]]|$1|Q|3|R|5|D|7|1G|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1H|8|@]|9|@$M|1I|N|1J|1|1K]]|A|$]]|$1|U|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]|12|$5|X|Y|Z|A|$10|13]]]]

The more I think about it, the less I think the case you describe shows good practice. It forces the client to discriminate, so client code would almost always look like:

<pre><code>b = foo1(123)
if b is not None:
 ...
</code></pre>

You couldn't even write:

<pre><code>if b:
 ...
</code></pre>

since, if <code>Baz.__nonzero__</code> is overwritten, b could evaluate to False, even if it's not None. It would be better to have a <code>Null-Baz</code> instance (AKA <a href="http://en.wikipedia.org/wiki/Null_Object_pattern" rel="nofollow">Null Object</a>), e.g.:

<pre><code>class Baz(object):
 def some_method(self):
 """some action:"""
 ...
 ...

class BazNull(Baz):
 def some_method(self):
 """nothing happens here"""
 ...

Baz.Null = BazNull()

...

def foo1(x):
 if some_condition:
 return Baz(x)
 else:
 return Baz.Null

...

b = foo1(123)
b.some_method()
</code></pre>

The point is: help the client (who might be yourself!) to keep <a href="http://en.wikipedia.org/wiki/Cyclomatic_complexity" rel="nofollow">Cyclomatic Complexity</a> low. The fewer branches, the better.

blocks|key|1985663|text|def+foo1(x):
++++try:
++++++++return+Baz(x)
++++except:
++++++++raise+ValueError('Incorrect+value+fo+Bac')|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1985664|或|unstyled|1985665|def+foo3(x):
++++return+Baz(x)+if+<condition>+else+False|1985666|我不相信半定义函数，但这个错误在搜索类型的失败修剪中很有用。|1985667|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$B|C]]|$1|I|3|J|5|F|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|F|7|Q|8|@]|9|@]|A|$]]]|L|$]]

<pre><code>def foo1(x):
 try:
 return Baz(x)
 except:
 raise ValueError('Incorrect value fo Bac')
</code></pre>

or 

<pre><code>def foo3(x):
 return Baz(x) if &lt;condition&gt; else False
</code></pre>

I do not believe in half defined function, but this False can be usefull in search type failure pruning.

blocks|key|3438461|text|我不同意这里的许多答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3438462|显式比隐式更好，但有时在可读性方面，越少越好。|3438463|def+get_cat():
++++if+cat_is_alive():
++++++++return+Cat()
#+vs+++++

def+get_cat():
++++if+cat_is_alive():
++++++++return+Cat()
++++return+None|code-block|syntax|javascript|3438464|在这个特定的示例中，您有两行额外的行，它们实际上没有提供任何有益的信息，因为默认情况下所有函数都不返回任何信息。|3438465|此外，随着类型提示的使用，return+None的显性甚至消失得更多：|offset|length|style|CODE|3438466|def+get_cat()+->+Union[Cat,+None]:
++++if+cat_is_alive():
++++++++return+Cat()|3438467|在这里包含return+None是一种双重冗余:默认情况下返回None，并且在类型提示标记中显式地指明了它。|3438468|为了避免跟在return+None后面，他们绝对是毫无意义和丑陋的。|3438469|entityMap^0|0|0|0|0|D|B|0|0|5|B|0|6|B|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@$M|13|N|14|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|F|7|15|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|16|8|@$M|17|N|18|O|P]]|9|@]|A|$]]|$1|U|3|V|5|6|7|19|8|@$M|1A|N|1B|O|P]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|X|$]]

I disagree with a lot of the answers here. 
Explicit is better than implicit but sometimes less is more when it comes to readability. 

<pre><code>def get_cat():
 if cat_is_alive():
 return Cat()
# vs 

def get_cat():
 if cat_is_alive():
 return Cat()
 return None
</code></pre>

In this particular example you have 2 extra lines that really provide no beneficial information since all functions return None by default.

Additionally explicitness of <code>return None</code> disappears even more with the usage of type hints:

<pre><code>def get_cat() -&gt; Union[Cat, None]:
 if cat_is_alive():
 return Cat()
</code></pre>

Including <code>return None</code> here is a double redundancy: None is returned by default and it's indicated explicitly in the type hint markup. 

Imho avoid trailing <code>return None</code> they are absolutely pointless and ugly.

I wonder if it is bad manner to skip <code>return None</code>, when it is not needed.

Example:

<pre><code>def foo1(x):
 if [some condition]:
 return Baz(x)
 else:
 return None

def foo2(x):
 if [some condition]:
 return Baz(x)

bar1 = foo1(x)
bar2 = foo2(x)
</code></pre>

In both cases, when condition is false, function will return with <code>None</code>.

Is it ok to skip "return None"?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我想知道在不需要return None的时候跳过它是不是不好的方式。示例：def foo1(x):    if [some condition]:        return Baz(x)    else:        return Nonedef foo2(x):    if [some condition]:        return Baz(x)bar1 = foo1(x)bar2 = 

问跳过"return None“可以吗？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问跳过"return None“可以吗？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问跳过"return None“可以吗？
EN