A set of coding guidelines for all C# versions up to 7.3, design principles and layout rules for improving the overall quality of your code development.
Welcome to this discussion about the current state and the future of www.csharpcodingguidelines.com and it's source at https://github.com/dennisdoomen/csharpguidelines
For a nice introduction on the rationale and background of my initiative, consider reading https://github.com/dennisdoomen/csharpguidelines/blob/master/Guidelines/0001_Introduction.md
It is better to invest in the name of the variable when using var
var retListPlanning = new ObservableCollection<PlanningArea>();
That's fine.
which is the better :smile: ?
my point of view is to avoid coding like this: ObservableCollection<PlanningArea> x = new ObservableCollection<PlanningArea>();
and invest more in the naming type
aha
I would also say not use var x; (Back to Basics)
The point is that you wan to prevent too much coupling between classes. For instance, you have some kind of domain entity with a method to do ask some information about one of its internal objects. I've seen developers returning an entire internal object even though only a single primitive value was sufficient. Quite often they don't realize that this causes way too much coupling.
I understand that we're referring code reviews. And understand your point. Just saying that it seems like a rare case, when I can't understand type from a variable name and usage (for common examples that I can imagine):
var employees = repository.FindEmployees(criteria); // Don't really care about 'customers' type. Whether it IEnumerable<Person>, IList or List. Just know that it has a collection semantic.
var topSalary = employees.Select(var emp => emp.CalculateYearSalary()).Max(); // While I don't know exact type of 'topSalary' would be, it's not that important to me. I'm pretty sure it's primitive type like Integer or Double.
Depends on the context. In your first example, I might wanna know whether somebody is returning an internal domain entity rather than some kind of DTO construct. If it is the former, you end up with unnecessary class coupling and leaky abstractions. In the second example, the difference between an integer and a double isn't really relevant, but might be considered an serious issue in accounting.
Ehm, wait a minute, wouldn't you detect such inappropriate return type from the method definition? When it should return an int value it surely can't return a complex internal type. You only need to check the method definition once whereas you'd have to analyse and verify its usage many times. And should the return type be something as unspecific as object you'd have another reason to complain, right?