Join Reynald Adolphe for an in-depth discussion in this video Class naming conventions and standards, part of C# Best Practices for Developers.
- [Instructor] So let's talk about some class naming conventions and standards. Now earlier we created an active class and there's a few things that I want to talk about as I go through the code. The first thing is that often times you will be using pascal casing which means that the first letter of the word is capital, and then subsequent words might be capitalized however camel case is when the first letter of the word is smaller case.
So for get occupation, camel case it would be like this. Our methods are normally pascal case, just like classes. The other thing to point out is that when you're naming classes you always want to use a meaningful name. So I'm working with actors, it only makes logical sense that I have actor or maybe a word like talent. However using something a little bit more vague like performer, then it becomes a little bit more convoluted and you don't want to be convoluted when you're naming your classes.
Now classes by default when you create them tend to be private, in other words you might not have the word public there. Even though it doesn't say private, it is if public is not there. So a quick demonstration if I went ahead and created a class called actress you'll notice that public is not there, I had to add that. Now we'll go ahead and get rid of this because we don't need it for now.
In general when you're writing your code you always want to use private by default. So when you're writing methods always have them private unless you know that you're actually going to need them somewhere else. Now in this case I had get occupation as public because if this was private and we tried to build our solution, we'll have an error.
And that's because from our test file it no longer sees it. So we definitely know that it needs to be public. If I try to navigate to it, Visual Studio lets me but I know that I need to change it. Now another thing that's important to do in classes is to add xml documentation. And you do that by adding the three bars and automatically if you're at the top of the method, Visual Studio will put in the stub that you can then populate.
So here I can type in something like will return title and what's cool with the xml documentation here is that it works with IntelliSense. So if we were to go to our actor class and hover over get occupation, you see that it says will return title. So it is a good practice to include that. In my career many developers don't, they usually just use the regular comments which is just with the two slashes like this.
But that does not work with IntelliSense, and it's just a comment that can be useful for the developer themselves. So when I hover over it you don't see that comment. And in fact regular comments like that really should not even be necessary if you name your methods effectively, like get occupation, it says what it needs to do. So there's really need for me to have just a general comment, it becomes very useful and powerful when there's lots of information that you want to put down maybe including the parameters for the method, and then when you're using IntelliSense you can gather that information that becomes useful, knowing what parameters need to be passed through.
And again, that would look just like this. You can put in the parameter information right over here where it has returns. Something that I like to do in respect to commenting is looking at what's built in, the framework itself. So like if I go to definition for assert, and then I uncollapse this I can see how Microsoft has decided to lay out their information. There's a summary section, parameters, and they break it down to expected actual and message.
And it's nice and clear, so this is just a reminder of how nice it could actually look when some thought is put into the organization of the comments.
- Naming and handling classes
- Running a unit test
- Using constructors
- Naming and handling methods, fields, and properties
- Using properties correctly
- Managing objects efficiently
- Common design patterns as best practices