3

情况:自动生成的成员,例如 MenuStrip 项目,其(自动生成的)名称基于创建项目时输入的文本。我最常见的情况是创建一个菜单条并通过输入它们的文本来添加菜单项(使用图形设计器)。

由于我的 GUI 是希伯来语,所有这些成员都有一个包含希伯来语字符串的名称。类似“(hebrew-text)ToolStripItem”的东西。当我创建事件处理程序时,事件处理程序“继承”希伯来文文本:“(hebrew-text)ToolStripMenuItem_Click”。

这实际上效果很好,IntelliSense 对希伯来语文本没有问题,编译器也是如此。

问题是:我应该更改这些名称(还是首先阻止它们被创建)?保留这些名称可能会产生什么后果?

编辑:澄清一下,当我说希伯来语文本时,我不是指用英文文本写的希伯来语单词,我指的是实际的希伯来语字符。

4

5 回答 5

9

始终用英语编程。我在几个欧盟国家所经历的所有成功的开发团队都是这样做的。如果(比如说)荷兰团队想要将代码出售给(比如说)西班牙团队,这会变得容易得多。

于 2010-04-25T15:49:06.133 回答
2

对我来说,英语是软件开发的语言。一方面,它是一种在非母语人士中广泛传播的语言,在开发人员中更是如此。而且英语是一门非常简单易学的语言,至少足以表达软件问题。我个人希望每个开发人员(至少来自欧洲)都具备这种语言水平。那些不这样做的人与世界其他地方隔绝,无法获得许多重要资源。
此外,由于绝大多数开发人员都使用英语,因此在英语中与软件相关事务的术语更不成熟,这极大地有助于减少歧义。

就我个人而言,即使是作为用户,我也会尽可能地尝试获得英文软件(尽管有些公司似乎并不理解他们只提供德文版本并没有帮助我)。本地化通常是废话,很难获得帮助,因为翻译得非常好让您无法找到,您遇到问题的功能如何用英语调用,同时德语帮助不可用。:-D

任何对它产生影响的开发人员,无论他是否用英语编写代码,都应该提高他的语言水平,例如用英语编码。如果不是,那么他没有理由不应该使用英语,但有很多理由应该这样做。

英语允许来自世界各地的开发人员组成一个大社区,分享知识和经验,让来自不同国家的团队在没有语言障碍的情况下一起工作。就个人而言,我希望世界各地的每个人都学习英语,但我不能指望那样。但是我想我可以期待一个掌握多种编程语言,有足够的数学知识并训练他的抽象和逻辑思维的人。

用英语编码就像使用正确的格式或具有一致的命名约定以及使用富有表现力的标识符名称。所有这些都是最基本的编程最佳实践(实际上甚至不是“编程”,只是“编写代码”)。如果您习惯了,这样做无需额外的努力。不这样做也可以。直到有一天,你会越过“工作正常”的界限,那是事情变得丑陋的时候,因为你越是避免使用最佳实践,就越难改变事情。

所以,是的,您应该更改您的成员名称。您应该首先养成用英语创建它们的习惯。

问候
back2dos

于 2010-04-25T16:53:48.453 回答
1

大概。我赞成多元文化主义,但是当主要文档是英文但代码不是时,这非常令人沮丧(特别是对于开源)。您会得到T_PAAMAYIM_NEKUDOTAYIM 之类的东西(请注意,大多数(全部?)其他 PHP 运算符只是符号或英文)。更讽刺的是,记录这一点的页面甚至没有国际化为希伯来语。事情可能会无意中泄漏到 UI 中,这使得国际化变得更加困难。

于 2010-04-25T15:44:23.610 回答
1

在我目前的工作中,我已经多次看到这个问题。我是一名印度程序员,正在处理用德语编写的代码。所有函数、变量、注释的名称都是德文的……在我使用重构工具并将所有变量重命名为英文描述之前,我阅读代码非常糟糕。在早期的工作中,我不得不处理仅用日语编写的 API 手册。日文评论!非常烦人且难以维护这样的代码,因为有时翻译会让您猜测原始程序员的意思。

我的建议:你不知道谁来维护你的代码。最好全部用英文写...

于 2014-02-25T15:12:24.723 回答
0

这实际上只是一个维护问题,如果您的所有开发人员都知道希伯来语那么您很好,如果您将项目的一部分外包,使其开源,或者聘请外国开发人员,那么英语几乎是通用语言。

于 2010-04-25T15:45:22.273 回答