In a book I been reading they use a capital letter for public methods and properties. I know there are some other conventions like you put "_" in front of private variables. For me I don't like that way and like this way better but just wondering about stuff in the method.
So
public void MyMethod()
{
}
public string MyProperty {get; set;
}
and for private
private void myMethod()
{
}
But how about in the method?
like
public void MyMethod()
{
string MyVariable = null;
// or
string myVairable = null;
}
Also how about if you have sort of a global variable like
public class Test
{
private string bob;
public Test()
{
bob = null;
}
}
so should it be lowercase(since it is private)? Also on a side note would it better just make it a property but instead of a public property just have it private.
Here are your code examples as they would be if they followed official Microsoft code style guidelines (enforced by StyleCop and FxCop)
public void MyMethod()
{
}
public string MyProperty { get; set; }
private void MyMethod()
{
}
public void MyMethod()
{
string myVariable = null;
}
public class Test
{
private string bob;
public Test()
{
this.bob = null;
}
}
Some highlights from the spec: all fields should be private and lower case (except if they're constant). All methods should be Capitalised, whatever the access. If you want to expose a field (i.e. make it public or protected), use a property (which should be capitalized if it's protected or public). If you have automatic getters and setters for properties (i.e. just get; and set;), they can be on one line, otherwise on separate lines (if there's more code). Always name fields starting with lower case a-z, not underscores. Braces should be on a new line. Always reference non-static members (i.e. properties, methods, fields) with this. to distinguish them from variables and to avoid ambiguity.
There's a huge list but these are the most relevant to your examples. Look at code.msdn.microsoft.com/sourceanalysis
And what you call 'global' in your question is in fact a 'field'. These should never be exposed (as I said above) because you're exposing your implementation when in fact your behaviour is all you should expose on the interface to a type. Properties allow you to specify an interface and, even if they're implemented as automatic properties now, you can change the getters and setters later without changing the interface.
I recommend the Microsoft Naming Guidelines:
http://msdn.microsoft.com/en-us/library/ms229002.aspx
Interestingly, they don't broach the subject of how to name the private attribute hidden behind a public property. I tend to prefix with an underscore.
In general, CamelCase, and lowercase the first letter if it's a parameter.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With