Minimizing usage of auto in sources

We already had a discussion about auto, but here is an example that excessive using auto degrades the readability of the code, rather than improves it https://github.com/urho3d/Urho3D/pull/2700. I suggest using auto only where it leads to notable code shortening (like map<int,list<string>>::iterator)

3 Likes

My two cents: as a beginner, auto makes it even harder to understand some parts of the code (like here, where although I could deduce that ResourceCache was the type of cache, I couldn’t deduce UIElement was the type of ui).

EDIT: Oh, looks like there’s actually an UI type and I was mixing it up with UIElement from the UI’s GetRoot(). Well, auto definitely didn’t help.

It’s the Marklar of marklar-oriented marklar.

2 Likes

I’m going to continue PR discussion here.

In fact, I do not see people with whom I can argue about this

This topic is kinda vague now: “let’s use auto less” is not really a rule.

If you disagree with current coding conventions regarding auto, please make explicit proposal how to change this section of coding conventions:

And let’s discuss it here. @Miegamicis writes code, so I think he would care?

But Eugene blocks my PR

I don’t. You block your own PR by not following Urho coding conventions enforced by CI.
I don’t understand how you can blame me for you breaking rules.
Of if you see yourself above coding conventions and you have the right to violate them however and whenever you wish, just say so.

CppCoreGuidelines advise the following:

ES.11: Use auto to avoid redundant repetition of type names

Reason
  • Simple repetition is tedious and error-prone.
  • When you use auto, the name of the declared entity is in a fixed position in the declaration, increasing readability.
  • In a function template declaration the return type can be a member type.
Example

Consider:

auto p = v.begin();   // vector<int>::iterator
auto h = t.future();
auto q = make_unique<int[]>(s);
auto f = [](int x) { return x + 10; };

In each case, we save writing a longish, hard-to-remember type that the compiler already knows but a programmer could get wrong.

Example
template<class T>
auto Container<T>::first() -> Iterator;   // Container<T>::Iterator
Exception

Avoid auto for initializer lists and in cases where you know exactly which type you want and where an initializer might require conversion.

Example
auto lst = { 1, 2, 3 };   // lst is an initializer list
auto x{1};   // x is an int (in C++17; initializer_list in C++11)
Note

When concepts become available, we can (and should) be more specific about the type we are deducing:

// ...
ForwardIterator p = algo(x, y, z);
Example (C++17)
auto [ quotient, remainder ] = div(123456, 73);   // break out the members of the div_t result
Enforcement

Flag redundant repetition of type names in a declaration.

The Urho3D coding conventions used to have a link to these guidelines, but it seems to have disappeared.

After all, you wrote these rules and they were not discussed enough.

I can’t break the rules that don’t work anyway. I opened the first file that came across and showed examples of this.

Rules changed. Nobody did a pass over old code to change it all. How is that of any issue? New code follows new rules. Old rewritten code follows new rules. I do not see a conflict honestly.

I see a conflict in the fact that Eugene wrote the rules that he doesn’t like by himself and left to another project. And we must adhere to these rules.

There was a poll with considerable majority voting for following c++ core guidelines, which i believe auto rules derive from. Coding Guidelines

There was a poll with considerable majority voting for following c++ core guidelines, which i believe auto rules derive from. Coding Guidelines

Just show me this vote and I’ll shut up. Personally, I did not participate in any voting.

1 Like


You also participated in the thread. When people abstain from voting they either have no opinion or do not care.

P.S. I do not like current style guidelines either by the way. Yet there is nothing else to do other than follow them.

Ok you’re right then I admit my mistake

What mistake?

The guidelines tell us to avoid auto in general, and provides examples of cases it should be applied to, exactly as you suggested in this thread’s OP.
Despite these guidelines being voted in, it seems the link to them was removed. [false]

I don’t quite follow wdym. Link to CppCG is still in Urho coding conventions, as it was since my thread years ago. Do you mean some other link?

Ah, I wasn’t looking at HEAD.

By the way, we voted for CppCoreGuidelines. But in rules refs to another resources. Wtf?

I don’t quite follow wdym (2). Can you quote what particular reference you are taking about?

CppCoreGuidelines is a fairly extensive document. I even doubt that those who voted for him have studied it entirely. Didn’t it contain rules for using auto? Why need refs here and here. By the way, I agree with the paragraph that you wrote in the rules and it does not contradict what I propose. But need to remove links to rules for which there was no vote.

EDIT: I would even replace this paragraph with one sentence. Use auto only if it shortens your code significantly.

1 Like