These are chat archives for dennisdoomen/CSharpGuidelines

27th
May 2015
Brendan Forster
@shiftkey
May 27 2015 06:08
:wave:
Dennis Doomen
@dennisdoomen
May 27 2015 06:09
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
Dennis Doomen
@dennisdoomen
May 27 2015 06:15
Welcome @shiftkey
Maher Jendoubi
@MaherJendoubi
May 27 2015 06:54
Hello
Maher Jendoubi
@MaherJendoubi
May 27 2015 06:59
I would like to discuss AV1520 about the using of var keyword since C# 3.0
Dennis Doomen
@dennisdoomen
May 27 2015 07:01
Go ahead
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:01
I use var when the type name is too long
Dennis Doomen
@dennisdoomen
May 27 2015 07:02
It's a heated topic at my current project as well.
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:02
ok
It is better to invest in the name of the variable when using var
Dennis Doomen
@dennisdoomen
May 27 2015 07:04
The primary reason for this guideline is to make sure that developers don't return too much from a method. The analogy is often to not return the entire truck if you only need a package.
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:05
I mean not only for the very obvious type
Dennis Doomen
@dennisdoomen
May 27 2015 07:06
I understand. Now imagine somebody is reviewing your code through Github. Will he or she be able to determine the type involved?
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:07
in the most of cases I would say yes
var retListPlanning = new ObservableCollection<PlanningArea>();
Dennis Doomen
@dennisdoomen
May 27 2015 07:07
I can't judge those cases from my side, but if that's indeed the truth, you're fine.
That's fine.
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:08
could you guess the type of retListPlanning?
Dennis Doomen
@dennisdoomen
May 27 2015 07:08
Obviously ;-)
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:08
ObservableCollection<PlanningArea> retListPlanning = new ObservableCollection<PlanningArea>();
which is the better :smile: ?
my point of view is to avoid coding like this: ObservableCollection<PlanningArea> x = new ObservableCollection<PlanningArea>();
Dennis Doomen
@dennisdoomen
May 27 2015 07:10
That's the purpose of AV1520 as well.
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:10
but I suggest to use var
and invest more in the naming type
aha
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:11
when you said obviously have you some examples for non obvious please?
Dennis Doomen
@dennisdoomen
May 27 2015 07:11
From the guideline: var myfoo = MyFactoryMethod.Create("arg");
Ivan Korneliuk
@vansha
May 27 2015 07:13
Hi, I almost always use var without a deep thinking on it. Although was against it early days on. Rationale - isn't it somehow correlated with Hungarian notation? Why it should be that important to understand exact type for the variable.
Dennis Doomen
@dennisdoomen
May 27 2015 07:13
@vansha I use it during code reviews to detect some developer exposing way too much from a method and causing unnecessary coupling between classes. When that developer uses var, it will be more difficult to spot.
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:15
@vansha if you like abstraction then var do the same thing with types
I would also say not use var x; (Back to Basics)
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:20
also I can't use var x = null;
Dennis Doomen
@dennisdoomen
May 27 2015 07:21
I still believe var should only be used if the type is obvious from the context.
Maher Jendoubi
@MaherJendoubi
May 27 2015 07:23
@dennisdoomen it makes sense for me I totally agree with you but I prefer to use var keyword as much I can :)
Ivan Korneliuk
@vansha
May 27 2015 07:24
@dennisdoomen Not sure I understand the point of exposing too much from a method. I mean how not using var protects that. Could you please give a simple example?
Dennis Doomen
@dennisdoomen
May 27 2015 07:32
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.
Ivan Korneliuk
@vansha
May 27 2015 07:43
Ah, I see. While I understand the concern, still believe that in many cases it would be obvious what sort of data is returned - whether it some primitive type or internal object.
Dennis Doomen
@dennisdoomen
May 27 2015 07:47
If you're looking at the code from inside Visual Studio...yes.... But what if you're reviewing a Pull Request on GitHub or BitBucket?
Ivan Korneliuk
@vansha
May 27 2015 08:03
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.
Dennis Doomen
@dennisdoomen
May 27 2015 08:39
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.