49

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

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 < Length; index++) {
        this[index] += vector[index];
    }
    return this;
}
nhahtdh
  • 55,989
  • 15
  • 126
  • 162
jason
  • 236,483
  • 35
  • 423
  • 525
  • 1
    I don't think my opinion is worth putting in an answer; however, as C# doesn't define a convention, I think prepending the `_` to the method name is a great route. C# suggests private data members be prepended with the leading `_`. I think, therefore, if you are looking for consistency and ease of communication, there is precedent for the leading `_` – Thomas May 26 '16 at 13:18
  • The Framework Design Guidelines for .Net https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions states "DO NOT use underscores, hyphens, or any other nonalphanumeric characters." – Caltor Jul 09 '20 at 10:23
  • 2
    Answers are not accepted anymore, i don't undersand exactly why, since there is some microsoft guideline. Off course there is no need to use it, but Microsoft Guideline https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions leads to this https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md Rule 13 is very clear, and also you can see in the example that for a private method they use PascalCase. So if i where you, i would rename your _Add to AddImplementation or just AddImpl. – Juan Ignacio Avendaño Huergo May 17 '22 at 07:04
  • Why does this private method need to even exist? Why not just put the code inside the private method inside the public method and call that instead from the static method? – SacredGeometry Jul 23 '22 at 12:51

13 Answers13

44

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 *Impl. I.e. AddImpl in your case.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
  • In addition, most IDE's have auto suggest that filter out private methods or hide them. – kevindaub Dec 20 '08 at 23:16
  • 4
    Also, if you change a method from public to private or vice versa, you really don't want to have to change the name of the method, and you shouldn't need to – Bazman Dec 20 '08 at 23:46
  • 17
    You're missing the point... He CANT name it "Add" since it would be a dupe. He's looking for an industry best practice for this situation. – TheSoftwareJedi Dec 21 '08 at 00:26
  • Rethinking his code. It seems like he is poorly structuring it there is no reason for the private method to even exist. – SacredGeometry Jul 23 '22 at 12:50
  • Understanding at a glance if something is private can help understanding of where to find the method in the code when scrollling. This question is tagged with C#. `*` has never been a private method convention in C#, nor has Pascal Case. For C#, prefixing with `_` and using camelCase is a widely recognised convention - see here - https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions#camel-case – Chris Halcrow Mar 27 '23 at 00:28
  • @ChrisHalcrow We are talking about *methods*. And contrary to your assertion `_` and camelCase has never been a C# convention for methods, on the contrary (it may even create a warning in some toolchains, e.g. [IDE1006](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/style-rules/naming-rules#rule-id-ide1006-naming-rule-violation)). PascalCase *is*. And so is the use of `*Impl`, though potentially not as widespread. – Konrad Rudolph Mar 27 '23 at 07:23
  • "I don't see the benefit". Public methods should leave the object in the correct (valid) state, whereas private methods may not necessarily have to do so. For me, this distinction is crucial. Therefore, whenever possible, I use camelCase for private methods in C#. – romanoza May 08 '23 at 13:43
  • @romanoza I remain unconvinced that this distinction needs to be reflected in the method name: this is information that only the method itself should need; and, if you need a reminder, it's sufficient to look at the method header, which will tell you whether it's public or private via a handy keyword directly next to its name. — And if you have a private method that leaves your object in an inconsistent state I sincerely hope that you have better ways of signalling this to the caller than via naming subtletly. – Konrad Rudolph May 08 '23 at 14:52
34

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

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

public Vector Add(Vector vector) {
    for (int index = 0; index < Length; index++) {
        this[index] += vector[index];
    }
    return this;
}
Andy May
  • 4,030
  • 5
  • 34
  • 33
  • 1
    Do you know if there are any standard convention which specifies pascal casing for private methods? – Ciaran Gallagher Jan 06 '16 at 13:26
  • 2
    @CiaranGallagher Strictly speaking the example given is camelCase rather than PascalCase. Out of the box Visual Studio isn't terribly keen on camelCase method names and will give you warning IDE1006 but this can be configured. – Caltor Jul 09 '20 at 10:14
31

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

TheSoftwareJedi
  • 34,421
  • 21
  • 109
  • 151
  • MS has an [InnerAdd](http://msdn.microsoft.com/en-us/library/hh860431(v=pandp.51).aspx) method as well. – nawfal May 28 '13 at 12:21
  • 3
    The Pascal casing is more common but I prefer the use of camel casing for private methods because it tells you (as you read it in code) that the method isn't part of the class surface area (public properties, methods, events). – SynBiotik Jun 27 '18 at 19:52
  • 1
    As i explain in my comment for the question, this is the most correct answer following the Microsoft Guidelines. – Juan Ignacio Avendaño Huergo May 17 '22 at 07:05
15

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

These are my naming conventions for C#:

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

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, QueryEnumerable<T>, QueryDataReader, etc. then all of these wants to call the same private methods, I have a tendency to call this method InternalQuery or PrivateQuery.

Dmitry Gonchar
  • 1,642
  • 2
  • 16
  • 27
Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
7

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

private Vector AddUnchecked(Vector vector) {
    for (int index = 0; index < Length; index++) {
        this[index] += vector[index];
    }
    return this;
}
EricSchaefer
  • 25,272
  • 21
  • 67
  • 103
7

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

private Vector DoAdd(Vector vector) { ... }

and

private Vector AddImpl(Vector vector) { ... }

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!

Bevan
  • 43,618
  • 10
  • 81
  • 133
  • I also shudder. But please note that my question was for a convention in a situation where there is a private method doing the work behind some public methods. Hence "[i]s there a convention for naming the private method that I have called "_Add" here?" and the sample code presented. – jason Dec 22 '08 at 04:15
3

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

cgreeno
  • 31,943
  • 7
  • 66
  • 87
3

Public methods:

public void Add()
{
}
this.Add()

Private methods:

private void _Add()
{
}
_Add();

Properties:

public int Id {get;set;}
this.Id = 10;

Fields:

private bool _isUsed;
_isUsed = false;

Local variables:

bool isUsed;
Y.Yanavichus
  • 2,387
  • 1
  • 21
  • 34
2

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:

public Vector Add(Vector vector) {
    // check vector for null, and compare Length to vector.Length
    for (int index = 0; index < 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);
}

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

PEZ
  • 16,821
  • 7
  • 45
  • 66
1

EPiServer uses a convention of "...Internal" as in AddInternal() in this situation.

1

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

private Vector AddCore(Vector vector)

or

private Vector DoAdd(Vector vector)

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

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++) {
        this[index] += vector[index];
    }
    return this;
}

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

Greg Dean
  • 29,221
  • 14
  • 67
  • 78
0

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.

Paul
  • 3,125
  • 2
  • 24
  • 21
  • Those people are naming private fields incorrectly according to the [.NET General Naming Conventions](https://msdn.microsoft.com/en-us/library/ms229045(v=vs.110).aspx) which strictly prohibits the use of Hungarian Notation – Breakskater Apr 15 '15 at 20:19
0

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.

MusiGenesis
  • 74,184
  • 40
  • 190
  • 334
  • Note however, that the Microsoft guidelines do not cover private methods or fields https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members#names-of-fields. Also "Members are ultimately the means by which framework functionality is exposed to the end users of a framework." https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/member Private methods and fields aren't exposed to the user and therefore not members in MS terminology and not covered by their style guide. If a team is fine with an underscore prefix, that's a valid team-internal choice. – blubberdiblub May 02 '21 at 19:36