I would like to advocate not using ‘auto’ in tutorial code examples. While convenient for the programmer, the learner would like to know the type. It gives a better idea of what the returned value contains, and facilitates class-reference lookup and such.
i think so too. auto is cool and all, but it just makes everything so unreadable. sometimes when i hover over some of these variables it doesn’t even show me what it is. also some older juce tutorials should be updated to follow the current juce standard. i always have to ask around because some weird stuff doesn’t work. doesn’t anyone (who has more knowledge than me) feel responsible for them or so?
Convenient for ‘the programmer’ yes.
Convenient for another programmer definitely not! It is also a maintenance nightmare.
I would think such a thing would be frowned upon though by typical JUCE developers.
Sorry, but I disagree. Even tutorials should use best-practices whenever possible, as not to teach beginners the “wrong” stuff.
auto is a very good thing. In 90% of the cases you shouldn’t even need to know the return value, as you just pass it on to another function etc.
In the few cases you actually need to know, modern IDEs can always tell you.
There is a reason why even VERY experienced developers preach the “Almost always auto” mantra:
10 Likes
for learning purposes it would be cool to directly see all return types. at least for all tutorials that are marked as “beginner”. then in the advanced stuff juce could be like: “ok now that you know how things work around here, check out how convenient auto is!”
1 Like
I’m also pro auto - to me it makes the code much more readable and makes reader focus more on variable names and semantics (by reference or by value) which I care more about than actual types - unless dealing with math and numbers.
P.S. if your IDE can’t show you the return type on hover you might want to switch to a good one. 
1 Like
Also, it’s important to mention that auto can’t exist without something you can ‘hover’ over and ‘go to definition’ on right next to it, and that expression should be what we focus on in terms of clarity.
For example in the Processing Audio Input tutorial:
auto* outBuffer = bufferToFill.buffer → getWritePointer (channel, bufferToFill.startSample);
Even if I was told in code this is a float* and not auto*. Does a float* reveal all I need to know about this code? Probably not… I’ll need to check what getWritePointer() does, otherwise I will not be able to use this pointer correctly.
1 Like
Even the beginners tutorials are aimed at Juce beginners, not C++ beginners. I think being proficient in C++ is a requirement to even start with Juce.
Juce is way too complex and some of its concepts too hard to understand for C++ beginners.
If auto is too much for you, then Juce will be way too hard for you too. Learn to walk before you run.
1 Like
For me personally, it is just an annoyance and the effort involved in switching to auto consistently is not worth any gains I can perceive. Worst case you end up with some mixed use, which is what we have in JUCE now.
Also agree with @rMidi, it makes the code harder to scan and see what is happening fast.
I’d prefer is people would just learn RUST and stop messing around with C++ and shoe horning in these features. It all comes off a bit like re-arranging the deck chairs on the Titanic.
2 Likes
I think the OP has a totally valid point, as often tutorial code (like code reviews) are not done in a sensible IDE, so you can’t lean on the IDE for hover over help with types.
I’m pretty certain thought that if the type is unclear, probably the best think you could do would be to name the variable and methods more descriptively to make the type ‘pop’ a bit better.
C++ isn’t proscriptive about such things, and there are arguments for and against various aspects of the language. If there was a clear winner, we’d all be doing it (and there are examples of this, such as the adoption of smart pointers) but for auto the patterns are still being found as we’re only 9 years into that particular experiment.
I like the idea of giving the class name in the variable name, e.g.,
auto complexBagClass = something.getComplexBagClass();
One can also specify units and other aspects of type in the name, e.g.,
auto integerSamplingRateInHz = somethingReturningThat();
In the worst case, a comment can be used:
auto bag = something.getBag(); // ComplexBagClass
It’s not reasonable to expect an IDE to be present, as tutorials are often read in HTML format, or PDF, etc., such as on a tablet. It’s learning time, not programming time. Also, not everyone adapts code in an IDE. Some of us use powerful old-school text editors.
3 Likes
Usually, the function should usually be clear enough about the type name, but a good variable name would also help.
Not to mention - usually even without an IDE you’re going to have to look at the getComplexBagClass() anyway - is it a plain getter? Is it returning a reference counted object like Image or ValueTree does? do I need to worry because it’s a copy and not a reference?
If it’s a plain float or int, sure - the type name is valuable because you know all about it. But a custom Type is not something that’s obvious anyway, you’re gonna have to look at what it is, even if you’re using text search+replace and not an IDE…
The type name itself here wouldn’t provide much info you won’t have to look at anyway.
Just last night I just came across a perfect example of where auto makes a lot of sense:
Updating my plugins to use double precision processBlock: all the code in my later plugins that used auto were easy to update, just refactored my original float processBlock as a template and create two versions of processBlock that call the templated original appropriately. With the very first plugin I created (where I was just getting back into C++ programming, having not really touched it since 1995) I had all manner of compiler errors where I had to change float* assignments into auto* assignments etc. etc. So it took about 10x longer to change that one than the others.
2 Likes
The main use for the type name is the ability to look it up on the spot (not in an IDE, but in a browser, say). I actually use the suffix P for pointers and R for references, so my variable names tell me what I need to know along that dimension as well.
1 Like
Yeah, I hear what you’re saying.
You can still look it up though. The right side of auto has (by definition) to be text searchable. And the result of that is really what you want - if it’s a getter for a custom type you can search for that one too, so nothing is ‘hidden’ from you by using that.
In fact - auto forces that since it can’t exist without the right side representing a valid expression.
So to me, even if it forces one more search on IDE-less people, it makes you focus on what the variable does and semantics, which as a reader I care more about usually, since I probably don’t know the types anyway. If you already know the types you probably know what the getters return…
Maybe the tutorials could have extra comments that explain the involved types behind auto?
This is a very common practice, and I think it is actually hazardous. During development, the type is often changed in a refactoring. So later one decides, that reference should be able to become nullptr, let me change it to a pointer, just to see if it works… oh it works, let me check that in and move on. The type has changed, but the name hasn’t. If one was to rely on the name, they are doomed. In a matter of seconds you left a trapdoor for future programmers or even yourself.
Even worse, if you convey if something is static in the name (or you rely in the absence of a hint that it is not)
The only rule to follow is: descriptive variable names. The second rule: the wider the scope, the more descriptive the variable name.
For tutorials I agree, adding comments for cases that are not obvious makes sense. But I didn’t find the juce tutorials lacking comments.
But then, I am not a beginner…
TL;DR: show best practices in tutorials and use auto.
2 Likes
I agree with the OP. I am not a fan of “auto”. Because it makes the code harder to read for me. And in Xcode, you cannot even hover over an “auto”, to see, what the type is.
And in Xcode, you cannot even hover over an “auto”, to see, what the type is.
I’ve been using XCode all this time without the autocomplete/suggestions working properly, always moving around to find how X thing is named. The other day I tried VSCode and man that’s night and day, giving all the info needed even the comments made on that variable. I can’t imagine how many time I’ve lost wondering on files and lines of code in Xcode.