-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
反馈(报错、警告、调试等)信息的风格与编程语言一致化 #1
Comments
嗯嗯。 》 确定用户需要掌握的概念 》反馈信息中的术语中文化 》即便与编程语言的语法不完全相同,至少风格上可以逐步接近 |
随着语言功能(feature)的增加,报错信息的内容估计会逐渐增多,其中包含的各种术语也是。 |
好的 |
@nobodxbodon 其实在编程语言报错信息翻译方面,你有没有了解过的研究? (尤其是目前直接的翻译晦涩难懂,不知道有没有从用户角度出发的报错信息研究) |
@UltimatePea 之前看到的一些报错信息相关论文摘要:
个人最近在尝试尽量不用术语、与编程语言语法一致的反馈信息设计:详见“某语言”设计帖。其中通过“获取最近语义”支持不符内置语法的用户输入,以省去语法相关的反馈信息。 另一种设计,是通过严格限定各语法要素的组合方式来尽量减少代码的语法问题,比如 Scratch。 各种设计都需将用户调试纳入考虑。即便像 Scratch 也需 各种调试技巧。个人感觉语言设计与调试手段是互相影响的,而报错信息与调试息息相关。 说回到报错信息,现在市面上的编程语言往往是一句话,但实际上详细解释相关内容可能要一大段(不妨找些具体例子讨论)。这往往意味着将语言内部运行机制暴露给用户。以API设计作对比,最好报错内容尽量与API业务相关,而不需将API内部实现暴露给用户。 也许这方面可以借鉴UX的报错信息,如 Avoid jargon and developer speak一节;或是web API的错误信息,如 此文。 |
一个python报错信息例子: My favorite terrible Python error message,“TypeError: object() takes no parameters”。 对新手用户来说几乎是无法一眼理解的,其背后牵涉到了许多python类型系统机制细节。 |
根据最近的实践来看,报错信息确实是一个很复杂的问题。 我自己在编程的时候很多报错信息都要看半天是什么意思,程序写不对就会报错。 目前我能想到的方法是根据社区的反馈逐步改进报错信息。所以这一块我们要非常重视社区给予的反馈。 |
感谢讨论和建议,也祝您虎年快乐! |
很高兴看到本项目以实用语言为目标,也许值得在早期将此方面纳入考虑。在文言提过 相关issue。
实践中用户很多耗时在理解错误信息和排错。各种反馈信息在划出语言功能边界的同时,也决定了对用户暴露的实现细节、用户需要了解的相关术语。
对使用自然语言语法的编程语言,一个优势是可以将反馈信息的风格与编程语言尽量一致化,个人认为可以提升用户体验,也是在现有编程语言中极少看到的。
实施上能想到的:
The text was updated successfully, but these errors were encountered: