It sounds like OP's issue isn't that auto exists or that people write code using it, it's that the documentation uses auto, which makes it hard to figure out the types of things when you look them up.
My problem with auto is that Visual Studio loses all ability to predict code when you use it. So when I do Type object and then do object. I get all the methods/members available for that Type. But if I use auto, VS is either can't recommend anything or recommends the wrong set of methods entirely. It really slows me down as a programmer and I hate using it for that reason.
Auto is useful to reduce the amount of typing and DRY principle. Your arguments are meaningless when you can hover the mouse on the "auto" keyword and have Visual Studio/Eclipse tell you its type.
I do not consider the API of a reasonably complex construct "obvious". That is often where IDEs shine for me - in java or any other language that can gather that info for me. It's scenarios where I don't have to go to cppreference.com, because the IDE is going to give me what I want directly.
I used to really be anal on making every single line explicit: no shortcuts. But over time, especially with increasing my usage of templates, I've come to relax on these things and prefer to put my efforts in good variable names and trusting the compiler.
I'm not saying you should use auto for basic types (especially ones that can be easily cast into each other - that shit gets dangerous). I am saying that auto is extremely powerful when working with most interesting APIs. The most recent example I have is a lot of things I end up doing with chrono.
It has some additional. Because so much code is generated on the fly during compilation, and because of frequent use of auto, IDEs have a hard time understanding the syntax to provide proper autocompletion :(
Code generation usually doesn’t get you any support from standard tooling. My autocomplete can see through macros, but it has no idea what C is if I was working with Perl.
I get that, but I meant how often does it introduce bugs in the situation the OP mentioned, using it for "a language or framework you don't usually use", where I won't know if it looks right or not because I'm unfamiliar. Are they going back to fix the code often?
Personally, I don't even rely on normal autocomplete very much when I code because I feel like if I don't know what I'm trying to call, then I don't know the language or library well enough, and it's best to go look at the documentation.
The syntax was one of the main reasons I chose AutoIt. For some reason I cannot stand the AHK syntax. For me personally it is hard to bring structure to an AHK code.
I guess you can code without auto-complete but that would mean having to check the documentation at every step instead of having it auto-completed on the go. Depends what people prefer, for me it's a step back.
It's not just about type errors. (Good) autocomplete and documentation are only available when types are either explicitly labeled or correctly inferred. It's important that I be able to 1. type in just the first few letters of a method name and press <tab> to complete it, and 2. hover over a method's name and get docs for the method. Both of these are only reliable if the type of the caller is known.
Not GP, but I have a linter that runs on commit, and generally it doesn’t catch anything because I’ve learned not to make the mistakes.
I have never liked autocomplete. If I know the type or method I’m looking for (which is most of the time) then typing its name is not a hardship, and takes really no more time than finding it in a list.
If I don’t know the type/method, most of the time I have the documentation up in another window or monitor, and I’m going to want to read that in depth anyway, since I’m not familiar with the type/method, so autocomplete wouldn’t save me any meaningful time.
reply