Join Reynald Adolphe for an in-depth discussion in this video Field and property naming conventions, part of C# Best Practices for Developers.
- [Instructor] So, I've mentioned quite a bit about classes so far. Right now, we are in our actor test class. Let's go to our actor class. The thing that I'd like you to keep in mind is essentially what the class is. As an experienced programmer, which I'm assuming that you are, we know that classes define a template that specifies the data and the processing for each entity in our application. It's possible we could have another class in this file here, but it only makes sense organizationally to just have one class.
Now, fields and variables in a class hold data for each object traded in that class, and fields in general should be private. You always want to have them protected. So, I'm returning the value Actor here, but I could have easily had a private field that's a string with jobTitle. The standard is to have fields as camel case.
And below here, I can have jobTitle equals Actor, and return this as a jobTitle. However, we always want to be able to have our field possibly be accessible to outsiders, and that's where properties come into play. So, I could have easily used a snippet like propfull, and that would have given me the setup so I can define my field.
Now, properties are pascal case. So, just keep in mind, fields should always be private, and in general, camel case, and to act as the field, we use the properties, and it's best practice to define a property for each field in a class that needs to be accessed, and it's why fields are sometimes called backing fields, because they provide the backing in memory storage for the data exposed by properties.
Now, below here for GetOccupation, we know that is our method, and it's the function that contains an operation, so when we're naming them, they should be verbs. It describes what is going on. So, never try to name a method a noun. It should be reflecting an action. And the case is camel. The only exception is for the parameters, which tend to be camel case. So, now, let's go ahead and run our test again, and make sure everything works as expected.
And it does. Let's go ahead and review some best practices. When we're working with classes, use pascal casing, and always remember to use a meaningful name. Do not get obscure, because that's just going to make it difficult for developers in the future that takes over your code, or just yourself. Consider using the XML document comments, because that works well with IntelliSense. Now, even though it's possible to have private fields and just use those, it's good practice to use properties so they can be accessible if needed outside of the class.
Now, some things not to do is to, avoid using prefixes or underscores and abbreviations when you're naming variables and classes. Your classes should have a well-defined purpose. It should be very apparent based on the name of the class. I also mentioned that there should be one class per code file. Don't have two or three, there's no reason for that, and it's not best practice. When you add properties, make sure that they are above your methods. Your properties should be at the beginning of the class file.
And the last thing to point out is to have your class file in a manageable size. Don't have them extremely huge. If your class file gets too big, consider reviewing the content of it and breaking them up. Most likely, it can be broken up.
- 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