Develop Reference

Should I have a method name longer than its statement?

According to General Naming Conventions of .NET framework:
X DO NOT use abbreviations or contractions as part of identifier names.
For example, use GetWindow rather than GetWin.
X DO NOT use any acronyms that are not widely accepted, and even if they are, only when necessary.
I've once consider GetName can be used for my method, but I believe it's not so sematically meaningful.
In order not to deviate too far from the naming convention, I've tried to figure out widely accepted acronyms, but I just run out of ideas for the following method:
String GetExplicitInterfaceMemberImplementationName(MemberInfo info) {
return info.DeclaringType.Name+"."+info.Name;
}
For this case, it is, in fact, not really longer than the statement, but just the identical length; and Type.Delimiter should be used rather than ".". However, the naming problems so often bothers me.
So, what method name should I declare? And for the long-term solutions, what can I do?
For an additional question, is there an API out of the box does the same thing?
Edit 1:
Stop and think, such a good suggestion for me.
For the purpose of its statement, also for semantic and not breaking the naming conventions, I got an idea from [AddAttributeStoreCommand.TypeQualifiedName Property]; so I now declare it as:
public static String GetTypeQualifiedName(this MemberInfo info) {
return info.DeclaringType.Name+"."+info.Name;
}
Yet, a long-term solution hasn't come up ..
Edit 2:
I'm not sure whether it's a good practice to name like this ..
public static String GetTypeDotItsName(this MemberInfo info) {
return info.DeclaringType.Name+"."+info.Name;
}

Code Complete 2nd Edition has this to say about method name length:
Make names of routines as long as necessary
Research shows that the optimum average length for a variable name is 9 to 15 characters. Routines tend to be more complicated than variables, and good names for them tend to be longer. Michael Rees of the University of Southampton thinks that an average of 20 to 35 characters is a good nominal length (Rees 1982). An average length of 15 to 20 characters is probably more realistic, but clear names that happened to be longer would be fine.
Note the word average. If the method name is as clear as possible, and it's 50 characters, then whatever. It's fine.
However, the book does mention another thing a few paragraphs up:
If you have routines with side effects, you’ll have many long, silly names, The cure is not to use less-descriptive routine names; the cure is to program so that you cause things to happen directly rather than with side effects.
Of course, side effects aren't the issue here, but you can extend the idea. Ask yourself "Is this long, silly name popping up because I'm doing overly complicated stuff?" If you're sure that you need an ExplicitMemberInterfaceImplementationName, then fine, but it can at least be something to stop and think about.

1) Put in the information that is needed to make the purpose of the method clear. You can probably halve the length of your example name without any loss of understanding about what it fits.
2) guidelines are guidelines. Don't slavishly follow rules when they become counter productive. If using an abbreviation makes it easier to read and understand the code, use abbreviations. The main thing is to try to limit abbreviations to long names that are commonly used, and use intuitive and commonly used abbreviations for them, so that anyone reading your code can easily work out what they mean. For example, decl is a common abbreviation for declaration, and difficult to mistake for anything else.
3) sometimes you can avoid the need to abbreviate by using a synonym.
I think you could probably drop interface and member from your name without losing the meaning.
But perhaps the "explicit interface implementation name" is actually the "explicit name" - explicit has a well defined meaning, especially in the context if your class, and you can always add the fully watertight legal definition in your documentation comment. So: "GetExplicitName"

The Best way to create methods that receives parameter [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'd like to know wich way is the best one to create methods that receives a low ammount of parameters like 1 or 2.
First One: Passing an entity class object as parameter.
MyClass entity = new MyClass();
BDClass bd = new BDClass();
entity.Name = "Alan";
bd.InsertName(entity);
public void InsertName(MyClass entity)
{
///A simple Insert/Select
}
Second One: Even programming on OO, use variables as parameter, instead of the entity class.
BDClass bd = new BDClass();
string name = "Alan";
bd.InsertName(name);
public void InsertName(string name)
{
///A simple Insert/Select
}
I'd like to know wich one is the best considering performance and good practice of programming. Or it depends of the situation ? I Mean, I guess it's better to use entity class as parameter only when it's a big amount of class, and the variable with low quantity of parameter.
I know its nothing to do with codes itselves, but I just want to learn wich one is the Correctly way to programm

There's no big differences and a correct answer. Since you can write it in the 2nd form, and the method name is InsertName, I prefer the 2nd one.
Why? First, it needs only a name(string), otherwise only one parameter is not enough. Second, you can pass any name to it no matter it comes from MyClass or anywhere else.
If you really need to pass the MyClass object with a given type, it must be the case that you need more than just a name from it, where you can't replace with only passing a name string. And in that case, MyClass may be a dependency of BDClass.

It depends on situation which you are handling. If your about to add whole object of entity class and your method is written in some c# Library project and you want to use that method in other project where your collecting whole information about that object of Entity Than first method approach suits you... But at the end it is completely up to you what you want to do.

It depends.
If your method is processing an (data/domain) entity, is should not even be a class; but rather an interface - which you will feed it to the method my means of a IoC framework.
If it needs to frequently pass it to other code blocks, in form of another class; then perhaps it's easier to use an entity class, which will be mapped to the result type.
It it's a pure function which is just calculating something (and it's algorithm does not change and you do not use something like a Strategy Pattern) then you can use just named parameters.
These are not ALL possible situations. These are just (IMHO) good ways of performing this task.
And I always start with simple named arguments! Avoid premature optimization! Wait for patterns in your code to emerge.

Both are correct, when correctness is defined as valid in C#.
Depending on use, one may pick one pattern or the other. There is no cookie cutter approach, and you won't see any performance differences.
For instance, if you wanted to validate an existing object of type MyClass then you would expect a whole item. The same goes for passing in objects with lots of properties, or when the number of parameters needed will increase over time.

Will bad things happen to me if I name my arrays, collections, lists, enumerables, etc. just the plural of what they contain?

I have always thought it was "best practice" to be explicit in naming my collection variables. So, if I had a collection of Car objects, I would typically name a Car[] carArray and a List<Car> carList.
And then 99% of the time, I end up just doing something like...
foreach (Car car in carArray)
{
...
}
...and I'm thinking, I could have just called the array cars, and it wouldn't have made any difference.
And now that we have IEnumberable<T>, I'm actually faced with the question of whether I might consider writing something like carIEnumerable? or carEnumerable. So far, the answer has been "no".
My thinking here is that the type of collection often doesn't matter, and when it does, is still doesn't matter if the collection type is written into the variable name. I just had a case where I had to switch from an IEnumerable<Car> to a List<Car> because I needed "bracket access" to the items (e.g., carList[3]). In that case, the two collection types do not behave the same, but would naming the variable cars have been a problem here?
Not to add another layer of complexity to this question, what happens if I use var? E.g.,
var cars = GetCars();
I can certainly tell cars is some kind of collection. I can iterate it. If I'm using LINQ, I can use extension methods. More importantly, if I later change up the type of collection, there would be much less code to mess with. var would still be var and cars would still be cars. That seems very appealing to me, and I having trouble seeing much disadvantage.
So, just to make sure my question is clear: How do you name your collection variables and why? Is there a serious readability or clarity cost to just "pluralizing" the name of the item?

var car = cars.Where(c => c.Name == "Robin Reliant");
Readability wins.
Hence I go with pluralizing.
Kindness,
Dan

The problem with this kind of naming is that it concentrates too much on the actual implementation rather than the purpose of the property. Instead of CarArray, you could use OwnedCars, or whatever tells the user why that enumeration is there.
I think naming the loop variable "car" in a small foreach-loop is just fine.
If you write var cars = GetCars(), the compiler looks at the type on the right side of the assignment, in this case possibly IEnumerable<Car>, and gives cars that type. You can even see it in subsequent uses of the variable if you hover over it with your mouse.
If you change the type of a collection and don't have to change your code because you are using var, think about the fact that those different types of collections probably have something in common that enables you to perform the same operations on them.
Probably it's IEnumerable if you use them in foreach loops.
So you could just as well expose those collections as IEnumerable, so users of your class don't depend too much on a certain implementation.

I never liked the "put the type of the variable in its name" approach - I really think it interferes with the smooth reading of the source. I believe code should be read like a story, and so it makes perfect sense to me that a group of cars (and I don't care if its implemented as an array, a linked list, a heap, set or whatever) is named "Cars":
foreach (Car currentCar : ParkingLog.getCars()) {
stolenCars.add(currentCar);
}
fencer.cars = stolenCars;
Works for me.

I generally start by pluralizing (e.g. cars). Often you will also have a local variable in the singular form (e.g. car), sometimes it can be awkward to read the code with two very similar variable names in which case I will find a new name for one of the variables.
I almost never would use carArray, more likely allCars, or selectedCars or something appropriate.

Prefer cars to carArray, but cars probably isn't what you want either. Which cars?
allCars
redCars
brokenCars
carsWith3Axels
In all but a few cases (there are always those pesky exceptions) variable names like cars are not descriptive enough.

Personally I avoid using the type of the collection in the variable name whenever possible. It may look nice but it's an un-enforcable constraint that other developers will mess up over time. If the type of the variable is really important for a particular operation I would instead consider rewriting the code to be ...
Less concerned about the specific collection implementation
Make the code shorter / more concise to the point the type of the variable is unambiguous
Or in other words, I don't like Hungarian notation.

You certainly shouldn't add the type name as part of the variable name - pretty much for the reason you mentioned. Personally, if I had a collection of Car objects I'd just call the collection Cars - the plural conveys the fact there are more than one without revealing the type, which is unnecessary.

I've been naming my variables things that include the variable type, as part of learning. It's helpful for me to see carArray somewhere in the code as a reminder that it's the array. But your question brings up a very valid point in that if you change that later, you then have to chase down all those references and that can be a big nightmare. I am seeing the wisdom of naming variables according to Matthew Vines' answer, "allCars," "brokenCars." I think I will do that more often from here on out, as my coding improves.

Putting the collection type in the variable name is a problem when maintenance leads you to change the type. Using pluralization, or something generic like 'carColl' is simpler. It gets the point across without being something that a future change would need to affect.

I'm thinking, I could have just
called the array cars, and it wouldn't
have made any difference.
Nope, doesn't make a difference to the compiler, but using descriptive names helps with readability, maintainability, and reuse.
In Visual Studio, I can quickly find the data type. Therefore, I use complete descriptive names. Plurals are fine. If the plural seems awkward then I append Listing or whatever is needed to indicate the variable contains a "collection".
For example, carArray means nothing to me. Is car an abbreviation? What if you change the implementation of carArray into a IList or IEnumerable of Car objects? Does that mean you change the name of the variable, or leave the name as it is? Too much to think about. Yet, I would understand Cars, CarListing, CarList, CarsByModel, and so on.

I think using the plural makes perfect sense, and that's the method I generally use in my code. I've never found that having the data type as part of the variable name is all that helpful.

The difference between "cars" and "carArray" is the self documenting nature of the code. No need to figure out what type of collection you are using if it's built into the name. In a trivial program, it doesn't really matter, but in something more significant the time savings are important.

What's the best way to layout a C# class? [duplicate]

This question already has answers here:
Order of items in classes: Fields, Properties, Constructors, Methods
(16 answers)
Closed 9 years ago.
Is there a standard way of laying out a C# file? As in, Fields, then Properties, then Constructors, etc?
Here's what I normally do, but I'm wondering if there's a standard way?
Nested Classes or Enums
Fields
Properties
Events
Constructors
Public Methods
Private Methods
Do people group their fields together, or do they put them with the properties? Or do people not worry about an order? Visual Studio seems to make it so hard to do.
Edit: Moved other part about ReSharper here: Make Resharper respect your preference for code order.

I tend to use Microsoft StyleCop, which has a set order according to rule SA1201:
Cause An element within a C# code
file is out of order in relation to
the other elements in the code.
Rule Description A violation of this
rule occurs when the code elements
within a file do not follow a standard
ordering scheme.
To comply with this rule, elements at
the file root level or within a
namespace must be positioned in the
following order:
Extern Alias Directives
Using Directives
Namespaces
Delegates
Enums
Interfaces
Structs
Classes
Within a class, struct, or interface,
elements must be positioned in the
following order:
Fields
Constructors
Finalizers (Destructors)
Delegates
Events
Enums
Interfaces
Properties
Indexers
Methods
Structs
Classes
Complying with a standard ordering
scheme based on element type can
increase the readability and
maintainability of the file and
encourage code reuse.
When implementing an interface, it is
sometimes desirable to group all
members of the interface next to one
another. This will sometimes require
violating this rule, if the interface
contains elements of different types.
This problem can be solved through the
use of partial classes.
Add the partial attribute to the class, if the class is not already
partial.
Add a second partial class with the same name. It is possible to place
this in the same file, just below the
original class, or within a second
file.
Move the interface inheritance and all members of the interface
implementation to the second part of
the class.

I think there's no best way. There are two important things to consider when it comes to layout. The first most important thing is consistency. Pick an approach and make sure that the entire team agrees and applies the layout. Secondly, if your class gets big enough that you are searching for where those pesky properties live (or have to implement regions to make them easier to find), then your class is probably too large. Consider sniffing it, and refactoring based on what you smell.
To answer the reshaper question, check under Type Members Layout in Options (under the C# node). It's not simple, but it is possible to change the layout order.

I don't believe regions are necessarily a sign of bad code. But to determine that you will have to review what you have. As I've stated here this is how I regionize my code.
Enumerations
Declarations
Constructors
Methods
Event Handlers
Properties
But the main thing is keeping it consistent and purposeful.

I tend to clump private data and tend to clump related methods/properties in functional groups.
public class Whatever {
// private data here
int _someVal = kSomeConstant;
// constructor(s)
public Whatever() { }
#region FabulousTrick // sometimes regionize it
// fabulous trick code
private int SupportMethodOne() { }
private double SupportMethodTwo() { }
public void PerformFabulousTrick(Dog spot) {
int herrings = SupportMethodOne();
double pieces = SupportMethodTwo();
// etc
}
#endregion FabulousTrick
// etc
}

You can try Regionerate to help with this. I really like it and it's a Scott Hanselman pick.

As said, I don't think there is a best way as such. But some organisation does help you the programmer.
How often in a long project have you spent time going up and down one or more source files trying to find one of your functions.
So I make use of the #region a lot to in this sort of way -
region Events : All of the event references that this class uses (at least in this particular partial class).
region Controls : All functions that directly interact with controls on a form.
region MDI : set the mdi up
Then there will be some to do with functionality rather than interface,
region Regex searches
I sort of make it up as I go along, but using the same pattern I always use. I must say I have been told by some programmers picking up my work that it is easy to follow and others that its messy.
You can please half the people half the time and the other half a quarter of the time and the other quarter of the time you confuse everyone including yourself. I think Winston Chrchil said that.

Whatever makes your more productive. Some like private fields next to property accessors, some like fields together above the constructors. The biggest thing that can help is grouping "like," elements. I personally like bringing together private methods, private properties, etc.
Try some things out and again, whatever you feel makes you more productive and helps you keep your code maintained.

Each to their own, but I tend to follow the same order that the MSDN help follows.
I also don't like to nest classes or enums, instead create separate files for them, that also makes writing unit tests easier (since it's easy to find the associated test file when you need to add/fix/refactor a test).
IMHO the order isn't that important because VS makes it very easy to find all members (especially if you follow the one class/interface/enum per file approach), and Sandcastle will group them if you want to build docs, so I'd be more concerned about giving them meaningful names.

On top of keeping a consistent set of regions in your class files, I keep all components of a region in alphabetical order. I tend to have a bit of "visual memory" when it comes to reading code and it drives me crazy having to use the navigation dropdown to find code in a file because it's all over the place.

I use the following layout:
events
globals/class-wide fields
private/internal
properties
methods
public/protected
properties
methods
nested classes (although I try to avoid these whenever possible)
I also firmly believe in 1 code "thing" (class, interface, or enum) per file, with the file name the same as the "thing" name. Yes, it makes a larger project but it makes it infinately easier to find things.

Why is C# Case Sensitive? [closed]

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
What reasoning exists behind making C# case sensitive?
I'm considering switching from VB.NET to take advantage of some language features (CCR and yield), and understanding the reasoning behind this difference may make the transition easier.
[UPDATE]
Well I took the plunge three days ago. Learning C# hasn't been particularly hard, I could barely remember my C++ days in the late 90's though.
Is the Case Sensitivity annoying me? not as much as i'd thought... plus I am finding that it actually is advantageous. I'm actually really happy with the CCR as a asynchronous coordination programming model. If only I had more time on the current project i'd port the code base into C# to take full advantage. Wouldn't be fair to my client though.
Assessing my current project now and I'm seeing blocking threads EVERYWHERE! AHhhh!!!
[UPDATE]
Well i've been programming in C# for nearly a year now. I'm really enjoying the language, and I really REALLY hate crossing over to VB (especially when it is unavoidable!)
And the case sensitivity thing? not even an issue

C# is case sensistive because it takes after the C style languages which are all case sensitive. This is from memory here's an MSDN link which is not working for me right now I can't verify.
I would also like to point out that this is a very valid use case:
public class Child
{
private Person parent;
public Person Parent
{
get { return parent;}
}
}
Yes you can get around this using prefixes on your member variables but some people don't like to do that.

They were probably thinking "we don't want people using SoMeVaRiAbLe in one place and sOmEvArIaBlE in another.

Consider the variable names in the following pseudocode:
class Foo extends Object { ... }
...
foo = new Foo();
Having case sensitivity allows conventions which use case to separate class names and instances; such conventions are not at all uncommon in the development world.

I think the fact that case can convey information is a very good reason. For example, by convention, class names, public methods and properties start with an uppercase letter by convention. And conversely, fields and local variables start with a lowercase letter.
After using the language for years, I've come to really enjoy this, code is much easier to read when you can read information simply from the casing of the words.
And that's why people do this sometimes, and it can make sense:
Foo foo = new Foo();
I do that all the time, it's very useful. If you think about it in a more useful situation like this:
Image image = Image.LoadFrom(path);
It just makes sense sometimes to call the instance the same thing as the class name, and the only way to tell them apart is the casing. In C++ the case-sensitivity becomes even more useful, but that's another story. I can elaborate if you're interested.

I think that having case sensitive identifiers can make code more readable, through the use of naming conventions, well, and even without naming conventions, the consistency enforced by case sensitivity ensures you that the same entity is always written the same way.

C# inherits the case sensitivity from C and Java, which it tries to mimic to make it easier for developers to move to C#
There might have been some good reasons for making C case sensitive when it was created three decades ago, but there don't seem to be any records on why. Jeff Atwood wrote a good article advocating for that case sensitivity might no longer make sense.

Probably copied from C, C++, Java, etc. or may be kept the same on purpose so that its similar to what other langauges have.

It was just a matter of taste on the C# langauge designer team. I am willing to bet it was for comonality with other C family languages. It does however lead to some bad programming practices such as a private field and its associalted property differing only in the case of the first letter.
EDIT:
Why might this be cosidered bad.
class SomeClass
{
private int someField;
public int SomeField
{
get { return SomeField; }
// now we have recursion where its not wanted and its
// difficult for the eye to pick out and results in a
// StackOverflowException.
}
}
Prefixing private fields with an _ or an m might make it easier to spot. Its not a huge biggie and personally I sill do exactly what I have just said is bad (so sue me!).

Parsing is also a tiny bit easier for case-sensitive languages. As long as there's no good reason to choose the non-case-sensitive way, why bother?

You are looking at this in a very limited way - from your point of view. Language designers must take into account a whole other set of considerations: cultural reasons, compatibility with other languages, common coding practices etc
All modern languages use case-sensitivity: which ones don't?
As someone who used BASIC for a number of years I got very tired of developers using different cases for the same variable. This sort of thing is very tiresome to look at and encourages sloppy programming. If you can't be bothered to get the case right - what else can't you be bothered to do?

From
.NET Framework Developer's Guide
Capitalization Conventions, Case-Sensitivity:
The capitalization guidelines exist
solely to make identifiers easier to
read and recognize. Casing cannot be
used as a means of avoiding name
collisions between library elements.
Do not assume that all programming
languages are case-sensitive. They are
not. Names cannot differ by case
alone.

My best guess as to the why it is case sensitive would be because Unix is case sensitive. Dennis Ritchie, the father of C also co-wrote Unix, so it makes sense that the language he wrote would coincide with the environment available at that time. C# just inherited this from its ancestor. I think this was a good decision on Microsoft's part, being that windows paths are not case sensitive.

I assume you'd like to see code like:
SomeField=28;
someField++;
somefield++;
SOMEFIELD++;
compiled as if SomeField in any casing variation is the same variable.
Personally, I think it's a bad idea. It encourages laziness and/or carelessness. Why bother properly casing the thing when it doesn't matter anyway? Well, while we're at it, maybe the compiler should allow misspellings, like SoemField++?

Naming. Names are hard to come by and you don't want to have to create a new name when talking about something similar or have to use some notation to set them apart.
Such scenarios are properties for fields or arguments in the constructor that you are about to assign to fields.