Exactly. Many people already use IDEs, or programs which provide auto-completion or hinting of the types a function accepts when writing out a function name - the type does not need to be explicitly written for the machine to identify the type of the function.
With good IDE support, writing types isn’t that much of a burden. Either write a function call first and use "assign return value to new variable", or use autocompletion where you only type the initials of a multi-word type name. Plus IDE refactoring actions when a parameter or return type needs to be changed.
To me, if you feel compelled to start putting type information in the variable names, function names, etc., what you're showing is that you really want a type system.
For code that is not yours, or code that you open a year later, I think it's easier to specify the type. Exactly as when you see something like "var x = some_function();" and you need to know the type.
If you don't have types you still might not know what to pass in. I mean if it says function( id, filePath, newStudent) is id a number or a string. Or say filePath perhaps you have a defined class for that instead of passing in a string. Sure you could write it as function( idNumber, filePathString, newStudentClass) but you're just reimplemting types as a naming scheme that isn't able to be checked compile time.
> With a good editor, this documentation is right at your fingertips. When you type a function's name, a call-tip will remind you of the expected arguments. If you've added type annotations, the types will be there, too.
Without type annotations, the types will be there too for a language with type inference. The editor just has to ask the language implementation "hey, what is the type for this function?" and show the result back to the programmer.
This is contrary to my experience. For instance if the types of function parameters aren't specified, the IDE won't have any way of knowing what the types of those parameters are and will therefore not be helpful with completions.
It depends on the situation. Using the 'auto' keyword makes things more generic. It can also save long type names from making expressions difficult to read. An IDE that can follow the auto to its actual type is also helpful.
If a type name is small then being explicit about the type name can be much more clear since it can save someone having to hunt down what type each function might return.
Do you think this would be less of a problem with editor/IDE support? Using colors, or other visuals, to infer and show the types while editing might overcome this desire.
One of the nice things about explicit types is that you can make sense of the code even when the person who wrote it wasn't the best at variable naming. I tend to distrust relying on convention.
That said, presumably one solution for such an issue is that have IDEs that can easily tell you what the type of an auto variable is.
But also, there’s nothing stopping the code from being much clearer about its intention than this weirdly contrived example (I have a lot of code and most the function names are pretty unique). And surely you want to search for ‘foo(‘ to find invocations.
Exactly. Many people already use IDEs, or programs which provide auto-completion or hinting of the types a function accepts when writing out a function name - the type does not need to be explicitly written for the machine to identify the type of the function.
reply