Timeline for Is the inability to find code by searching for a class name a reason to avoid using auto in c++ variable declarations?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 6 at 16:20 | history | edited | Christophe | CC BY-SA 4.0 |
added 118 characters in body
|
| Jul 6 at 13:17 | history | edited | Christophe | CC BY-SA 4.0 |
deleted 110 characters in body
|
| Jul 6 at 13:01 | comment | added | Christophe | @DocBrown Indeed. So I've edited relativizing the sample of developers I was referring to. I also added code example to prove my statements with evidence (note that when auto choses the wrong type, often explicating the destination type is not sufficient and explicit conversion of an operand is needed, which then allows auto to work well again). Last but not least, I reminded that modern IDEs can help with getting used to it. | |
| Jul 6 at 12:58 | history | edited | Christophe | CC BY-SA 4.0 |
added 506 characters in body
|
| Jul 6 at 10:39 | comment | added | Doc Brown | We both don't have stats, but I did not make such a claim ;-) | |
| Jul 6 at 9:28 | history | edited | Christophe | CC BY-SA 4.0 |
added 365 characters in body
|
| Jul 6 at 8:51 | comment | added | Christophe | @DocBrown here again, I will return your argument: is there any evidence that apart from a few people claiming here that auto is a readability problem, is there any evidence that this is a generally accepted issue ? Personally I know some and see many more Python and JavaScript gurus that are very happy with the absence of explicit type, and the main complain I hear int his regard is when runtime errors are encountered due to incompatible type in JS, i.e. the absence of protection against typing errors but not the readability of their code. But true, I have no stats and neither have you ;-) | |
| Jul 6 at 8:46 | comment | added | Christophe | @DocBrown I think the example is on contrary very good for the vast majority of cases where LHS can be deduced from the expression. See this snippet, where you can verify by yourself by changing types of item price: ideone.com/GpOsEa - Now it does not work if the type promotion rules of C++ are not sufficient, and a change of magnitude is required. But these are special cases, and then indeed, you need to explicitly state your type. I didn't say auto everywhere. | |
| Jul 6 at 6:49 | comment | added | Doc Brown | ... and about Python and JavaScript coders - that's a very gross statement about a huge number of people, and I am sure you will find a lot developers who are not just Python coders or just JavaScript coders but also working with different languages and will complain about readability. | |
| Jul 6 at 6:37 | comment | added | Doc Brown | The "double totalCost = ..." example is a really bad one - because in this particular case, it is not unlikely the correct type for totalCost cannot be reliably deduced from the types of the code on the right hand side (lets say quantity and price are just doubles, the compiler cannot find out whether the LHS needs to be a double or a long double). | |
| Jul 5 at 20:03 | history | edited | Christophe | CC BY-SA 4.0 |
added 391 characters in body
|
| Jul 5 at 19:41 | comment | added | Christophe | @JAD But you could loon at other examples also. Nobody complains about JavaScript var which looks like auto. Except for type checking to avoid at compile time the runtime errors. Other lodern languages also encourege this parctice like Swift. | |
| Jul 5 at 19:38 | comment | added | Christophe | @JAD indeed, PEP484 explains that the goals of type hinting is static analysis and refactoring, but that it is not intended to change the paradigm of the dynamic typed language peps.python.org/pep-0484 - Thos confirms Ben's statement | |
| Jul 5 at 7:43 | comment | added | JAD | @BenCottrell ok, let me be more accurate: there's a reason type hints were retrofitted into the language. And at least part of that is for humans to read. It's not just for type checking, but also for documenting APIs. | |
| Jul 5 at 6:29 | comment | added | Ben Cottrell | @JAD MyPy exists for static type checking, which is already a given in statically type-checked languages like C++. It's not for human readability. The reason for adding types to code is simply so that tools have sufficient information to be able to enforce a set of rules/constraints at build time and to be able to provide more assistance within an IDE. Adding more redundant types which can be automatically inferred by a tool does not help anybody. | |
| Jul 5 at 5:55 | comment | added | JAD | "Python coder usually not complain that their code is difficult to read because the type is not shown explicitly." Yes they do, there's a reason MyPy exists. | |
| Jul 4 at 21:30 | history | answered | Christophe | CC BY-SA 4.0 |