Considering IDE and text editor features when choosing a coding style

Question

Recently, I had a debate with one of my friends on using type inference in C# (var keyword). His argument was that we should stick to using the explicit type names because "even with the meaningful variable names, explicit type names enhance readability of the code".

I do agree that it enhances readability but any modern IDE (like Visual Studio and Rider in this case) comes with type hints which show the type names of the type inferred variables which makes no difference between using explicit type names and implicitly typed variables from reader's point of view unless he is using something like Notepad or hardcopies of the code.

But his counterargument was that we should not depend on IDE/Text editor features when choosing a coding style because "We code for the humans to read, so we should not depend on one or two "tools we are using" when deciding our coding styles and conventions."

Is his point correct? I do not have a problem between choosing implicit or explicit typing or maintaining consistency of our coding practices, but not considering the "tools" we use when deciding the coding styles sounds too much.

Answer 1

"Type hints" are a very weak argument for "var", because they appear only when one places the mouse cursor over the var keyword. But when reading code, any professional developer processes whole lines and sections of code at once, without hovering the cursor from one var to another to find out the type (and remember it when the mouse is moved away). Hence I disagree with your idea that it makes no difference ... from reader's point of view - usage or non-usage of var has a significant influence on the readability, even in a powerful IDE like Visual Studio.

Does that mean one should not use var, like your friend suggested? Well, this debate has already taken place years ago, on this site and elsewhere. The gross consensus is, there are several cases where usage of the "var" keyword does not make the code less readable, and several cases where it can actually enhance readability (of course, wrong usage of var can also reduce readability, that is also true).

Look into older Q&A threads about this topic, like this one, or this similar Q&A about C++ and the auto keyword. None of the arguments in the accepted answers (and several other answers) mentions the IDE's capabilities as an argument for var. So if you are going to argue for usage of "var", there are way better arguments than the availability of type hints in the IDE.

Answer 2

They might have a point if your code is a whole bunch of:

var i = 1.0m

but:

var docs = docRepo.GetDocuments();

vs

IEnumerable<Document> docs = docRepo.GetDocuments();

Is questionable.

Also consider you are actually programming in notepad, do you want to type out your long class names without intellisense? or keep it short with var? What kind of mad max programming future where you can't trust the machines are we hedging against?

Answer 3

Coding style should reflect the actual usage by people on the team

If everyone on your team uses Visual Studio, then it makes sense to select a coding style that makes things easier for Visual Studio users and doesn't duplicate information which Visual Studio already provides.

Your team's practices are more diverse than you think they are

That said, your team probably does not always use Visual Studio exclusively, and even if you are right now, you probably will not be in the future.

Chances are, you are using some kind of web-based source control service like GitHub which handles pull requests through a web interface, and that web interface is not going to have all of Visual Studio's context. (While Visual Studio does have pull request functionality, I've found that context lookups often don't work when reviewing PRs because it loads the diffs as a "Miscellaneous File" and not part of the solution.) Even outside of PRs, there will be times when someone wants to look up how something is done without having their IDE open, and will use a web interface's source code browser for it if such is available.

Additionally, if you have CI/CD then the automated builds will sometimes produce build errors. The emails and other messages produced by such a system will be read in an email client, not in Visual Studio.

A good coding style should consider all of the tools and processes during which people might have to read your code. Unless your team is exceptionally invested in a particular tool, this usually means that the plain-text of your code should be as readable as possible, because that's only thing that every tool will have in common.

This does not mean you should not var

As mentioned by other answers, var often improves the readability of a piece of code. Using var is a statement that the type of a particular variable doesn't matter - and if your code is well architected (not tightly coupled, doesn't expose concretions you shouldn't be depending on, etc.), those statements of intent can be accurate.