isFollowingCamelCaseConventionInCPlusPlus more_import_than_readability？
我将在下一个项目中从 Python 转向 C++。
我知道为什么我不应该并且我知道为什么我应该。别介意这场辩论。
C++ conventionForVariablesIsCamelCase我遇到了麻烦接受为，at_least_for_my_eyes_it's_less_read_than_the_lower_case_underscored_convention。
你们中是否有人遇到过一篇文章或信息声称程序员应该采用小写下划线约定并放弃驼峰命名法，即使在 C++ 项目中也是如此？或者也许有研究表明其中一种方法在科学上确实比另一种方法更具可读性？
I'm moving back from Python to C++ for my next project.
I know why I shouldn't and I know why I should. Never mind that debate.
C++ conventionForVariablesIsCamelCaseAndI'mHavingTroubleAcceptingIt as, at_least_for_my_eyes_it's_less_readable_than_the_lower_case_underscored_convention.
Did any of you encounter an article or information claiming programmers should adopt lower_case_underscored convention and abandon the camelCase, even in C++ projects? Or perhaps research that shows that one is indeed scientifically more readable than the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果在团队中编码，一致性可能比个人偏好更重要；团队成员不必在阅读 Joe 的代码和阅读 Jane 的代码之间进行上下文切换。同样，如果编写学术作业，则应遵循团队风格等课程风格（无论正确或错误），因为评分的人会习惯于阅读该内容，并且您需要为您的工作提取尽可能最好的分数！
否则我会建议，一种公约相对于另一种公约几乎没有什么优势。 CamelCase确实提供了一定的符号长度效率。
If coding in a team, consistency is probably more important than personal preference; team members should not have to context switch between reading Joe's code and reading Jane's code. Equally if coding academic assignments, course style like team style should be adhered to (for right or wrong), simply because the person awarding the marks will be used to reading that, and you need to extract the best possible mark for your work!
I would suggest otherwise that one convention has little advantage over another. CamelCase does provide a certain efficiency of symbol length.
如果这是一个私人项目，请使用您觉得舒服的任何命名约定，这有助于您提高工作效率。请记住，与语言/惯例的整体“风格”保持一致通常是一个好主意，因为任何示例/示例等通常都会使用该风格，从而使集成等更容易且更少“刺耳” 。
如果它是一个公共项目，那么使用约定可能会更好，因为这对其他人来说更容易使用。
如果是公司，请按照公司准则的要求进行操作。如果没有，那么我会像公共项目一样做。
关于驼峰命名法，我个人想说的一件事是，不要完全沉迷于它，为了可读性而应用常识。例如，我经常看到驼峰式名称中的缩写写成部分上部/部分下部，我认为这确实损害了可读性。在这种情况下，我总是会选择更具可读性的选项。因此，例如我总是写：
而不是
但是，这只是个人喜好。
If it's a private project, use whatever naming convention you feel comfortable with and helps you be productive. Just bear in mind that it is generally a good idea to be in keeping with the overall "style" oft he language / usual practise since any samples / examples etc. will usually use that style, making integration etc. easier and less "jarring".
If it's a public project it's probably better to use the conventions since that's easier for other people to work with.
If it's corporate, do whatever your corporate guidelines mandate. If there aren't any, then I'd do the same as for a public project.
One thing I'd personally say about CamelCase, is not to get completely hung up on it, and apply common sense for the sake of readability. For example, I've often seen abbreviations in camel case names written as part upper / part lower, which I think really hurts readability. In cases like this I'd always go for the more readable option. So, for example I'd always write:
rather than
But, this is just personal preference.
C++ 程序员之间对于 C++ 命名没有达成一致的约定，但是 C++ 标准库和 boost 中都使用带下划线的小写字母。
至于您链接的编码标准文档...
随机公司的编码标准的链接，该标准使用“C++ 开发社区中的常见做法”作为其标准的理由，但没有提供对该声明的引用，这听起来像是对权威，以证明文档编写者的偏好是合理的。
There is no agreed upon convention for C++ naming among C++ programmers, however lower case with underscores is used in both the C++ standard library and in boost.
As for the coding standards document you linked...
A link to a random company's coding standards that use "Common practice in the C++ development community" as a justification for their standards, yet provide no citation for that statement smells like a false appeal to authority in order to justify the preferences of whoever wrote the document.
驼峰命名法与下划线：科学对决描述了一项科学研究发现：
但该页面不同意他们的结论是有效的。 :)
它还对网站访问者进行了两项民意调查，每种风格的支持率都是 50/50。
CamelCase vs underscores: Scientific showdown describes a single scientific study which found:
But then the page disagrees that their conclusions are valid. :)
It also has two polls of visitors to the site, both of which are 50/50 in favor of each style.