Return to Answer

It is true that code is being read and maintained more often than it is written.
But that's one more reason to use auto !

auto to accelerate change propagation

For the maintenance of code, auto has indeed often (not always) the advantage of facilitating abstraction and ease decoupling from the types. Take your example:

double totalCost=item1.quantity*item1.price+item2.quantity*item2.price+....

Imagine that you find out that finally double is not sufficiently precise for the price, and you'd need to go for long double to avoid unacceptable loss. You'd have to go carefully through your code, and for every double look if it's concerned by the change or not. With auto, you let the compiler automatically propagate that change and will have less risks of forgetting one occurence.

See online example here.

Of course, type inference has its limits, and sometimes the programmer really has to chose the right type (often with the need of explicit casting some operands already in the expression to really achieve the intended result - see counter example here). Make that the exception, not the rule.

auto to prevent accidental slicing

Type inference also avoids nasty slicing errors, for example when MySpecialisedClass subclass needs to be used instead of MyClass and one declaration was forgotten, e.g:

MySpecialisedClass xyz("some", more, arguments);
... // lots of code 
MyClass uvw = xyz; // still looks fine - but slicing occurs ! 

See online example here demonstrating the advantage of auto.

But what about reading ?

There are a lot of languages with no explicit types specified or type inference similar to auto:

• JavaScript: In my experience, native experienced JS devs rarely complain about unreadable due to missing type information. The main concern is when accidentally a variable causes a runtime error because of a wrong type. So it's more about type safety than readability.
• Python, which is strongly but dynamically typed: Python devs that I know, usually don't complain either about the lack of explicit type and type hinting aims at type safety rather than readability as explained in PEP484
• Many other modern languages promote type inference. For example Rust or Swift, to name only a few. Swift for exemple encourages type inference with let (like const auto) and var (like auto).

Why would the absence of explicit type be more difficult to read if it's C++ then ? My position is that it's because of habits, habits still prevent people to embrace modern C++ and its benefits.

Why not giving a try? Modern IDEs perfectly do the trick in getting used to it. Example with XCode:

It is true that code is being read and maintained more often than it is written.
But that's one more reason to use auto !

auto to accelerate change propagation

For the maintenance of code, auto has indeed often (not always) the advantage of facilitating abstraction and ease decoupling from the types. Take your example:

double totalCost=item1.quantity*item1.price+item2.quantity*item2.price+....

Imagine that you find out that finally double is not sufficiently precise for the price, and you'd need to go for long double to avoid unacceptable loss. You'd have to go carefully through your code, and for every double look if it's concerned by the change or not. With auto, you let the compiler automatically propagate that change and will have less risks of forgetting one occurence.

See online example here.

Of course, type inference has its limits, and sometimes the programmer really has to chose the right type (often with the need of explicit casting some operands already in the expression to really achieve the intended result - see counter example here). Make that the exception, not the rule.

auto to prevent accidental slicing

Type inference also avoids nasty slicing errors, for example when MySpecialisedClass subclass needs to be used instead of MyClass and one declaration was forgotten, e.g:

MySpecialisedClass xyz("some", more, arguments);
... // lots of code 
MyClass uvw = xyz; // still looks fine - but slicing occurs ! 

See online example here demonstrating the advantage of auto.

But what about reading ?

There are a lot of languages with no explicit types specified or type inference similar to auto:

• JavaScript: In my experience, native experienced JS devs rarely complain about unreadable due to missing type information. The main concern is when accidentally a variable causes a runtime error because of a wrong type. So it's more about type safety than readability.
• Python, which is strongly but dynamically typed: Python devs that I know, usually don't complain either about the lack of explicit type and type hinting aims at type safety rather than readability as explained in PEP484
• Many other modern languages promote type inference. For example Rust or Swift, to name only a few. Swift for exemple encourages type inference with let (like const auto) and var (like auto).

Why would the absence of explicit type be more difficult to read if it's C++ then ? My position is that it's because of habits, habits still prevent people to embrace modern C++ and its benefits.

Why not giving a try? Modern IDEs and editors perfectly do the trick in getting used to it. Example with Visual Studio Code, when hovering over an auto declared identified:

It is true that the code is being read and maintained more often than it is written. But that's at lest one more reason to use auto !

auto as maintenance accelerator - change propagation

Imagine that you find out that finally double is not sufficiently precise for the price, and you' need to go for long double to avoid unacceptable loss. You'd have to go carefully through your code, and for every double look if it's concerned by the change or not. With auto, you let the compiler automatically propagate that change and will have lest risks of forgetting one occurence.

auto as maintenance accelerator - slice protection

Type inference also avoids nasty slicing errors, when you want to use MySpecialisedClass subclass instead of MyClass and forget to adapt one declarator:

MyClass xyz("some", arguments);
... // lots of code 
MyClass uvw = xyz; // looks fine

But after refactoring:

See online example here.

But what with reading ?

There are a lot of languages out there with no types specified:

• Take also JavaScript. In my experience, JS devs do rarely complain that their code is not readable due to missing type information. The main concern is when accidentally a variable causes a runtime error because of the wrong type. So the complain is more about type safety than readability. (Of course, I exclude here fellows who come from strongly explicitly typed languages and who still have to get used to it)
• Take Python, which is strongly but dynamically typed. Python coders I know usually not complain that their code is difficult to read because the type is not shown explicitly.
• Moreover type inference is adopted by many modern languages, like Rust or Swift, to name only a few. Swift for exemple encourages type inference and auto-like constructs with let and var.

Moreover, modern IDEs perfectly do the trick in getting used to it. Example with XCode:

It is true that code is being read and maintained more often than it is written.
But that's one more reason to use auto !

auto to accelerate change propagation

Imagine that you find out that finally double is not sufficiently precise for the price, and you'd need to go for long double to avoid unacceptable loss. You'd have to go carefully through your code, and for every double look if it's concerned by the change or not. With auto, you let the compiler automatically propagate that change and will have less risks of forgetting one occurence.

auto to prevent accidental slicing

Type inference also avoids nasty slicing errors, for example when MySpecialisedClass subclass needs to be used instead of MyClass and one declaration was forgotten, e.g:

See online example here demonstrating the advantage of auto.

But what about reading ?

There are a lot of languages with no explicit types specified or type inference similar to auto:

• JavaScript: In my experience, native experienced JS devs rarely complain about unreadable due to missing type information. The main concern is when accidentally a variable causes a runtime error because of a wrong type. So it's more about type safety than readability.
• Python, which is strongly but dynamically typed: Python devs that I know, usually don't complain either about the lack of explicit type and type hinting aims at type safety rather than readability as explained in PEP484
• Many other modern languages promote type inference. For example Rust or Swift, to name only a few. Swift for exemple encourages type inference with let (like const auto) and var (like auto).

Why not giving a try? Modern IDEs perfectly do the trick in getting used to it. Example with XCode:

It is true that the code is being read and maintained more often than it is written. But that's at lest one more reason to use auto !

auto as maintenance accelerator - change propagation

For the maintenance of code, auto has indeed often (not always) the advantage of facilitating abstraction and ease decoupling from the types. Take your example:

double totalCost=item1.quantity*item1.price+item2.quantity*item2.price+....

Imagine that you find out that finally double is not sufficiently precise for the price, and you' need to go for long double to avoid unacceptable loss. You'd have to go carefully through your code, and for every double look if it's concerned by the change or not. With auto, you let the compiler automatically propagate that change and will have lest risks of forgetting one occurence.

See online example here.

Of course, type inference has its limits, and sometimes the programmer really has to chose the right type. Make that the exception, not the rule.

auto as maintenance accelerator - slice protection

Type inference also avoids nasty slicing errors, when you want to use MySpecialisedClass subclass instead of MyClass and forget to adapt one declarator:

MyClass xyz("some", arguments);
... // lots of code 
MyClass uvw = xyz; // looks fine

But after refactoring:

MySpecialisedClass xyz("some", more, arguments);
... // lots of code 
MyClass uvw = xyz; // still looks fine - but slicing occurs ! 

But what with reading ?

There are a lot of languages out there with no types specified:

• Take also JavaScript. Do JavaScript complain that their code is not readable ? In my experience, the main concern is when accidentally a variable causes a runtime error because of the wrong type. So the complain is more about type safety than readability. (Of course, I exclude here fellows who come from strongly explicitly typed languages)
• Take Python, which is strongly but dynamically typed. Python coder usually not complain that their code is difficult to read because the type is not shown explicitly.
• Moreover type inference is adopted by many modern languages, like Rust or Swift, to name only a few. Swift for exemple encourages type inference and auto-like constructs with let and var.

Why would the absence of explicit type be more difficult to read if it's C++ then ? My position is that it's because of habits, habits still prevent people to embrace modern C++ and its benefits.

It is true that the code is being read and maintained more often than it is written. But that's at lest one more reason to use auto !

auto as maintenance accelerator - change propagation

For the maintenance of code, auto has indeed often (not always) the advantage of facilitating abstraction and ease decoupling from the types. Take your example:

double totalCost=item1.quantity*item1.price+item2.quantity*item2.price+....

Imagine that you find out that finally double is not sufficiently precise for the price, and you' need to go for long double to avoid unacceptable loss. You'd have to go carefully through your code, and for every double look if it's concerned by the change or not. With auto, you let the compiler automatically propagate that change and will have lest risks of forgetting one occurence.

See online example here.

Of course, type inference has its limits, and sometimes the programmer really has to chose the right type (often with the need of explicit casting some operands already in the expression to really achieve the intended result - see counter example here). Make that the exception, not the rule.

auto as maintenance accelerator - slice protection

Type inference also avoids nasty slicing errors, when you want to use MySpecialisedClass subclass instead of MyClass and forget to adapt one declarator:

MyClass xyz("some", arguments);
... // lots of code 
MyClass uvw = xyz; // looks fine

But after refactoring:

MySpecialisedClass xyz("some", more, arguments);
... // lots of code 
MyClass uvw = xyz; // still looks fine - but slicing occurs ! 

See online example here.

But what with reading ?

There are a lot of languages out there with no types specified:

• Take also JavaScript. In my experience, JS devs do rarely complain that their code is not readable due to missing type information. The main concern is when accidentally a variable causes a runtime error because of the wrong type. So the complain is more about type safety than readability. (Of course, I exclude here fellows who come from strongly explicitly typed languages and who still have to get used to it)
• Take Python, which is strongly but dynamically typed. Python coders I know usually not complain that their code is difficult to read because the type is not shown explicitly.
• Moreover type inference is adopted by many modern languages, like Rust or Swift, to name only a few. Swift for exemple encourages type inference and auto-like constructs with let and var.

Why would the absence of explicit type be more difficult to read if it's C++ then ? My position is that it's because of habits, habits still prevent people to embrace modern C++ and its benefits.

Moreover, modern IDEs perfectly do the trick in getting used to it. Example with XCode: