Hacker News Reader

Comment by xyrouter | Hacker News Reader

> There’s absolutely no sense in which less explicit information is somehow better for code readers.

This is patently false. It has been demonstrated more than once in this thread that there clearly are cases where the types can be deduced effortlessly and avoiding explicit information leads to cleaner code.

Your claim is only your subjective opinion/belief and definitely not a fact.

We might just have to agree to disagree, but I would disagree with your claim here in the strongest possible terms. Constantly pretending as if your subjective beliefs comes off as obtuse and is in poor taste. There is one size fits all standard for coding. You are free to follow your coding standards and so is everyone else. What looks like an obvious argument to you may appear absurd to another. Like I said, the world of software development is far more heterogenous that you seem to believe it is.

View on HN

> “It has been demonstrated several times in this thread that there clearly are cases where the types can be deduced effortlessly and avoiding explicit information leads to cleaner code.”

I do not see a single example in this thread that demonstrates that. Absence of explicit type info is an inherently bad thing. It’s never good to offer code readers less explicit / more ambiguous info.

Like I said, you’d expect some offsetting benefit (what you call “cleaner code”) to compensate for paying the penalty of giving up valuable explicit info. But auto does not actually provide that in comparison to typedef/typename. auto, by comparison, is not meaningfully cleaner code. It only loses valuable explicit information, without an offsetting benefit that couldn’t otherwise be obtained without losing that valuable explicit information.

> Absence of explicit type info is an inherently bad thing.

Let me reiterate: It is your opinion which many people here do not agree with in the context of types obvious from context. Your opinion is definitely not a popular coding standard and definitely not a fact. Most of the coding standards are in favor of using auto for simple code where the type is immediately obvious from the context.

The auto keyword is available to help people who do not share your opinion. The auto keyword is present for teams which agree that absence of explicit type info is a good thing for simple code with obvious types (obvious from the context).

Teams that believe that absence of explicit type info is an inherently bad thing don't have to use the auto keyword. But that belief does not become a fact no matter how many times you reiterate that belief.

> paying the penalty of giving up valuable explicit info

That's your opinion. My opinion which many coding standards agree with: There is no penalty in giving up explicit type info in a local loop variable. The typo info is not valuable in that case.

In my comments my goal was to describe why those other beliefs about auto are just fundamentally mistaken. To lobby for a certain way to think of it.

My perspective on this actually is a very popular coding standard in some communities. For example, in The Zen of Python [0] (which is an official Python PEP) there is, “Explicit is better than implicit” right in the second line. It’s quite a widely regarded principle in programming.

Still, given that I only lobbied to persuade that my perspective is the right one in this case, and did not ever try to claim that people cannot have a different opinion, your comment seems unrelated to earlier part of the discussion.

[0]: < https://www.python.org/dev/peps/pep-0020/ >.

Reply on news.ycombinator.com