Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
My textbook (Visual C# How to Program, 6/e) states that fields in C# should use camelCase. This corresponds with examples given in Microsoft C# Guide:
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/fields
public class CalendarEntry
{
// private field
private DateTime date;
// ...
}
However the official Microsoft naming convention clearly states that fields should use PascalCase (although they didn't provide an example of private fields as they normaly should be):
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions
Identifier: Field,
Casing: Pascal,
Example:
class MessageQueue
{
public static readonly TimeSpan InfiniteTimeout;
}
public struct UInt32
{
public const Min = 0;
}
Sooo, how do I know what case to use to keep my coding style right according to MS coding conventions?
AFAIK there is no set in stone convention for c#... Yes, there is technically an "official" convention, but it's not followed 100% of the time, even in MS's own source code, and it's certainly not religiously followed by many programmers and/or companies.
With that in mind, my preferred convention, and the best I've seen so far, is the one set by default in ReSharper. I strongly suggest following this convention:
PascalCase for: Classes, Structs, Methods, Properties, public | internal | protected Fields (regardless of static | readonly | const) and private const Fields.
_underscorePrefixCamelCase for: private _fields (except when const).
camelCase for: local variables.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
This post was edited and submitted for review 1 year ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I've read the naming convention in https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions.
However, I couldn't find the answer for this example below:
public class A
{
private int _b;
// Should I use "_" + camel case to name this member:
private string _c => _b.ToString();
// Or should I use pascal case to name this member:
private string C => b.ToString();
}
Should the member _c or C be called "private property" with a getter method or "private calculated field"? why?
If we want to use a member private internally with an expression body(=>) similar to this example. What is the naming convention for it?
As a common usage style in C#, fields start with a lowercase letter, properties start with a capital letter. Generally, fields begin with the _ character. If the data member is a field, it would be more appropriate to call it _c, and if it's a property, it would be called C.
Properties show fields. Fields are privately defined within a class and must be accessed via the get and set properties. Properties provide a level of abstraction that allows you to modify fields without affecting the external path accessed by clients using your class.
In this example, you don't need to define a field or property if you want clients to always use the _b variable as a string:
public class A
{
private int _b;
public string GetBAsString()
{
return _b.ToString();
}
}
References
What is the difference between a field and a property?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to create private list, while making it public as readonly\unwriteable, unable to add\remove\insert cells\nodes to the list.
My current solution is:
public IEnumerable<DataToken> DataTokens {
get {
return from v in _datatokens select v;
}
}
private List<DataToken> _datatokens;
I know the property's name is fine, but what about the variable's name? I can't name it dataTokens because it's parameter's name's format. Currently I call it _datatokens that is really bad name.
Is there a better alternative? I couldn't find anything about it at msdn.
Since identifiers are case-sensitive in C#, there is nothing against datatokens as a variable name.
There is a guideline available on MSDN that would suggests it to be dataTokens (camel-cased).
By the way, you should use ReadOnlyCollection<T> as return type to make it read-only to the outside world, so I would suggest to split this one up in two properties with different access modifiers.
C# also supports auto-properties, so you can save yourself the trouble of solving this conundrum and simply declare your property thus;
public IEnumerable<DataToken> DataTokens { get; private set; }
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Recently I am working a server that transfers commands and data and in my global variables, I have a 100 constants that I use through out my program for communication protocols. Is there a way I can make a class of global variables and then access that class when needed?
One way would be to create a class and mark it as static:
public static class GlobalVariables
{
public static int GlobalInt;
public static float GlobalFloat;
}
You'll be able to access these anywhere in your program.
If you do not want anyone to be able to edit these values, you could mark them with the const keyword:
public const int GlobalInt = 15;
Create a static class and mark your fields with const keyword, it's implicitly static and you won't be able to overwrite them by accident.
In addition to the suggestions above, is there any chance that these "constants" might change in the future? The reason I ask is that you mentioned they were communication protocols. If its things like addresses, ports or anything else that might change, consider using the static class and on that class use a static constructor to read the values from the configuration or have the static properties of that class just refer to the configuration. You don't want a firewall change to force you to have to recompile your code.
If a value has no chance of changing, it should be a const.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is there a standard or accepted code style for whether public or private members / functions come first in a class?
I expected to find a lot on Google regarding this but have found nothing.
Take a look at this SO question. It has the StyleCop Rules Documentation's requirements.
Fairly well used standard.
ASIDE: There is a free plugin for C#. Makes following the rules much simpler when you know what you are doing wrong. It will tell you if you violate the rules and can be set to run during the build step.
There are ordering rules with StyleCop which are useful to follow as a point of standardisation.
No this is simply a matter of personal preferences. Just follow your company one if that applies.
As people are saying, the order generally doesn't matter. However, there is one important exception, and that's initializing static fields. You can initialize static fields based on the value of other static fields - it all ends up getting compiled into the static constructor, but in the order that it's written in the code.
For example:
class Program {
private static int j = 4;
private static int i = Program.j;
static void Main(string[] args) {
Console.WriteLine(Program.i); // 4
}
}
But:
class Program {
private static int i = Program.j;
private static int j = 4;
static void Main(string[] args) {
Console.WriteLine(Program.i); // 0
}
}
So keep this case in mind if you decide to re-shuffle your members around. To be totally safe, you can put the initializations in the static constructor, like:
class Program {
private static int i;
private static int j;
static Program() {
Program.j = 4;
Program.i = Program.j;
}
}
There are rules enforced by StyleCop that I have seen many people use as a standard.
Frankly, they make sense1, but I don't think it's the best way.
I think things should be grouped by functionality, not by type, or accessibility, or static, etc. I would argue that a scheme that is organized by functionality requires the least amount of navigation when trying to read or maintain a code base. Any other ordering scheme (or *rules) would leave you navigating all over the class as you try to work with it. A conceptual ordering that places things together that make sense will minimize that jumping around. It's about making it easier to understand and work with it. It's a practical perspective, rather than forming rules for the sake of having rules that can be enforced.
1: They make sense in that they are a rule, they appeal to the OCD among us, and they can be enforced by a machine, but who cares if the machine can enforce them? But code is not for the machine, it is for the humans. When I need to understand the code, I don't think to myself "if only I could first understand all the constant fields, and then all the fields, etc." I take a very different approach. I want to see the big picture first, and one thing that is going to assist with that is seeing the code organized by functionality.
Here is the Microsoft C# Coding Conventions (C# Programming Guide)
It makes no mention of ordering for public, protected or private functions or members in a class.
I know in my past experience that FxCop had "suggested" that I put my public functions before my private functions, but again not necessarily a standard.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
There are a few questions on this, but they all seemed to be targeting a specific part of the language;
What are the most common naming conventions in C#? - Asking specifically about getters/setters.
C# naming conventions for acronyms - Asking more specifically about short uppercase suffixes.
I'm just starting out in C# with a friend on a venture to create games for XBOX Live Arcade. I've developed a number of games using ActionScript 2 and 3 but want to start exploring more powerful languages and devices.
I want to ensure that I don't peeve people that I start working with (if I get to that) or even just people on here when I run into trouble and ask a question with seriously disturbing / "incorrect" naming of methods, etc.
I've found it confusing in the example code that I've seen because there seems to be from my current point of view some flaws. I doubt that a flawed naming convention would be used, so I realize that I'm just having trouble understanding.
As far as I can tell so far, there are these conventions:
public Type SomeMethod()
private Type SomeMethod() - no underscore or anything?
public static Type SomeMethod()
private static Type _SomeMethod() - this one just seems odd..
public Type someProperty - switching it up to camel casing for properties?
public static Type SomeProperty - and then going back to pascal casing for static..
In ActionScript 3, I have developed and strictly stick to these conventions:
private var _someVar
public var someVar
private function _someMethod()
public function someMethod()
public static var SomeStaticVar
public static function SomeStaticMethod()
public const SOME_CONSTANT
Is there a complete list of naming conventions with reasoning behind each so that I can get my head around them? The reversal of syntax (i.e. public Type method() instead of AS3's public function method():Type) is throwing me out enough at the moment that I know I need to keep an eye on how I'm naming things, otherwise I'll forget and develop bad habits, which I'd rather nail and avoid now.
The two main Capitalizations are called camelCase and PascalCase.
The basic rules (with lots of variations) are
Types use PascalCase
properties and methods always use PascalCase
public members (fields, consts) use PascalCase
local variables use camelCase
parameters use camelCase
And although the documentation states that "Internal and private fields are not covered by guidelines" there are some clear conventions:
private fields use camelCase
private fields that back a property prefix a _
There is the All-In-One Code Framework Coding Standards from Microsoft which contains a complete set of rules and guidelines. (also used to be available here)
This document describes the coding style guideline for native C++ and .NET (C# and VB.NET) programming used by the Microsoft All-In-One Code Framework project team.
There are a whole lot of naming conventions advocated by Microsoft for .Net programming. You can read about these here.
As a rule of thumb, use PascalCase for public property, method and type name.
For parameters and local variables, use camelCase.
For private fields, choose one: some use camelCase, other prefix _camelCase with an _.
A commonly seen convention is also to name constants with ALLCAPS.
C# prefers PascalCasing for classes, properties, and methods.
As far as I can tell so far, there are these conventions:
public Type SomeMethod() <-- yes
private Type SomeMethod() <-- correct, no underscore
public static Type SomeMethod() <-- correct
private static Type _SomeMethod() <-- this seems odd to me too. underscore should not be there
public Type someProperty <-- no, a public property should be PascalCased (SomeProperty)
public static Type SomeProperty - and then going back to pascal casing for static..
If you are using Visual Studio, or XNA Game Studio (which I think is a fork of Visual Studio), I highly recommend springing for a ReSharper license (from jetbrains software). They will tell you, in your code editor, how to conform to common C# conventions.
Addition:
You should use camelCasing for private fields and method arguments. For private fields, I usually prepend them _withAnUnderscore.