blocks|key|1744298|text|不用谢。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1744299|首先，#regions更多地是一种将许多相关函数/成员分组到可折叠区域的方法。它们的目的不是将单个数千行函数构建为多个部分。(也就是说，如果您编写的单个方法太长，以至于您考虑用#region构造它，那么您可能正在做一些严重错误的事情。无论是不是区域，该代码都是不可维护的。句号。)|offset|length|style|CODE|1744300|然而，许多人争辩说，这并没有真正的帮助，你应该考虑重写那些实际上需要区域才能理解的类。此外，区域倾向于隐藏令人讨厌的代码。|1744301|entityMap^0|0|3|8|2G|7|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

Not at all.

First of all, <code>#regions</code> are more a way of grouping many related functions/members into collapsible regions. They are not intended to structure a single multi-thousand line function into parts. (That being said, if you write a single method that's so long that you consider structuring it with <code>#region</code>s then you're probably doing something seriously wrong. Regions or not, that code would be unmaintainable. Period.)

Many people argue however, that it doesn't really help and that you should consider rewriting classes that actually need regions to be understandable. Also, regions tend to hide nasty code.

blocks|key|435428|text|#region+/+#endregion是一种对属于同一类的代码部分进行逻辑分组的方法。就我个人而言，我倾向于对私有字段声明、属性、公共函数和私有函数进行分组。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|435429|有时我会使用这些关键字来对代码的某些部分进行分组，这些部分需要我经常关注和更新，例如，计算方法。|435430|entityMap^0|0|7|A|A|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

<code>#region</code> / <code>#endregion</code> is a way to logically group parts of the code belonging to the same class. Personally, I tend to group private field declarations, properties, public functions and private functions.

Sometimes I use those keywords to group some parts of the code which I need to look after and update often, for instance, calculation methods.

blocks|key|435450|text|如果一个类中有多个“逻辑代码组”，那么你的类就违反了单一责任原则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|435451|把它整理好，你就不再需要区域了。|435452|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|$]]

If you have more than one 'logical group of code' in a class, your class violates the single responsibility principle.

Sort that out and you no longer need regions.

blocks|key|435478|text|区域在理论上看起来很好，但根据我的经验，这是一个经常被滥用的功能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|435479|程序员喜欢井然有序；大多数人喜欢把东西整理到小盒子里。它们将杂乱的代码、字段、属性、构造函数、方法、公共方法、内部方法、私有方法、助手方法、常量、接口实现以及天知道的其他东西组合在一起。|435480|我唯一能想到的更让我恼火的是使用分部类来隐藏复杂性。|435481|无论如何，虽然过度使用区域通常是隐藏不应该存在的混乱的迹象，但我也看到好的代码被它们淹没了。我下载了一些由受人尊敬的程序员编写的开源项目。这些家伙正在写一些令人惊叹的代码，但是，哦，这是什么？|435482|一块地？一个字段区域！两个属性？一个属性区域！一个构造函数？一个构造函数区域！一个私有方法？私有方法区域！|435483|我可以继续说下去。|435484|直到今天，当我看到这一点时，我仍然感到震惊。在某些情况下，一个区域、一个空白行、另一个空白行和结束区域可能占用原始代码的5倍空间(5行有区域，1行没有)。它基本上是强迫症的一种形式；在编写软件的过程中，这些区域可能会吸引我们的有序意识，但在实践中，它们是无用的--纯粹的噪音。当我第一次开始编写c#时，我也是这样滥用它们的。但是后来我意识到我的代码是多么的嘈杂，每次我打开一个文件时按下ctrl-k+l就表明我做错了。|435485|当一个类实现了一个有很多属性的接口(例如，用于数据绑定)，或者甚至是一组用于实现某些相关功能的方法时，我可以理解它。这没有任何意义。|435486|我仍然时不时地使用区域，但是...我做了很多克制。|435487|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

Regions seem good in theory, but in my experience, it's a feature that is often abused. 

Programmers love order; most folk love tidying things away into little boxes. They group messy code, fields, properties, constructors, methods, public methods, internal methods, private methods, helper methods, constants, interface implementations and God knows what else. 

The only thing I can think of that irks me more is the use of partial classes to hide complexity.

Anyway, while over-use of regions is often a tell-tale sign of hiding a mess that shouldn't be there, I've also seen good code swamped by them. I've downloaded a few open source projects written by respected programmers. These fellows are writing some amazing code, but, oh, what's this?

One field? A field region!
Two properties? A property region!
One constructor? A constructor region!
One private method? A private method region!

I could go on.

To this very day, I am still astounded when I see this. In some cases, a region, a blank line, another blank line and the end region can take up 5x the space of the original code (5 lines with regions, 1 line without). It's basically a form of OCD; these regions may appeal to our sense of order during the act of writing software, but in practice they're useless -- pure noise. When I first started writing c# I abused them in this way, too. But then I realised how noisy my code was, and that hitting ctrl-k l every time I open a file is a sign that I was doing it wrong.

I can understand it when a class implements an interface that has a lot of properties (e.g. for databinding) or even a group of methods for implementing some related functionality, but for everything?. It makes no sense.

I still use regions now and then, but... I exercise a lot of restraint.

blocks|key|1744560|text|我所发现的唯一一种我觉得使用一个区域完全没问题的情况是在下面的代码中。一旦我把它弄对了，我就再也不想去看那些常量了。事实上，我每天都在使用这个类，我想在过去四年中我唯一一次解开这个区域是在我需要用Python重新实现它的时候。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1744561|我认为(希望，祈祷)这段代码的情况是一种边缘情况。基于VB3类型声明的COBOL常量，该类型声明定义由C%2B%2B函数返回的C#数据结构的布局。是的，我把这个移植到了Python上。我就是那么棒。我很想学习Haskell，这样我就可以用它重写我的Python代码，并着眼于有一天用OCaml重新实现我的Haskell代码。|1744562|++++#region+buffer_definition
++++/*
++++++++The+buffer+is+a+byte+array+that+is+passed+to+the+underlying+API.++The+VB+representation+of
++++++++the+buffer's+structure+(using+zero-based+arrays,+so+each+array+has+one+more+element+than
++++++++its+dimension)+is+this:

++++++++Public+Type+BUFFER_TYPE
++++++++++++Method+As+String+*+50
++++++++++++Status+As+Integer
++++++++++++Msg+As+String+*+200
++++++++++++DataLine+As+String+*+1200

++++++++++++Prop(49)+As+String+*+100

++++++++++++Fld(79)+As+String+*+20
++++++++++++Fmt(79)+As+String+*+50
++++++++++++Prompt(79)+As+String+*+20
++++++++++++ValIn(79)+As+String+*+80
++++++++++++ValOut(79)+As+String+*+80
++++++++End+Type

++++++++The+constants+defined+here+have+the+following+prefixes:
++++++++++++len+=+field+length
++++++++++++cnt+=+count+of+fields+in+an+array
++++++++++++ptr+=+starting+position+within+the+buffer
++++*/

++++//+data+element+lengths
++++private+const+int+len_method+=+50;
++++private+const+int+len_status+=+2;
++++private+const+int+len_msg+=+200;
++++private+const+int+len_dataLine+=+1200;

++++//+array+elements+require+both+count+and+length:
++++private+const+int+cnt_prop+=+50;
++++private+const+int+len_prop+=+100;

++++private+const+int+cnt_fld+=+80;
++++private+const+int+len_fld+=+20;
++++private+const+int+len_fmt+=+50;
++++private+const+int+len_prompt+=+20;
++++private+const+int+len_valIn+=+80;
++++private+const+int+len_valOut+=+80;

++++//+calculate+the+buffer+length
++++private+const+int+len_buffer+=
++++++++len_method
++++++++%2B+len_status
++++++++%2B+len_msg
++++++++%2B+len_dataLine
++++++++%2B+(cnt_prop+*+len_prop)
++++++++%2B+(cnt_fld+*+(len_fld+%2B+len_fmt+%2B+len_prompt+%2B+len_valIn+%2B+len_valOut));

++++//+calculate+the+pointers+to+the+start+of+each+field.++These+pointers+are+used
++++//+in+the+marshalling+methods+to+marshal+data+into+and+out+of+the+buffer.
++++private+const+int+PtrMethod+=+0;
++++private+const+int+PtrStatus+=+PtrMethod+%2B+len_method;
++++private+const+int+PtrMsg+=+PtrStatus+%2B+len_status;
++++private+const+int+PtrDataLine+=+PtrMsg+%2B+len_msg;
++++private+const+int+PtrProp+=+PtrDataLine+%2B+len_dataLine;
++++private+const+int+PtrFld+=+PtrProp+%2B+(cnt_prop+*+len_prop);
++++private+const+int+PtrFmt+=+PtrFld+%2B+(cnt_fld+*+len_fld);
++++private+const+int+PtrPrompt+=+PtrFmt+%2B+(cnt_fld+*+len_fmt);
++++private+const+int+PtrValIn+=+PtrPrompt+%2B+(cnt_fld+*+len_prompt);
++++private+const+int+PtrValOut+=+PtrValIn+%2B+(cnt_fld+*+len_valIn);

++++[MarshalAs(UnmanagedType.LPStr,+SizeConst+=+len_buffer)]
++++private+static+byte[]+buffer+=+new+byte[len_buffer];

++++#endregion|code-block|syntax|javascript|1744563|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

The only circumstance I've ever found where I felt using a region was totally okay is in the code below. Once I got it right, I never wanted to have to look at those constants again. Indeed, I use this class every day, and I think the only time I've uncollapsed this region in the last four years was when I needed to reimplement it in Python. 

I think (hope, pray) that the circumstances of this code are an edge case. C# constants based on a VB3 type declaration that defines how the COBOL data structure returned by a C++ function is laid out. Yeah, I ported this to Python. I'm that good. I'm tempted to learn Haskell just so that I can rewrite my Python code in it, with an eye towards one day reimplementing my Haskell code in OCaml.

<pre><code> #region buffer_definition
 /*
 The buffer is a byte array that is passed to the underlying API. The VB representation of
 the buffer's structure (using zero-based arrays, so each array has one more element than
 its dimension) is this:

 Public Type BUFFER_TYPE
 Method As String * 50
 Status As Integer
 Msg As String * 200
 DataLine As String * 1200

 Prop(49) As String * 100

 Fld(79) As String * 20
 Fmt(79) As String * 50
 Prompt(79) As String * 20
 ValIn(79) As String * 80
 ValOut(79) As String * 80
 End Type

 The constants defined here have the following prefixes:
 len = field length
 cnt = count of fields in an array
 ptr = starting position within the buffer
 */

 // data element lengths
 private const int len_method = 50;
 private const int len_status = 2;
 private const int len_msg = 200;
 private const int len_dataLine = 1200;

 // array elements require both count and length:
 private const int cnt_prop = 50;
 private const int len_prop = 100;

 private const int cnt_fld = 80;
 private const int len_fld = 20;
 private const int len_fmt = 50;
 private const int len_prompt = 20;
 private const int len_valIn = 80;
 private const int len_valOut = 80;

 // calculate the buffer length
 private const int len_buffer =
 len_method
 + len_status
 + len_msg
 + len_dataLine
 + (cnt_prop * len_prop)
 + (cnt_fld * (len_fld + len_fmt + len_prompt + len_valIn + len_valOut));

 // calculate the pointers to the start of each field. These pointers are used
 // in the marshalling methods to marshal data into and out of the buffer.
 private const int PtrMethod = 0;
 private const int PtrStatus = PtrMethod + len_method;
 private const int PtrMsg = PtrStatus + len_status;
 private const int PtrDataLine = PtrMsg + len_msg;
 private const int PtrProp = PtrDataLine + len_dataLine;
 private const int PtrFld = PtrProp + (cnt_prop * len_prop);
 private const int PtrFmt = PtrFld + (cnt_fld * len_fld);
 private const int PtrPrompt = PtrFmt + (cnt_fld * len_fmt);
 private const int PtrValIn = PtrPrompt + (cnt_fld * len_prompt);
 private const int PtrValOut = PtrValIn + (cnt_fld * len_valIn);

 [MarshalAs(UnmanagedType.LPStr, SizeConst = len_buffer)]
 private static byte[] buffer = new byte[len_buffer];

 #endregion
</code></pre>

blocks|key|337435|text|我认为函数应该只用于可重用的代码。这就是他们设计的目的。没有什么比看到为只调用一次的东西创建函数更让我恼火的了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337436|使用一个区域。|337437|如果你需要做500行，那么输入这500行。如果你想使用一个区域来整理它，如果有任何可重用的东西，那么就使用一个函数。|337438|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think that functions should only be used for reusable code. Thats what they were designed for. Nothing infurriates me more than seeing a function being created for something that is called only once. 

Use a region.

If you need to do 500 lines then type the 500 lines in. If you want to neaten it up use a region, if there is anything reusable then use a function.

How do you recommend using #region / #endregion? To what extent should that replace using sub functions to clarify your code?

#region/#endregion vs sub functions?

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

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

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

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

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

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

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

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

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

社区新版编辑器体验调研

您如何推荐使用#region / #endregion？这应该在多大程度上取代使用sub函数来澄清您的代码？

问#region/#endregion vs sub函数？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问#region/#endregion vs sub函数？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问#region/#endregion vs sub函数？
EN