自动会使C ++代码更难理解吗？

auto x = GetX();

someWeirdTemplate<someOtherVeryLongNameType, ...>::someOtherLongType x = GetX();

#1 楼

简短的回答：更全面地说，我目前对auto的看法是，除非您明确希望进行转换，否则您应该默认使用auto。 （更准确地说，“ ...除非要显式地提交给类型，这几乎总是因为您要进行转换。”）

更长的答案和原理：

仅当您确实要显式提交类型时才写一个显式类型（而不是auto），这几乎总是意味着您要显式获得对该类型的转换。我脑海中浮现出两个主要情况：


（常见）initializer_list引起auto x = { 1 };推导initializer_list的惊奇。如果您不希望使用initializer_list，请说出类型-即，明确要求进行转换。
（稀有）表达式模板的情况，例如auto x = matrix1 * matrix 2 + matrix3;捕获了对助手不可见的助手或代理类型。程序员。在许多情况下，捕获该类型既好又无害，但是有时如果您真的希望将其折叠并进行计算，请说出类型-即再次明确要求进行转换。

常规否则，默认情况下请使用auto，因为使用auto可以避免陷阱，并使您的代码更正确，更可维护，更健壮并且更高效。从“最重要到最不重要”的顺序从高到低依次排列：




正确性：使用auto可以确保您获得正确的类型。俗话说，如果你重复自己（重复说一遍），你就会并且会撒谎（弄错了）。这是一个常见的示例：void f( const vector<int>& v ) { for( /*…*-至此，如果您明确编写迭代器的类型，则要记住要写const_iterator（对吗？），而auto就是正确的实现。

可维护性和鲁棒性：使用auto可使代码在更改时更加健壮，因为当表达式的类型更改时，auto将继续解析为正确的类型。如果改用显式类型，则当新类型转换为旧类型时，更改表达式的类型将注入静默转换，或者当新类型仍然有效时（如旧类型但不转换为旧类型），不必要的构建中断类型（例如，当您将map更改为unordered_map时，如果您不依赖订单，这总是很好的，将auto用作迭代器，您会从map<>::iterator无缝切换到unordered_map<>::iterator，但是在所有地方都使用map<>::iterator明确意味着您'除非浪费实习生，否则您会浪费宝贵的时间，除非实习生走过，您可以对它们进行无聊的工作。）

性能：因为auto保证不会发生隐式转换，默认情况下，它保证更好的性能。相反，如果您说类型并且需要转换，那么无论您是否期望，您都会无声地获得转换。

可用性：使用auto是难于拼写的唯一好选择以及不确定的类型（例如lambda和模板帮助程序），没有采用重复的decltype表达式或效率较低的间接调用（如std::function）。

方便：是的，auto的键入较少。我之所以提到最后一个是出于完整性，是因为它是喜欢它的常见原因，但这并不是使用它的最大原因。
因此：默认情况下，最好说auto。它提供了如此多的简单性，性能和清晰度优势，如果不这样做，只会伤害自己（以及代码的未来维护者）。仅当您真正想要一个显式类型时才提交它，这几乎总是意味着您想要一个显式转换。

是的，关于（现在）有一个关于此的GotW。

评论

---

即使我确实想要进行转换，我也觉得自动有用。它使我可以明确地要求进行转换，而无需重复以下类型：auto x = static_cast （y）。 static_cast清楚地表明该转换是有意的，并且避免了有关该转换的编译器警告。通常情况下，避免编译器警告不是很好，但是我可以在收到static_cast时没有仔细考虑转换的警告，这是可以的。尽管如果现在没有警告，我不会这样做，但是如果类型以潜在危险的方式更改，我希望将来获得警告。

–巴克·哈默斯霍尔特·鲁恩
2012年12月26日在18:05

---

我发现对auto的一件事是，我们应该努力针对接口（不是从OOP的角度）进行编程，而不是针对特定的实现进行编程。实际上，模板也是如此。您是否抱怨“难以阅读的代码”，因为您有在各处使用的模板类型参数T？不，我不这么认为。在模板中，我们也针对接口进行编码，很多人称之为编译时鸭子式输入。

– Xeo
2012-12-27 13:09：

---

“使用自动保证您将获得正确的类型。”完全不对。它仅保证您将获得代码其他部分规定的类型。将其隐藏在汽车后面时，是否完全正确尚不清楚。

–轨道轻度竞赛
15年3月10日在19:06

---

我真的很惊讶，没有人关心IDE。即使是现代IDE也不能正确支持在使用auto变量的情况下跳转到类/结构定义，但是几乎所有的IDE都使用显式类型规范正确地做到了这一点。没有人使用IDE吗？每个人都只使用int / float / bool变量吗？每个人都喜欢使用库的外部文档而不是自带文档的标题？

–avtomaton
17-1-26在1:15

---

GotW：herbutterutter.com/2013/08/12/…我看不出“ initializer_list惊喜”是多么令人惊讶；大括号= RHS在任何其他解释中都没有多大意义（大括号的init列表，但是您需要知道要初始化的内容，这是auto的矛盾之处）。令人惊讶的是，自动i {1}还会推导出initializer_list，尽管它暗示不采用此括号的init-list而是采用此表达式并使用其类型...但我们也在那里获得initializer_list。幸运的是，C ++ 17很好地解决了所有这些问题。

– underscore_d
17年12月9日15:43

---

#2 楼

这是一个个案的情况。

有时会使代码难以理解，有时却很难。举个例子：

void foo(const std::map<int, std::string>& x)
{
   for ( auto it = x.begin() ; it != x.end() ; it++ )
   { 
       //....
   }
}

绝对比实际的迭代器声明更易于理解和编写。

现在使用C ++已有一段时间了，但是我可以保证在此过程中第一次出现编译器错误，因为我会忘记const_iterator，而最初会选择iterator ... :)

我会在这种情况下使用它，但实际上不会混淆类型（如您的情况），但这纯粹是主观的。

#3 楼

换一种方式来看。您是否写：

std::cout << (foo() + bar()) << "\n";

或：

// it is important to know the types of these values
int f = foo();
size_t b = bar();
size_t total = f + b;

std::cout << total << "\n";

有时拼写类型无济于事

是否需要提及类型的决定与是否要通过定义中间变量在多个语句之间拆分代码的决定不同。在C ++ 03中，两者是链接在一起的，您可以将auto视为分隔它们的一种方法。

有时使类型显式很有用：

// seems legit    
if (foo() < bar()) { ... }

vs.

// ah, there's something tricky going on here, a mixed comparison
if ((unsigned int)foo() < bar()) { ... }

在声明变量的情况下，使用auto可以像在许多表达式中那样直言不讳。您可能应该尝试自己决定什么时候可以提高可读性以及什么时候会影响可读性。

您可以辩解说，混合有符号和无符号类型是一个错误的开始（实际上，有人进一步争论说，不应完全使用无符号类型）。可以说这是一个错误的原因是，由于行为不同，它使得操作数的类型至关重要。如果需要了解值的类型是一件坏事，那么不必了解它们也不是一件坏事。因此，只要代码没有因为其他原因而令人困惑，这会使auto正常，对吗？ ;-)

特别是在编写通用代码时，在某些情况下，变量的实际类型不重要，重要的是它满足所需的接口。因此，auto提供了一个抽象级别，您可以忽略该类型（但它知道编译器当然不会）。在适当的抽象级别上工作可以极大地提高可读性，而在“错误”级别上工作会使阅读代码成为徒劳。

#4 楼

IMO，您正在相反地看待这个问题。

auto导致代码不可读甚至可读性不高。 （希望）为返回值使用显式类型可以弥补以下事实：（显然）不清楚某个特定函数将返回哪种类型。

至少我认为，如果您的函数的返回类型不是立即显而易见的，那就是您的问题所在。该函数的作用从其名称应显而易见，而返回值的类型应从其作用显而易见。如果不是，那是问题的真正根源。

如果这里有问题，则不是auto。它与其余代码一起使用，并且显式类型很有可能只是一个创可贴，足以使您避免看到和/或解决核心问题。一旦解决了这个实际问题，使用auto的代码的可读性通常就可以了。

我想公平地说，我应该补充一点：我已经处理了一些不存在此类情况的案例。几乎没有您想要的那么明显，并且解决问题也相当困难。仅举一个例子，我几年前曾为一家曾与另一家公司合并的公司做过一些咨询。他们最终得到的代码库比真正合并的“库在一起”更多。组成程序出于相似的目的开始使用不同的（但非常相似的）库，尽管它们正在努力更干净地合并事物，但它们仍然这样做。在很多情况下，猜测给定函数将返回哪种类型的唯一方法是知道该函数的起源。

即使在这种情况下，您也可以帮助使几件事更清楚了。在这种情况下，所有代码都始于全局名称空间。只需将大量迁移到某些名称空间中，就可以消除名称冲突，并大大简化了类型跟踪。

#5 楼

我不喜欢一般用途的汽车有以下几个原因：


您可以重构代码而不修改它。是的，这是经常列举为使用auto的好处之一。只需更改函数的返回类型，如果调用该函数的所有代码都使用了auto，则无需额外的工作！您点击编译，它会生成-0个警告，0个错误-并且您只需继续检查代码即可，而无需处理检查和可能修改该函数使用的80个位置的麻烦。

但是，这真的是个好主意吗？如果在六个用例中类型很重要，而现在代码实际上表现出不同，该怎么办呢？这不仅可以隐式地破坏封装，而且不仅可以修改输入值，还可以修改其他调用该函数的类的私有实现的行为本身。

1a。我相信“自我记录代码”的概念。自记录代码背后的原因是注释趋向于过时，不再反映代码在做什么，而代码本身（如果以显式方式编写）是不言自明的，始终保持最新它的意图，不会让您对陈旧的评论感到困惑。如果可以在无需修改代码本身的情况下更改类型，则代码/变量本身可能会过时。例如：

auto bThreadOK = CheckThreadHealth（）;

除非问题是重构了CheckThreadHealth（）在某个时候返回表示错误状态的枚举值，如果任何，而不是布尔。但是进行此更改的人错过了检查这行特定代码的过程，并且编译器没有帮助，因为它在编译时没有警告或错误。


您可能永远都不知道实际的类型是什么。这通常也被列为汽车的主要“好处”。当您只说“谁在乎？它会编译！”时，为什么要了解功能为您提供的功能呢？

可能甚至是种作品。我说这种方法是可行的，因为即使您为每次循环迭代都复制了一个500字节的结构，因此您可以检查其上的单个值，但是代码仍然可以完全正常工作。因此，即使您的单元测试也无法帮助您意识到不良的代码正隐藏在这种简单且无辜的汽车后面。扫描文件的大多数其他人也不会一眼就注意到它。

如果您不知道类型是什么，但是选择一个变量名可以使这种情况变得更糟。关于它是什么的错误假设，实际上实现了与1a中相同的结果，但是从一开始就实现了，而不是后重构。


在最初编写代码时键入代码是不正确的。是编程中最耗时的部分。是的，auto使最初编写某些代码的速度更快。作为免责声明，我确实输入> 100 WPM，所以也许它不会像其他人那样困扰我。但是，如果我只需要整天编写新代码，那我将是一个快乐的露营者。程序设计中最耗时的部分是诊断代码中难以重现的边缘错误，这些错误通常是由细微的非显而易见的问题引起的，例如，可能会引入对auto的过度使用（引用与复制，对我来说，很明显，引入auto最初是作为使用标准库模板类型的可怕语法的变通方法，这对我来说似乎很明显。而不是尝试修复人们已经熟悉的模板语法-由于可能会破坏所有现有代码，这也几乎是不可能的-添加一个基本上可以隐藏问题的关键字。本质上，您可能称之为“黑客”。

实际上，我对标准库容器中的auto使用没有异议。显然是为关键字创建的，标准库中的功能不太可能从根本上改变目的（或类型），从而使auto相对安全地使用。但是对于在您自己的代码和接口中使用它可能会更加不稳定，并且可能会进行更根本的更改，我会非常谨慎。

auto的另一个有用的应用程序可以增强语言的功能在与类型无关的宏中创建临时对象。这是您以前真正无法做到的，但是现在您可以做到。

#6 楼

是的，如果您不使用auto，则可以更轻松地知道变量的类型。问题是：您是否需要知道变量的类型才能阅读代码？有时答案是肯定的，有时则是。例如，从std::vector<int>获取迭代器时，您是否需要知道它是std::vector<int>::iterator还是足够？任何人想要使用迭代器的所有事情都由它是一个迭代器的事实给出-只是类型无关紧要。

在那些情况下使用auto iterator = ...;您的代码更难阅读。

#7 楼

我个人仅在对程序员绝对清楚的情况下使用auto。

示例1

std::map <KeyClass, ValueClass> m;
// ...
auto I = m.find (something); // OK, find returns an iterator, everyone knows that

示例2

MyClass myObj;
auto ret = myObj.FindRecord (something)// NOT OK, everyone needs to go and check what FindRecord returns

#8 楼

这个问题征求意见，不同的程序员对此有所不同，但我会拒绝。实际上，在许多情况下恰恰相反，auto可以使程序员专注于逻辑而不是细节，从而有助于使代码更易于理解。

面对复杂的模板尤其如此类型。这是一个简化的人为示例。哪个更容易理解？

for( std::map<std::pair<Foo,Bar>, std::pair<Baz, Bot>, std::less<BazBot>>::const_iterator it = things_.begin(); it != things_.end(); ++it )

..或...

for( auto it = things_.begin(); it != things_.end(); ++it )

有人会说第二个更容易理解，其他人可能会说第一个。还有一些人可能会说，免费使用auto可能会导致使用它的程序员愚蠢，但这是另一回事。

#9 楼

到目前为止，有许多不错的答案，但我还是把重点放在最初的问题上，赫伯在他的建议中走得太远，无法自由地使用auto。您的示例是使用auto显然会损害可读性的一种情况。有人坚持认为，对于现代IDE来说，这不是问题，您可以将其悬停在变量上并查看类型，但我不同意：即使是始终使用IDE的人有时也需要单独查看代码段（认为代码回顾）。 ，例如，IDE则无济于事。

底线：在有帮助时使用auto：即迭代for循环。当它使读者难以找出类型时，请不要使用它。

#10 楼

我很惊讶，没有人指出，如果没有明确的类型，auto会有所帮助。在这种情况下，您可以通过在模板中使用#define或typedef来查找实际的可用类型（有时并不容易）来解决此问题，或者只使用auto。

假设您有一个函数，该函数返回了特定于平台的类型：

#ifdef PLATFROM1
__int256 getStuff();
#else //PLATFORM2
__int128 getStuff();
#endif

您希望使用女巫吗？

#ifdef PLATFORM1
__int256 stuff = getStuff();
#else
__int128 stuff = getStuff();
#endif

或只是简单地

auto stuff = getStuff();

当然，您可以在任何地方写

#define StuffType (...)

，但是

StuffType stuff = getStuff();

实际上能告诉我们有关x类型的更多信息吗？它告诉它是从那里返回的内容，但恰恰是auto是什么。这只是多余的-在这里“ stuff”被写入了3次-我认为这使其比“ auto”版本的可读性更差。

#11 楼

可读性是主观的；您需要查看情况并决定最好的方法。

如您所指出的，没有自动，长声明会产生很多混乱。但是，正如您还指出的那样，简短声明可以删除可能有价值的类型信息。

此外，我还要补充一点：请确保您正在查看的是可读性而不是可写性。易于编写的代码通常不容易阅读，反之亦然。例如，如果我正在写，我会更喜欢自动。如果我正在阅读，也许是更长的声明。

然后保持一致。这对您有多重要？您是要在某些部分使用auto还是在其他部分使用显式声明，还是在整个过程中使用一种一致的方法？

#12 楼

我将以可读性较低的代码为优势，并鼓励程序员越来越多地使用它。为什么？显然，如果使用auto的代码难以阅读，那么也将很难编写。程序员被迫使用有意义的变量名，以使其工作更好。
也许一开始程序员可能不会编写有意义的变量名。但是最终在修复错误或代码审查时，当他/她不得不向他人解释代码时，或者在不久的将来，他/她向维护人员解释代码，程序员将意识到错误并会使用将来有意义的变量名。

#13 楼

我有两个准则：



如果变量的类型很明显，那么编写起来会很乏味或很难
确定自动使用。

auto range = 10.0f; // Obvious

for (auto i = collection.cbegin(); i != cbegin(); ++i) // Tedious if collection type
// is really long

template <typename T> ... T t; auto result = t.get(); // Hard to determine as get()
// might return various stuff

如果需要特定的转换，或者结果类型不明显并且可能引起混淆。

class B : A {}; A* foo = new B(); // 'Convert'

class Factory { public: int foo(); float bar(); }; int f = foo(); // Not obvious

#14 楼

是的。
它会降低冗长度，但常见的误解是冗长度会降低可读性。
只有当您认为可读性是美的而不是您理解代码的实际能力时，这才是正确的-通过使用auto并不能提高代码的能力。
在最常引用的示例中，矢量迭代器可能会出现在使用auto可以提高代码的可读性。
另一方面，您并不总是知道auto关键字会为您带来什么。您必须遵循与编译器相同的逻辑路径来进行内部重构，并且在很多时候，尤其是对于迭代器，您将做出错误的假设。

最后如今，“自动”功能牺牲了代码的可读性和清晰度，因为语法和美学上的“整洁”（这仅是必需的，因为迭代器具有不必要的复杂语法），并且可以在任何给定的行上少输入10个字符。
这样做不值得冒险，也不值得长期努力。