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
I'm creating this constant on a web service :
private const int SiteId = 4;
I understand that it should be Pascal Notation but resharper suggest me to use the D in capital, so the word ID is all uppercase like this :
private const int SiteID = 4;
What's the proper naming convention for this particular case ?
NOTE: Found lot of answers already on SO but none have the word ID on their examples.
As Cam said, it's a matter of preference.
I prefer "Id" simply because it's an abbreviation not an acronym. You wouldn't write Site IDentification, so why write SiteID?
Perhaps this convention stems from the fact that it is usually spoken "site eye dee" as opposed to "site idd".
http://msdn.microsoft.com/en-us/library/vstudio/ms229043(v=vs.100).aspx
The two abbreviations that can be used in identifiers are ID and OK. In Pascal-cased
identifiers they should appear as Id, and Ok.
It's really personal preference. Personally, I like my constants to be all caps.
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 9 months ago.
Improve this question
I have to store in database
[Column 1], [Column 2-start datetime]
Version1_1, 01-01-2011
Version1_2, 01-01-2011
Version1_3, 01-01-2011
…
I have a class with two fields: the version name and the datetime (+id).
The version name represents the first column. It can be an enum or a static class with constants.
Regarding almost any scenario I understand enums are better. But then, The DB will store integers in the first column instead of string values. Which gives me a feeling of uncertainty.
Are the enums still the best option in this scenario? I don't see disadvantages in lacking clean string values in [Column 1] in database.
If you store the values as integers in the database, you have several advantages:
Less storage space required
Easier querying without taking string comparisons into account
Better query performance because integer comparisons are much faster than string comparisons
A disadvantage on the database side is of course the reduced readability, but considering the advantages, I'd prefer integers in the database.
On the C# side, enums let you have the best of both worlds: integers inside and at the same time text identifiers when working with the values.
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.
Improve this question
In Blazor when I have a private field / property in the code that will be used in the diplay / razor page, should it have a naming convention of camelcase (e.g. someVariable) or should I have an underscore with camel case (e.g. _anotherVariable).
E.g. in code
private string someVariable {get; set;}
private string _anotherVariable {get; set;}
in razor
I've found documentation for both styles - just looking for what's considered 'best' in the community of Blazor.
Other questions I have - should the variables be marked 'private' or 'protected' and do they need to be properties with the {get; set;} or should I only do this for public properties??
Thanks in advance for helping me straighten this out.
The style of the naming convention is up to your preference.
There isn't a style guide for Blazor.
Look at
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions
Refer to the style guide for ASP.NET in case you want to follow the best practice from Microsoft.
Private is a good choice for variables visibility in case you work on the same page with #code.
Protected is more useful in case of derived classes.
The variables doesn't need to be declared as properties with getter and setter.
You HAVE to use getter and setter for parameters, cascading parameters and injected classes in code behind.
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 3 years ago.
Improve this question
With conventional I mean i.e. what the standards or most used versions are.
The int i are well known, and in many cases string str or the even shorter string s, as a generic naming of variables. What are the conventional naming schemes for the remaining C# built-in types?
bool
byte
sbyte
char
decimal
double
float
int
uint
long
ulong
object
short
ushort
string
Edit:
As many people here won't answer without a background reasoning; the reason for not naming these into length, name, age etc. is because it lays in a library class to provide functionality to many projects where all the variables can be assigned to different things based on the use case.
Compare this to the new List<int>().Add(int i); (I know it's written as T item), but here I need to use multiple types in the same method, and item1, item2, item3 etc. won't make the cut.
Appart from for loops where i,j,k are admitted, I would strongly advise not to use short names. Variable are understood by the compiler whatever name you choose. However humans need a precise meaning to understand and work with your code.
Take a look at:
int i;
bool b;
versus:
int weight;
bool isAdult;
Doest it make any difference?
If you plan on following a standard convention, Follow the Microsoft Naming Convention Here, otherwise, you may stick to whatever convention you/your team is familiar/comfortable with.
As for the abbreviation :
DO NOT use abbreviations or contractions as part of identifier
names.
For example, use GetWindow rather than GetWin
Basically its better to:
consider using names based on a parameter/field’s meaning rather
than it’s type.
Here is the general Naming Convention which explains everything you need.
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
I have seen that the majority of well-known developers (such as those in Lynda, Pluralsight, etc. or even writers) nowadays prefer the following approach over the latter one:
private IField _Field;
publc MyClass (IField Field){
_Field = Field;
}
Over this approach:
private IField Field;
public MyClass(IField Field){
this.Field = Field;
}
I know that there must be a reason behind this, but I can't figure out why.
Since this trend has began by the time C# 6 was released, I guess the reason might be due to something relating to Roslyn compiler but could not find anything over Google.
I'd appreciate if anyone could elaborate what advantages the first approach may possibly have over the second one.
It is just one naming convention - a lot of people coming from C and C++ backgrounds are used to this convention, as it makes it very clear that a field is a field, which is not as easily visible in those languages (given the IDEs that existed when they were invented).
With C# and particularly Visual Studio giving one a lot of help with idenifying members and their scope, this is less needed.
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 7 years ago.
Improve this question
According to ReferenceSource, the Version class is sealed, ICloneable, IComparable, IComparable<Version>, IEquatable<Version>. It also only stores int values. Is there a particular reason why the .NET programmers chose to make this a class instead of a struct? Why would someone need a null version?
Here's the field declaration block from ReferenceSource:
// AssemblyName depends on the order staying the same
private int _Major;
private int _Minor;
private int _Build = -1;
private int _Revision = -1;
They even make a comment, saying they need to keep the fields aligned. Maybe it's just me, but this is really a struct thing?
Why would someone need a null version?
To specify that no version is specified, for instance in AssemblyName as referred to in the comment in your question. An AssemblyName may omit the version when passed to Assembly.Load, for instance, in which case its Version property will be null. Remember that these types were created for .NET 1.0, which didn't have generics, so Nullable<Version> didn't exist yet as an alternative.