2 ms·

If you are unaware, you can work with JSON objects in a strongly typed way using JSON attributes on POCOs e.g. https://www.newtonsoft.com/json/help/html/Serial

If you are unaware, you can work with JSON objects in a strongly typed way using JSON attributes on POCOs e.g. https://www.newtonsoft.com/json/help/html/SerializationAttributes.htm https://www.newtonsoft.com/json/help/html/SerializationAttri... I would avoid using dynamic (I believe underneath it is basically the same as the Dictionary<T, U> anyway, howeve r I don't really care to look it up). Also regarding var. It is best IMO to use var when evident i.e. If the var right hand side is obvious what the type is use var, if it isn't use the Type name. e.g. When you should use var (it is evident from the right hand side) var name = "Joe Bloggs"; vs when it isn't evident: var myVariables = _service.SomeMethod(); It allows the code to be better read without the IDE. However obviously it is up to you.

philliphaydon 6y ago
var myVariables = _service.SomeMethod(); Sure when you write non-obvious code `var` sucks. But: var product = service.FetchProduct(productId); If the type of var is not obvious to you then you have bigger problems to worry about.
- uk_programmer 6y ago
  https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions#language-guidelines https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... > Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important. > Do not use var when the type is not apparent from the right side of the assignment. > Do not rely on the variable name to specify the type of the variable. It might not be correct. Your example has me inferring the type from the method name which isn't dissimilar to what they are advising against here. TBH I should have known I would get a comment like this, where everyone lives in utopia and everything is always obvious to another person, nobody ever had a bad nights sleep or not feeling their best etc etc. There are plenty of times where it may not be obvious what the Type it is returning even with quite decent coding standards and in any event I think it helps readability and isn't a huge ask. You can get Resharper / Rider to do this as a project setting (Visual Studio can probably do this out of the box now) in your repo and then the IDE will just do it for you.
  - philliphaydon 6y ago
    MS recommends suffixing `Async`, and VS by default names fields with underscore but the C# naming suggests Pascal. So referencing MS docs is hardly justification.
    - uk_programmer 6y ago
      So? because you disagree with some parts of it, all of it is a bad idea? That is a poor argument. I've justified quite clearly why I think it is a good idea and in my original post I said quite clearly "It is upto you". It is trivial to turn on in the IDE and it improves readability outside of the IDE.

philliphaydon 6y ago

var myVariables = _service.SomeMethod(); Sure when you write non-obvious code `var` sucks. But: var product = service.FetchProduct(productId); If the type of var is not obvious to you then you have bigger problems to worry about.

uk_programmer 6y ago
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions#language-guidelines https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... > Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important. > Do not use var when the type is not apparent from the right side of the assignment. > Do not rely on the variable name to specify the type of the variable. It might not be correct. Your example has me inferring the type from the method name which isn't dissimilar to what they are advising against here. TBH I should have known I would get a comment like this, where everyone lives in utopia and everything is always obvious to another person, nobody ever had a bad nights sleep or not feeling their best etc etc. There are plenty of times where it may not be obvious what the Type it is returning even with quite decent coding standards and in any event I think it helps readability and isn't a huge ask. You can get Resharper / Rider to do this as a project setting (Visual Studio can probably do this out of the box now) in your repo and then the IDE will just do it for you.
- philliphaydon 6y ago
  MS recommends suffixing `Async`, and VS by default names fields with underscore but the C# naming suggests Pascal. So referencing MS docs is hardly justification.
  - uk_programmer 6y ago
    So? because you disagree with some parts of it, all of it is a bad idea? That is a poor argument. I've justified quite clearly why I think it is a good idea and in my original post I said quite clearly "It is upto you". It is trivial to turn on in the IDE and it improves readability outside of the IDE.