Which convention to follow between C# and DotNet ?

Pierre Stempin 6 Reputation points

Hello, I just noticed that some elements of the DotNet and the C# naming convention contradict each other, here for the static fields:

For DotNet (https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members)
It says: 'For example, do not use "g_" or "s_" to indicate static fields.'

But for C# (https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions)
It says strictly the inverted thing: 'When working with static fields that are private or internal, use the s_ prefix and for thread static use t_.'

So, I'm using Unity which use both DotNet and C#. Which naming convention should I follow?
How am I supposed to write my static fields? With a 's_' prefix or not?


An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.
10,629 questions
{count} vote

2 answers

Sort by: Most helpful
  1. Karen Payne MVP 35,386 Reputation points

    Ask ten developers their recommendation you will get at least 8 to ten opinions.

    My recommendation, using the following is to prepend a private variable with an underscore with the first letter lowercase. Static public and private methods camel case e.g. ReadProductsTask.

    Don’t care for s_ prefix or t_.

    In the end if this is for personal use, go with suites you best and when looking at a field for instance know by looking at the field know it’s scope. If working in a team or sharing say a GitHub repository there needs to be a unanimous agreement on how fields, properties, methods and delegates/events are named.

    1 person found this answer helpful.
    0 comments No comments

  2. alexzzzyawn 6 Reputation points

    There is a context around the .NET guidelines that seems to have slipped your attention:

    The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines, and public or protected instance fields are not allowed by the member design guidelines.

    On the other hand, the C# guidelines you mentioned are specifically for "static fields that are private or internal". So in this sense, I don't think there is any ambiguity that you should use the prefixes.

    1 person found this answer helpful.
    0 comments No comments