isFollowingCamelCaseConventionInCPlusPlus more_import_than_readability？

Question

在我的下一个项目中，我将从Python转回C++。

我认识why I shouldn't我也认识why I should。别管这场辩论了。

C++ conventionForVariablesIsCamelCaseAndI'mHavingTroubleAcceptingIt as，at_least_for_my_eyes_it's_less_readable_than_the_lower_case_underscored_convention.

您是否遇到过一篇文章或信息声称程序员应该采用lower_case_underscored约定并放弃camelCase，即使在C++项目中也是如此？或者，也许有研究表明，其中一种确实比另一种更具科学可读性？

Answer 1

C++程序员对C++命名没有达成一致的约定，但是在C++标准库和boost中都使用了带下划线的小写字母。

至于你链接的编码标准文档...

指向随机公司的编码标准的链接使用“C++开发社区中的通用实践”作为其标准的理由，但没有提供对该声明的引用，这听起来像是为了证明编写文档的人的偏好而向权威机构提出的错误呼吁。

Answer 2

如果在团队中编码，一致性可能比个人偏好更重要；团队成员不应该在阅读Joe的代码和阅读Jane的代码之间进行上下文切换。同样，如果编写学术作业，应该坚持团队风格之类的课程风格(无论对错)，因为评分的人会习惯于阅读它，而你需要为你的工作提取尽可能好的分数！

否则，我会建议一种约定比另一种约定几乎没有优势。CamelCase确实提供了一定的符号长度效率。

Answer 3

如果这是一个私人项目，请使用任何您觉得舒服的命名约定，并帮助您提高工作效率。请记住，与语言/常规实践的整体“风格”保持一致通常是一个好主意，因为任何样本/示例等通常都会使用这种风格，从而使集成等变得更容易且不那么“刺耳”。

如果它是一个公共项目，那么使用约定可能会更好，因为这对其他人来说更容易使用。

如果它是公司的，那就做你的公司指南要求的任何事情。如果没有，那么我会像做公共项目一样做。

关于CamelCase，我个人要说的一件事是，不要完全沉迷于它，而是为了可读性而应用常识。例如，我经常看到驼峰大小写名称中的缩写写成part as / part lower，我认为这真的会影响可读性。在这种情况下，我总是选择可读性更好的选项。举个例子，我总是这样写：

private string targetURL;

而不是

private string targetUrl;

但是，这只是个人喜好。