5 ms·

Am I the only one bothered that many of these implementations of idioms are often not idiomatic according to the language? e.g. in C# the idiomatic way to insta

Am I the only one bothered that many of these implementations of idioms are often not idiomatic according to the language? e.g. in C# the idiomatic way to instantiate something is typically to use the var keyword (unless the type of its value can't be inferred). And the idiomatic way to format a string is to use the $ special character, not string.Format... I suspect other languages

gwbas1c 5y ago
C# has evolved quite a bit over 20ish years. I suspect those posts predate $. Also: some people really oppose "var." I don't understand why, especially when newer languages like Swift and Rust really encourage similar idioms. Something something = new Something () is usually a smell to me. I personally find "var" much easier to work with.
- wyldfire 5y ago
  > Something something = new Something () is usually a smell to me. var something = new Something() ... this one in C# is probably using type inference? Or maybe it doesn't matter in C# because it has a dynamic type anyways? Yes, Rust permits type inference but sometimes it can't infer it and you have to specify it. And sometimes it's clearer to be explicit about the type. C++ permits it too (auto) but depending on the team it can be pretty unpopular except for maybe verbose type names/iterator types, etc.
  - hvidgaard 5y ago
    The compiler can almost trivially get the type. As long as the type on the right side is resolved it's a single pass to resolve the type of the left side. Only rarely is the compiler unable to and you will get an error and have to provide it yourself.
- Thiez 5y ago
  These days `Something something = new();` is also allowed.
  - pharmakom 5y ago
    Why did they add this when we can already do: var x = new Foo() C# should have fewer, better considered features imo.
    - still_grokking 5y ago
      Maybe because people are still naming their identifiers "x" and such, and "new Foo()" could be some arbitrary expression? Or maybe just because C# is a TIMTOWTDI language? C# looks indeed quite baroque to me. But as I'm not doing any C# I don't know whether this is a good or a bad thing in practice. OTOHS I guess less complexity in a language is generally to be preferred compared to having more flexibility doing the same thing.
    - Thiez 5y ago
      I think it can be useful for initialising properties and fields, where you are not allowed to use `var` (for good reason, if you ask me). But of all the recent features it's the one that I would miss least if it were taken away.
      - pharmakom 5y ago
        Fair point! Although I wish they had found a way to add F# style global inference rather all these little tricks
        Thiez 5y ago
        I suspect type inference becomes pretty tricky in the presence of subtyping. I don't have any F# experience, but I have done some Haskell back in the days and I found the type inference very convenient. But I also think there is something to be said for limiting type inference to "inside" methods where it is effectively invisible to users of a class. Rust has made the same choice: you have type inference inside functions, but never outside.
- Joker_vD 5y ago
  And before C# got $-interpolation, almost every project had a static StringUtils class with an extension method FormatStr for string... seriously, I never quite understood the reasons why Format was made a static method instead of an instance method.
- snak 5y ago
  The problem is people abuse of "var", and use it everywhere even when the type is not obvious from the right-hand expression/assignment. This is especially bad when reading code outside of an IDE, like in a GitHub PR, git/cli tools, etc... From msdn/dotnet documentation: > The use of var helps simplify your code, but its use should be restricted to cases where it is required, or when it makes your code easier to read. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/implicitly-typed-local-variables https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... Also, C# 9.0 introduces target-typed new expressions: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-new https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- still_grokking 5y ago
  Most of the time I met people opposing type inference those people thought 'var' would be dynamic typing. I truly don't understand why this misconception is still so widespread. The argument that code becomes unreadable without an IDE is only true if identifiers aren't named properly (for example by heavy abuse of abbreviations, or even the usage of single-letter symbols). The only places where type-inference should be avoided are "public interface" kind of things. It's best practice to be explicit about an "interface"—even in languages with full type inference. This avoids changing an interface unnoticed only by changing an expression somewhere. (I don't mean here C#'s Interfaces verbatim, but for example signatures of "package public" methods and such).

gwbas1c 5y ago

C# has evolved quite a bit over 20ish years. I suspect those posts predate $. Also: some people really oppose "var." I don't understand why, especially when newer languages like Swift and Rust really encourage similar idioms. Something something = new Something () is usually a smell to me. I personally find "var" much easier to work with.

wyldfire 5y ago
> Something something = new Something () is usually a smell to me. var something = new Something() ... this one in C# is probably using type inference? Or maybe it doesn't matter in C# because it has a dynamic type anyways? Yes, Rust permits type inference but sometimes it can't infer it and you have to specify it. And sometimes it's clearer to be explicit about the type. C++ permits it too (auto) but depending on the team it can be pretty unpopular except for maybe verbose type names/iterator types, etc.
- hvidgaard 5y ago
  The compiler can almost trivially get the type. As long as the type on the right side is resolved it's a single pass to resolve the type of the left side. Only rarely is the compiler unable to and you will get an error and have to provide it yourself.
Thiez 5y ago
These days `Something something = new();` is also allowed.
- pharmakom 5y ago
  Why did they add this when we can already do: var x = new Foo() C# should have fewer, better considered features imo.
  - still_grokking 5y ago
    Maybe because people are still naming their identifiers "x" and such, and "new Foo()" could be some arbitrary expression? Or maybe just because C# is a TIMTOWTDI language? C# looks indeed quite baroque to me. But as I'm not doing any C# I don't know whether this is a good or a bad thing in practice. OTOHS I guess less complexity in a language is generally to be preferred compared to having more flexibility doing the same thing.
  - Thiez 5y ago
    I think it can be useful for initialising properties and fields, where you are not allowed to use `var` (for good reason, if you ask me). But of all the recent features it's the one that I would miss least if it were taken away.
    - pharmakom 5y ago
      Fair point! Although I wish they had found a way to add F# style global inference rather all these little tricks
      - Thiez 5y ago
        I suspect type inference becomes pretty tricky in the presence of subtyping. I don't have any F# experience, but I have done some Haskell back in the days and I found the type inference very convenient. But I also think there is something to be said for limiting type inference to "inside" methods where it is effectively invisible to users of a class. Rust has made the same choice: you have type inference inside functions, but never outside.
Joker_vD 5y ago
And before C# got $-interpolation, almost every project had a static StringUtils class with an extension method FormatStr for string... seriously, I never quite understood the reasons why Format was made a static method instead of an instance method.
snak 5y ago
The problem is people abuse of "var", and use it everywhere even when the type is not obvious from the right-hand expression/assignment. This is especially bad when reading code outside of an IDE, like in a GitHub PR, git/cli tools, etc... From msdn/dotnet documentation: > The use of var helps simplify your code, but its use should be restricted to cases where it is required, or when it makes your code easier to read. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/implicitly-typed-local-variables https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... Also, C# 9.0 introduces target-typed new expressions: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-new https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
still_grokking 5y ago
Most of the time I met people opposing type inference those people thought 'var' would be dynamic typing. I truly don't understand why this misconception is still so widespread. The argument that code becomes unreadable without an IDE is only true if identifiers aren't named properly (for example by heavy abuse of abbreviations, or even the usage of single-letter symbols). The only places where type-inference should be avoided are "public interface" kind of things. It's best practice to be explicit about an "interface"—even in languages with full type inference. This avoids changing an interface unnoticed only by changing an expression somewhere. (I don't mean here C#'s Interfaces verbatim, but for example signatures of "package public" methods and such).