ISO研究Ada或C ++中的下划线与MixedCase [英] ISO Studies of underscores vs MixedCase in Ada or C++

问题描述

我正在寻找任何严格的，b $ b b科学，学术或工业研究

比较

C ++或类似语言中的命名惯例作为

Ada：


具体来说，用

形成的名字或多或少强调了

比使用MixedCase形成的名字

StudlyCaps camelCase？


....同样，任何测量值

程序员的工作效率，bug价格，

等;虽然恕我直言可读性很重要

最多。

*宗教 - 不是吗？！


我明白这是一个宗教问题

对于很多程序员来说，这是一个编程风格的问题。

我对宗教战争不感兴趣。

我显然有自己的看法，但是我am

对科学证据持开放态度。

* Ada研究？


我以为我见过像
这样的研究一些早期设计文件中的
这对于Ada来说是
，但是我无法在网上找到

这样的引用。这不是完全令人惊讶的，因为Ada在网络设计之前已经设计了

。


Ada 83和95质量指南建议

强调提高可读性，但提供

没有来源证明这个陈述是正确的。

*这样的研究可能是什么样的


简单的可读性和召回：

- 提供一个测试科目

a复合词列表

由下划线和混合组成case

- 删除列表，并询问测试对象

来写它

- 准确性得分


程序调试

- 目前相同的程序，

不同之处仅在于使用下划线/ MixedCase

来测试主题程序员（例如一个CS类）

- 程序有一个已知的bug

- 让测试对象找到bug

- 准确定位bug得分


Cruel TA研究：

- 两部分CS课程

- 执行编程标准，

下划线vs MixedCase

- 构成编程问题

- 分数根据成功

完成任务


经验：

- 给定版本控制数据库

of large程序，一些用下划线写的

样式，其他在MixedCase中

- 由LOC，名称计数等标准化的总错误率

- 或者：只计算可归因的错误

（检查签到后）错误命名的变量


就此而言，我会对任何调查感兴趣

人们可能已经完成了计算项目和他们的

编码标准，可能加权

- 开源（例如sourceforge）

- 工业

- 教科书，按销售额加权

- 编码标准网站，按Google分数加权......
虽然这不如一项严谨的研究那么令人信服。

*选择新闻组的解释


我希望我选择这些的原因很明显

新闻组将此搜索发布到：


comp.software-eng，comp.programming，

- 一个软件问题工程

comp.lang.c ++，

- 我最感兴趣的语言

comp.lang.ada

- 因为我模糊地回忆起历史作品

I am in search of any rigourous,
scientific, academic or industrial studies
comparing naming conventions in
C++ or similar languages such as
Ada:

Specifically, are names formed with
underscores more or less readable
than names formed with MixedCase
StudlyCaps camelCase?

....and similarly, any measurements
of programmer productivity, bug rate,
etc.; although IMHO readability matters
most.
* Religion - NOT?!

I understand that this is a religious issue
for many programmers, an issue of programming style.
I am not interested in a religious war.
I obviously have my own opinion, but I am
open to scientific evidence.
* Ada Studies?

I thought that I had seen studies like
this in some of the early design documents
for Ada, but I have not been able to find
such references on the web. Which is not
entirely surprising, since Ada was designed
prior to the web.

The Ada 83 and 95 Quality Guidelines recommend
underscores to improve readability, but provide
no source justifying this statement.
* What such studies might look like

Simple readability and recall:
- present a test subject with
a list of compound words
formed with underscoresand mixed case
- remove the list, and ask test subject
to write it
- score on accuracy

Program debugging
- present programs that are otherwise identical,
differing only in their use of underscores/MixedCase
to test subject programmers (e.g. a CS class)
- program has a known bug
- ask test subjects to find bug
- score on accuracy locating bug

Cruel TA study:
- Two sections of a CS class
- Enforce programming standards,
underscores vs MixedCase
- Pose a programming problem
- Score according to success
completing assignment

Empirical:
- Given version control databases
of large programs, some written in underscore
style, others in MixedCase
- Total bug rates normalized by LOC, name count, etc.
- OR: count only bugs that can be attributed
(after inspection of checkins) to misnamed variables

For that matter, I would be interested in any surveys
folks may have done that count projects and their
coding standards, possibly weighted
- open source (e.g. sourceforge)
- industrial
- textbooks, weighted by sales
- websites of coding standards, weighted by Google score...
Although this is less convincing than a rigorous study.
* Explanation of Newsgroups Chosen

I hope it is obvious why I have chosen these
newsgroups to post this search to:

comp.software-eng, comp.programming,
- an issue of software engineering
comp.lang.c++,
- the language I am most interested in
comp.lang.ada
- because I vaguely recall historical work

推荐答案

Andy Glew写道：

Andy Glew wrote:

我正在寻找任何严谨的，
科学，学术或工业研究
比较C ++或类似语言中的命名约定，例如

I am in search of any rigourous,
scientific, academic or industrial studies
comparing naming conventions in
C++ or similar languages such as

[SNIP]

下划线约定也适用于不区分大小写的la nguages。


InnerCaps约定无法解决所有大写单词的问题，例如

SMTPTCPIPConnection。通常的解决方案是将它们写错了

SmtpTcpIpConnection。


下划线约定会使线条变长，这可能会导致错误

对可读性的影响。


IMO这是个人偏好问题，也是使用什么字体和
开发envirnmoent的问题。


IMO如果必须使用许多

语言为整个公司选择* one *约定，那么只有下划线语言。使用InnerCaps可以创建难以找到的名称冲突，特别是在语言中，变量类型可以通过简单的赋值来改变运行时。

/>

-

Attila aka WW

[SNIP]

The underscore convention work also in case insensitive languages.

The InnerCaps convention fails to solve the issue of all caps words like
SMTPTCPIPConnection. Usual solution is to write them wrong as
SmtpTcpIpConnection.

The underscore convention tends to make lines longer, which can have bad
effect on readablity.

IMO it is a personal preference issue, and also an issue of what fonts and
development envirnmoent is in use.

IMO if one has to select *one* convention for a whole company using many
languages then only the underscore one stands. With InnerCaps there is a
possibility to create hard-to-find name collisions, especially in languages
where the type of variables can change runtime by a simple assignment.

--
Attila aka WW

" Andy Glew" <一个******* @ amd.com>在消息中写道

新闻：2c ************************** @ posting.google.c om ...


[snip]

"Andy Glew" <an*******@amd.com> wrote in message
news:2c**************************@posting.google.c om...

[snip]

具体来说，名称形成的
下划线或多或少可读，而不是形成的名称MixedCase
StudlyCaps camelCase？


用大写字母写一个大文本（几行），同样用下划线再写

。然后让人们阅读并询问他们找到了什么

更容易阅读。如果大多数人赞成带有下划线的文本

，我不会感到惊讶。


[snip]

Ada 83和95质量指南建议使用下划线来提高可读性，但提供无法证明此声明的来源。

Specifically, are names formed with
underscores more or less readable
than names formed with MixedCase
StudlyCaps camelCase?
Write a large text (several lines) with mixed-case and the same again
with underscores. Then give it people to read and ask them what they find
easier to read. I would not be surprised if the majority favours the text
with underscores.

[snip]
The Ada 83 and 95 Quality Guidelines recommend
underscores to improve readability, but provide
no source justifying this statement.

下划线可以很容易地被视为一个空间分开单词，

而混合大小写不提供这样的分离，而是一个

''大''这里来一个新词 - 标记（即大写字母）。这个问题我用b：b来看看：非大写字母也可以是大字母。只是看看't''，''h'等等的
，其中，imo，不会让阅读混合大小写的文本

更容易。


就个人而言，我更喜欢下划线。


只需我的.02c

-

jb


（如果你想通过电子邮件回复，用x替换y）

The underscore can easily be view as a space which seperates the words,
whereas mixed-case does not provide a seperation like that, but rather a
''large'' here-comes-a-new-word-mark (ie. the captial letter). The problem I
see with this: non-captial letters can be ''large'' as well. just have a look
at the ''t'', ''h'' etc, which, imo, does not make reading a mixed-case text
easier.

Personally, I prefer underscore for the reason above.

Just my .02c
--
jb

(replace y with x if you want to reply by e-mail)

Jakob Bieling写道：

Jakob Bieling wrote:

下划线可以很容易地被视为一个分隔单词的空间，而混合大小写不提供像这样的分离，而是一个
''large''这里是一个新词标记（即大写字母）。我用这个问题看到的问题：非大写字母也可能是大的。只是看看t，h等等，这些，imo，不会让阅读混合大小的文本更容易。

The underscore can easily be view as a space which seperates the words,
whereas mixed-case does not provide a seperation like that, but rather a
''large'' here-comes-a-new-word-mark (ie. the captial letter). The problem I
see with this: non-captial letters can be ''large'' as well. just have a look
at the ''t'', ''h'' etc, which, imo, does not make reading a mixed-case text
easier.

我想我们只需要一个编程字体，在所有大写字母前都有半尺寸的下划线

。这样可以解决所有这些问题。

我个人不喜欢打印下划线，但我同意他们更可信/ b $ b可读。 Emacs确实有一个以驼峰为基础的标识符标识符，如b * b模式，这是朝着正确方向迈出的一步。

I think we just need a programming font that has half-sized underscores
in front of all the capital letters. That would solve all these problems.
I personally don''t like typing underscores, but I agree they are more
readable. Emacs does have a view-camel-cased-identifiers-as-underscored
mode, so that''s a step in the right direction.

这篇关于ISO研究Ada或C ++中的下划线与MixedCase的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！