I haven't heard of a single C# developer that does not code in an environment that won't do refactorings for them. That's not a point.
As for making code unclear, I still disagree: having the type explicitly there is much better for readability. Calling methods from other libraries, as well as the same project, obviously sometimes results in the methods returning something. You have two options: figure out what the method returns, or write what the method returns once and then forget about it.
Migrations of third party libraries are also easier with explicit types. In case a type changes across versions (e.g. gets renamed), you can see the type's former name basically instantly, since it'll be highlighted as an error - it doesn't exist anymore. From then, using source control, you can see when and to what it was renamed. Same goes for properties, methods, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I haven't heard of a single C# developer that does not code in an environment that won't do refactorings for them. That's not a point.
As for making code unclear, I still disagree: having the type explicitly there is much better for readability. Calling methods from other libraries, as well as the same project, obviously sometimes results in the methods returning something. You have two options: figure out what the method returns, or write what the method returns once and then forget about it.
Migrations of third party libraries are also easier with explicit types. In case a type changes across versions (e.g. gets renamed), you can see the type's former name basically instantly, since it'll be highlighted as an error - it doesn't exist anymore. From then, using source control, you can see when and to what it was renamed. Same goes for properties, methods, etc.