变量命名和使用另一种语言的团队成员

发布于 2024-07-26 01:10:30 字数 253 浏览 3 评论 0原文

我与印度的几位开发人员合作,我们最大的困难之一是他们的变量命名。 起初我非常沮丧,无法理解为什么他们不正确地命名事物(是懒惰吗?)但是,我意识到他们可能不习惯命名变量,因为他们读取的所有代码都在英语,以及他们读到的英语单词对他们来说几乎没有意义。 现在看来这是显而易见的,但如果你不能充分理解英语,就不可能很好地命名变量。

您将如何与讲外语的团队成员一起改进命名实践?

抱歉,如果这有点主观,我已将其标记为社区维基。

谢谢!

I work with several developers in India and one of our biggest difficulties is their naming of variables. At first I was very frustrated and couldn't understand why they wouldn't just properly name things (was it laziness?) However, I realized that they probably aren't used to naming variables, becausee all of the code they read is in English, and the English words they read have little or no meaning to them. It seems obvious now, but it is impossible to name variables well if you cannot understand English adequately.

How would you work towards better naming practices with a foreign speaking team member?

Sorry if this is a little subjective, I have marked it community wiki.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

被翻牌 2024-08-02 01:10:30

改变对团队成员的要求——他们必须对书面英语有足够的理解。

编辑:针对 Bill K 的评论,在我看来,处理不良沟通问题的成本并未计入节省计算中。 不,我从未与海外开发者合作过,但我确实与 2 位非英语母语人士合作,有时与他们的沟通会有点慢,尽管他们都在美国生活了 20 年。

另外,我没想到我的答案是最有用的。 只是想表达一个观点。 如果您不雇用某人在您的办公室工作,那么您为什么要雇用他们从地球另一端为您工作呢? 即使您通过代理机构,您也间接雇用了每个为您的代码工作的开发人员。

我的经验是,在开发人才方面,廉价可能会付出高昂的代价。

Change the requirements for members of your team -- they must have an adequate understanding of written English.

Edit: in response to Bill K's comment, it seems to me that the cost of dealing with poor communication problems isn't factored into the savings calculations. No, I've never worked with overseas developers, but I do work with 2 non-native English speakers and communication goes a little slower with them sometimes, even though they've both lived in the USA for 20 years.

Also, I wasn't expecting my answer to be the most useful. Just trying to make a point. If you wouldn't hire someone to work in your office, then why would you hire them to work for you from the other side of the globe? Even if you're going through an agency, you are indirectly hiring every developer that works on your code.

My experience has been that when it comes to development talent, being cheap can be quite costly.

海风掠过北极光 2024-08-02 01:10:30

您可以将“变量命名”作为每次代码审查的主题。 这将是一个很容易讨论的事实议程项目。 您可以使用讨论来衡量他们是否理解他们想要实现的目标。

You could make the 'variable naming' a topic for each code review. It would be a matter of fact agenda item that could be easy to discuss. You could use the discussion as a gauge as to whether they understand what they are trying to achieve.

夏尔 2024-08-02 01:10:30

如果每个人都说同一种语言,并且您不会将代码出售给另一家公司,那么用他们的母语编写代码就可以了。

如果每个成员使用不同的语言,则代码应为英语。
尝试为应用程序中最常用的单词制作一本字典,以便每个人都可以检查。 必要时选择英语水平较高的人进行翻译。

当某些单词看起来错误时,您始终可以重构。

If everybody speaks the same language and you will not sell the code to another company then it is ok to write the code in their native language.

If each member speaks a different language the code should be in English.
Try to make an dictionary of the most common words used in the application where everybody can check. Choose someone with more English skills to translate when is necessary.

And you can always refactor when some word looks wrong.

橘亓 2024-08-02 01:10:30

大多数开发人员应该对技术英语有一定的了解(毕竟,大多数语言的 API 都是用英语编写的)。 因此,英语似乎是一个不错的选择。 变量通常不会有非常困难的名称,例如 xCounter、isXYZ 等。如果它们很难命名,那么我会将其视为一个确定的标志,表明该变量声明的抽象级别不是正确的那一个。

人们可能会建议本地化变量名称。 我发现这真的很困难,尤其是现在,代码通常被位于其他大陆的人、海外收购的公司等获取。

必须给予一些东西☺

Most devs should have a reasonable understanding of technical english (after all, API's in most languages are written in english). Therefore, english seems a good choice. Variables won't typically have very difficult names e.g. xCounter, isXYZ, etc. And if they are difficult to be named, then I would take that as a sure sign that the the level of abstraction in which that variable is being declared on is not the right one.

One might propose to localize variable names. I found that really difficult, more nowadays when it's typical for the code to be taken by people located in other continents, companies acquired overseas, etc.

Something gotta give ☺

樱花坊 2024-08-02 01:10:30

我无意批评,但我有一个真正的问题......如果他们的英语不够流利来命名变量,他们如何足够流利地理解基于英语的业务领域模型,更不用说设计了并构建一个软件产品来解决该领域的现实问题?

I don't intend to be critical, but I have a real question... If they are not fluent enough in English to name variables, how are they fluent enough to understand an English-language-based business domain model, much less design and construct a software product that solves a real-world problem in that domain?

北城半夏 2024-08-02 01:10:30

找到与您一起工作的一位懂一点英语的开发人员,并让他们都由他来运行变量名称?

Find the one developer you're working with over there who knows some English and have them all run variable names by him?

陪我终i 2024-08-02 01:10:30

也许让他们用母语描述性地命名变量,然后使用翻译器将它们转换为英语? 甚至可以添加标记并运行预编译器来进行自动翻译? 只是一个想法。

Maybe have them name the variables descriptively in their native language and then use a translator to convert them to english? Might even be able to add markup and run a precompiler to do the auto translation? Just a thought.

往事风中埋 2024-08-02 01:10:30

我不确定具体问题,即变量名称没有描述性,或者它们使用的变量名称不是英文,变量命名风格不一致等。无论哪种方式,您都可以尝试建立详细的编码标准,也许可以使用代码审核或审查以执行它们。 例如:

  • 不允许使用“temp”作为局部变量的名称
  • 变量的命名必须使变量的用途显而易见
  • 始终使用一致的风格来命名变量(例如驼峰命名法)

关键是发布这些规则并在整个组织中强制执行它们。

I am not sure about the specific problem i.e. variable names are not descriptive, or are they using variable names aren't in English, variable naming style is inconsistent etc. Either way, you can try to establish detailed coding standards and perhaps use code audits or reviews to enforce them. For example:

  • Using "temp" as the name of local variables is not allowed
  • Variables must be named so that the purpose of the variable is obvious
  • Always use a consistent style to name variables (e.g. Camel Case)

The key would be to publish these rules and enforce them for the entire organization.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文