blocks|key|932779|text|我通常看到并使用"AddCore“或"InnerAdd”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|932780|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I usually see and use either "AddCore" or "InnerAdd"

blocks|key|140577|text|我从来没有在C#中看到过区分公有方法和私有方法的编码约定。我不建议这样做，因为我看不到好处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|140578|如果方法名与公共方法冲突，则是时候变得更具描述性了；如果像您的示例一样，它包含公共方法的实际方法实现，一种惯例是将其称为*Impl。也就是说，在你的情况下是AddImpl。|offset|length|style|CODE|140579|entityMap^0|0|1O|5|26|7|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|I|$]]

I've never seen any coding convention in C# that distinguished between public and private methods. I don't suggest doing it, since I don't see the benefit.

If the method name conflicts with public methods, it’s time to become more descriptive; if, as in your case, it contains the actual method implementation for the public method, one convention is to call it <code>*Impl</code>. I.e. <code>AddImpl</code> in your case.

blocks|key|932765|text|我通常对私有方法使用thisCase，对公共方法使用ThatCase。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|932766|private+Vector+add(Vector+vector)+{
++++for+(int+index+=+0;+index+<+Length;+index%2B%2B)+{
++++++++this[index]+%2B=+vector[index];
++++}
++++return+this;
}

public+Vector+Add(Vector+vector)+{
++++for+(int+index+=+0;+index+<+Length;+index%2B%2B)+{
++++++++this[index]+%2B=+vector[index];
++++}
++++return+this;
}|code-block|syntax|javascript|932767|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I usually use thisCase for private methods and ThatCase for public methods.

<pre><code>private Vector add(Vector vector) {
 for (int index = 0; index &lt; Length; index++) {
 this[index] += vector[index];
 }
 return this;
}

public Vector Add(Vector vector) {
 for (int index = 0; index &lt; Length; index++) {
 this[index] += vector[index];
 }
 return this;
}
</code></pre>

blocks|key|3358463|text|就我个人而言，对于方法，无论可见性如何，我都有相同的命名约定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358464|以下是我对C#的命名约定：|3358465|属性命名空间，类型，方法，属性:+PascalCase|3358466|Local变量:+camelCase|unordered-list-item|3358467|
|3358468|Parameters+to方法:+camelCase|3358469|3358470|Private+：带下划线前缀的_PascalCase，如果支持属性的字段，则与仅带下划线前缀的属性同名|3358471|3358472|编辑：请注意，我为私有方法使用前缀名称而感到内疚。当我第一次读到你的问题时，我没有听懂。|offset|length|style|BOLD|3358473|例如，如果我有7种不同的方式通过我的DatabaseCommand类执行我的SQL语句，像QueryDataTable，QueryEnumerable，QueryEnumerable<T>，QueryDataReader等等，那么所有这些都想调用相同的私有方法，我倾向于将这个方法称为InternalQuery或PrivateQuery。|CODE|3358474|entityMap^0|0|0|0|0|0|0|0|0|0|0|2|0|24|I|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|16|8|@]|9|@]|A|$]]|$1|M|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|O|5|H|7|18|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1A|8|@$S|1B|T|1C|U|V]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1D|8|@$S|1E|T|1F|U|Y]]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|10|$]]

Personally, for methods, I have the same naming convention regardless of visibility.

These are my naming conventions for C#:

<ul>
<li>Namespaces, types,methods, properties: PascalCase</li>
<li>Local variables: camelCase</li>
<li>Parameters to methods: camelCase</li>
<li>Private fields: _PascalCase with underscore prefix, if backing field for property, then same name as property only with underscore prefix</li>
</ul>

Edit: Note, I am guilty of using prefix-names for private methods. I didn't catch that particular part of your question the first time I read it.

For instance, if I have 7 different ways to execute my SQL statement through my DatabaseCommand class, like QueryDataTable, QueryEnumerable, <code>QueryEnumerable&lt;T&gt;</code>, QueryDataReader, etc. then all of these wants to call the same private methods, I have a tendency to call this method InternalQuery or PrivateQuery.

blocks|key|4204364|text|因为公共的Add()会做一些检查，而私有的不会：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4204365|private+Vector+AddUnchecked(Vector+vector)+{
++++for+(int+index+=+0;+index+<+Length;+index%2B%2B)+{
++++++++this[index]+%2B=+vector[index];
++++}
++++return+this;
}|code-block|syntax|javascript|4204366|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Since the public Add() does some checks and the private doesn't:

<pre><code>private Vector AddUnchecked(Vector vector) {
 for (int index = 0; index &lt; Length; index++) {
 this[index] += vector[index];
 }
 return this;
}
</code></pre>

blocks|key|3358735|text|我看到的两个常用的变体是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358736|private+Vector+DoAdd(Vector+vector)+{+...+}|code-block|syntax|javascript|3358737|和|3358738|private+Vector+AddImpl(Vector+vector)+{+...+}|3358739|两者都不是特别令人满意，但它们是我所见过的。|3358740|我从来没有看到过所有私有方法都应该有前缀的约定--一想到它就让我不寒而栗！|3358741|与所有C%2B%2B开发人员打交道已经够糟糕的了，他们给每个成员加上前缀"_“--而我是作为一个曾经给每个成员加上"F”前缀的前Delphi开发人员发言的。我还在恢复中！|3358742|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

The two variations that I've seen commonly used are these:

<pre><code>private Vector DoAdd(Vector vector) { ... }
</code></pre>

and 

<pre><code>private Vector AddImpl(Vector vector) { ... }
</code></pre>

Neither one is particularly satisfactory, but they're what I've seen.

I've never seen a convention that ALL private methods should have a prefix - the mere thought of it makes me shudder! 

It's bad enough dealing with all the C++ developers who prefix every member in sight with "_" - and I'm speaking as a former Delphi developer who used to prefix every member with "F". I'm still recovering from that!

blocks|key|3358382|text|在私有属性中使用前导下划线是很常见的，但我从来没有在方法上这样做过|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358383|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It is quite common to use a leading underscore for private properties but I have never seen it done on methods

blocks|key|141136|text|公共方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|141137|public+void+Add()
{
}
this.Add()|code-block|syntax|javascript|141138|私有方法：|141139|private+void+_Add()
{
}
_Add();|141140|属性：|141141|public+int+Id+{get;set;}
this.Id+=+10;|141142|字段：|141143|private+bool+_isUsed;
_isUsed+=+false;|141144|局部变量：|141145|bool+isUsed;|141146|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

Public methods:

<pre><code>public void Add()
{
}
this.Add()
</code></pre>

Private methods:

<pre><code>private void _Add()
{
}
_Add();
</code></pre>

Properties:

<pre><code>public int Id {get;set;}
this.Id = 10;
</code></pre>

Fields:

<pre><code>private bool _isUsed;
_isUsed = false;
</code></pre>

Local variables:

<pre><code>bool isUsed;
</code></pre>

blocks|key|3358503|text|无论我的队友建议什么，我都会去做，并使其成为团队中的惯例。但在特殊情况下，看起来你可以避免它：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358504|public+Vector+Add(Vector+vector)+{
++++//+check+vector+for+null,+and+compare+Length+to+vector.Length
++++for+(int+index+=+0;+index+<+Length;+index%2B%2B)+{
++++++++this[index]+%2B=+vector[index];
++++}
++++return+this;
}

public+static+Vector+Add(Vector+vector1,+Vector+vector2)+{
++++//+check+parameters+for+null,+and+compare+Lengths
++++Vector+returnVector+=+vector1.Clone()
++++return+returnVector.Add(vector2);
}|code-block|syntax|javascript|3358505|或许我就是不该这么晚才上场...|3358506|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I'd go for whatever my teammates suggested and make it a convention in the team. But in the particular case it looks like you could avoid it:

<pre><code>public Vector Add(Vector vector) {
 // check vector for null, and compare Length to vector.Length
 for (int index = 0; index &lt; Length; index++) {
 this[index] += vector[index];
 }
 return this;
}

public static Vector Add(Vector vector1, Vector vector2) {
 // check parameters for null, and compare Lengths
 Vector returnVector = vector1.Clone()
 return returnVector.Add(vector2);
}
</code></pre>

Or maybe I just shouldn't be on SO this late...

blocks|key|3358324|text|我认为在大多数约定中，隐私方面有更多的自由。然而，我经常看到这样的情况：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358325|private+Vector+AddCore(Vector+vector)|code-block|syntax|javascript|3358326|或|3358327|private+Vector+DoAdd(Vector+vector)|3358328|然而，我可能会放弃私有的add方法，只使用一个：|3358329|public+static+Vector+Add(Vector+vector1,+Vector+vector2)+
{
++++//+check+if+vector1+is+null
++++Vector+returnVector+=+vector1.Clone()
++++return+returnVector.Add(vector2);
}

public+Vector+Add(Vector+vector)+
{
++++//+check+parameters+for+null,+and+compare+Lengths
++++for+(int+index+=+0;+index+<+Length;+index%2B%2B)+{
++++++++this[index]+%2B=+vector[index];
++++}
++++return+this;
}|3358330|还要将这些大括号放在正确的位置:-)|3358331|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I think with most conventions there is more freedom on private stuff. However I see this a lot:

<pre><code>private Vector AddCore(Vector vector)
</code></pre>

or

<pre><code>private Vector DoAdd(Vector vector)
</code></pre>

However I would probably drop the private add method and just have one:

<pre><code>public static Vector Add(Vector vector1, Vector vector2) 
{
 // check if vector1 is null
 Vector returnVector = vector1.Clone()
 return returnVector.Add(vector2);
}

public Vector Add(Vector vector) 
{
 // check parameters for null, and compare Lengths
 for (int index = 0; index &lt; Length; index++) {
 this[index] += vector[index];
 }
 return this;
}
</code></pre>

Also put those curly brackets in the right spot :-)

blocks|key|141162|text|在这种情况下，EPiServer和AddInternal()一样使用"...Internal“的约定。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|141163|entityMap^0|H|D|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

EPiServer uses a convention of "...Internal" as in <code>AddInternal()</code> in this situation.

blocks|key|3358414|text|使用方法名称进行描述性描述以创建能够解释其自身的代码，不应该有任何冲突，因为您不应该让两个方法做完全相同的事情，所以您应该没有理由需要一个字符来作为方法名称的前缀。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358415|有些人用"m_“作为私有字段的前缀，我还没有看到私有方法有类似的样式。|3358416|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|$]]

Be descriptive with the method names to create code that explains itself, there shouldn't be any collisions because you shouldn't have two methods doing exactly the same thing, so you should have no reason to need a character to prefix method names with.

Some people prefix private fields with "m_", I have not seen any similar styles for private methods.

blocks|key|4204344|text|不幸的是，我遇到过很多这样的约定，并且倾向于在窗体上的控件命名时使用前导下划线(例如，不仅仅是“txtFirstname”，而是"_txtFirstname“)。这似乎是一种奇怪的溢出效应，来自不再推荐的使用前导下划线命名私有变量的做法。或者，程序员就是喜欢使用下划线键，我想不出什么原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4204345|不要使用这种惯例，当你的同事坚持这样做时，挑战他在网上找到推荐这种做法的东西(任何东西)。|4204346|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|$]]

I've encountered this convention a lot, unfortunately, along with a tendency to name controls on a form with a leading underscore (e.g. "_txtFirstname" instead of just "txtFirstname"). It seems to be a weird bleedover effect from the no-longer-MS-recommended practice of naming private variables with a leading underscore. That, or programmers just love using the underscore key for no reason I can figure out.

Don't use this convention, and when your co-worker insists on it, challenge him to find something (anything) online that recommends this practice.

Is there a convention for naming the private method that I have called "<code>_Add</code>" here? I am not a fan of the leading underscore but it is what one of my teammates suggests.

<pre><code>public Vector Add(Vector vector) {
 // check vector for null, and compare Length to vector.Length
 return _Add(vector);
}

public static Vector Add(Vector vector1, Vector vector2) {
 // check parameters for null, and compare Lengths
 Vector returnVector = vector1.Clone()
 return returnVector._Add(vector2);
}

private Vector _Add(Vector vector) {
 for (int index = 0; index &lt; Length; index++) {
 this[index] += vector[index];
 }
 return this;
}
</code></pre>

Private method naming convention

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

对于我在这里称为"_Add“的私有方法，是否有命名约定？我不喜欢前面的下划线，但这是我的一个队友建议的。public Vector Add(Vector vector) {    // check vector for null, and compare Length to vector.Length    return _Add(vector);}public static Vector Add

问私有方法命名约定
EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问私有方法命名约定EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问私有方法命名约定
EN