Hacker News Reader

Comment by twodave | Hacker News Reader

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

View on HN

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.

> 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.

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.

These days `Something something = new();` is also allowed.

Why did they add this when we can already do:

    var x = new Foo()

C# should have fewer, better considered features imo.

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.

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.

Fair point! Although I wish they had found a way to add F# style global inference rather all these little tricks

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.

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.

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-g...

Also, C# 9.0 introduces target-typed new expressions:

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

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).

Reply on news.ycombinator.com