35

去年我正在对一个团队成员的代码进行故障排除，它缺少缩进和注释。我正在和他谈论这件事，告诉他这不是一个好主意，但他被冒犯了。他比我聪明，或者当然受过更多教育。

从那以后我发现他申请了微软，当他们让他做一个双向链表实现时，他写了没有缩进或评论，说他没有时间担心风格。（这是一封电子邮件提交，需要 2 小时才能完成）

微软没有给他回电话……你觉得他们怎么回应，你会怎么回应？

微软的任何人都可以建议他们在这种情况下会做什么？

4

45 回答 45

54

没有程序员是一座孤岛。有一天，有人将不得不阅读他们的代码。之前在这里重复过很多次：

始终编​​写代码，就好像最终维护您的代码的人将是一个知道您住在哪里的暴力精神病患者。 ——马丁·戈尔丁（也许）

也就是说，如果他们的风格足够好，那么在雇用程序员时还有其他更重要的事情需要评估。但是，如果他们完全拒绝使用注释或试图让他们的代码对其他人可读，那就是破坏交易了。

于 2008-09-24T15:42:12.427 回答
16

不关心风格的开发人员就像不关心颜色的艺术家、画家。

于 2008-09-24T16:21:49.757 回答
9

几乎没有不评论的借口，也没有不缩进的借口。缩进由大多数最好的编辑处理，评论应该成为 MS 可能想雇用的人的第二天性。

它们当然都是人们进入的学科（无论是自然地还是通过学校教育），所以没有表现出来，也许表明缺乏纪律，或者，至少努力表达它。

编辑：链接列表需要 2 小时？！我明白他的意思是现在......在剩下的一小时五十分钟内适应所有格式会非常困难！（我只是在玩——我认为面试不仅仅是一个链接列表！）

于 2008-09-24T15:38:58.533 回答
9

代码由三个实体读取：计算机、程序员和最终的维护者。
样式和格式与计算机无关，可能对程序员很重要，但对维护者肯定很重要，他们必须尝试理解程序的功能。
拒绝通过使代码可读来适应其他开发人员是不尊重的。
使用有意义的变量名和注释创建有组织的代码是对其他任何阅读它的人的一种常见礼貌形式。

于 2008-09-24T15:41:49.760 回答
8

编程风格非常重要。评论更是如此。即使你一个人在自己的项目上工作，你也应该注释你的代码，因为一个月后你不会记得你做了什么以及为什么。如果你在一个团队中工作，那么不清楚、未格式化和未注释的代码可能会导致灾难。

于 2008-09-24T15:39:16.473 回答
3

没有标识和可读风格的编程就像写一本没有段落和分页符的书。这只是一大堆文字，我永远不会花时间去理解它。

我完全理解微软的反应——我也不会给他回电话。

于 2008-09-24T15:39:07.440 回答
3

我会解雇他，但幸运的是，他永远不会真正被雇用。

我宁愿他花 2 个小时编写干净、几乎可以正常工作的代码，而不是让他把一些有效的东西拼凑在一起。

编程风格很重要，尤其是在团队合作时。
在支持由几个人编写的遗留应用程序时，它变得至关重要。

作为专业人士的一部分，而不仅仅是一些脚本小子，关心代码。这是关于意识到其他人会在六个月后阅读这段代码（甚至是你！）。因此，您应该使其尽可能易于维护。

于 2008-09-24T15:44:39.800 回答
3

我会尝试奉承他，告诉他因为他可以做比其他程序员更复杂的事情，所以他需要对它进行评论并很好地布局，以便我们其他人能够理解它。

我想如果有人在面试中对我表现出这种态度，我会非常仔细地考虑雇用他。我敢肯定，即使是微软也需要团队成员。

于 2008-09-24T15:37:02.267 回答
3

格式化不需要任何时间。这是一个糟糕的借口。为了暴力精神病患者，当你完成后让你的编辑器格式化它。

于 2008-09-24T16:29:23.513 回答
2

在面试中，不缩进或评论你的代码是完全可以的。事实上，如果你有时间这样做，我会感到惊讶——我们通常不会给那么多时间。

但是，作为一般做法，我完全希望您缩进代码并在必要时添加注释。事实上，我们的构建机器会在代码中包含制表符而不是空格等微小的事情上失败。

代码可读性很重要。就像没有人喜欢阅读一大段（而不是小的、结构化的段落）一样，没有人喜欢阅读一大段没有格式的代码。

于 2008-09-24T15:38:52.263 回答
2

我很难相信有人会认为没有缩进是个好主意。太傻了，如果他在采访中为我这样做，我也不会给他回电话。

评论有点灰暗，伟大的代码在很大程度上是自我记录的。如果您编写了出色的代码，那么注释应该只在实际情况非常复杂且难以理解的地方出现。

于 2008-09-24T15:39:22.307 回答
2

我想知道任何体面的程序员如何在没有缩进的情况下编写代码，无论是在 IDE、vi、记事本、白板上还是在便利贴上完成。缩进代码应该是自然而然的。如果他上交的内容看起来像这样，我不会给他回电话（我只是从 Wikipedia 复制实现，重点是缺少缩进）：

struct Node{
data
next
prev
}
struct List{
Node firstNode
Node lastNode
}
function insertAfter(List list, Node node, Node newNode) {
newNode.prev := node
newNode.next := node.next
if node.next = null
list.lastNode := newNode
else
node.next.prev := newNode
node.next := newNode
}
function insertBefore(List list, Node node, Node newNode) {
newNode.prev := node.prev
newNode.next := node
if node.prev is null
list.firstNode := newNode
else
node.prev.next := newNode
node.prev    := newNode
}
function remove(List list, Node node){
if node.prev = null
list.firstNode := node.next
else
node.prev.next := node.next
if node.next = null
list.lastNode := node.prev
else
node.next.prev := node.prev
destroy node
}
于 2008-09-24T17:54:42.497 回答
2

当然，风格很重要。尤其是在涉及缩进和空格之类的事情时。代码应该很容易被人阅读，因为这是一个人以后必须维护该代码。代码的可读性越高，维护起来就越容易，代码的质量最终会变得越高。

有一个心理因素会影响代码风格。当代码“丑陋”且难以阅读/理解时，您希望减少对该代码的所有权，因此个人激励您尽力而为的动力就会减少。随着代码变得更具可读性/易于理解，您对所做的工作感觉更好，并希望获得更多所有权。您对代码的所有权越多，编写更好的代码对个人来说就越重要。

至于微软如何回应，我会以完全相同的方式回应。我认为他们没有给他回电话的回应可能是完全合理的（除了缺乏代码风格之外，可能还有其他因素，尽管我确信这是一个贡献者）。

于 2008-09-24T15:48:21.023 回答
2

好吧，事实是，它寿命最长的软件生命周期阶段是维护。在那段时间里，人们主要阅读和分析它，试图修复它、重用它、增强它等。这是保持它易于阅读和理解的最佳理由。有人说他没有时间担心明显影响可读性的风格，这只是表明他作为软件工程师的不成熟。或者可能根本不了解软件生命周期。

于 2008-09-24T15:49:51.097 回答
2

编程风格非常重要。干净的代码令人赏心悦目，并提高了程序的可维护性。因此，它与程序本身的质量和架构直接相关。

即使在一种强制缩进的语言中，也可以用糟糕的风格打破一切。因此，糟糕的风格可能不是缺少缩进或注释。实际上，我很少使用注释，我更喜欢文档字符串和整体编写更好的文档。如果您确实看到其中有一些需要修复或想知道的地方，我会将注释与您在代码中散布的小注释相关联。

我宁愿把不好的风格看作是不让编程语言为你做一些事情。在一两个地方正确、干净地编写宏确实是好风格而不是坏风格。

于 2008-09-24T15:51:10.580 回答
2

代码风格很重要还有另一个原因。它可以作为确定程序员专业程度的代理。正如孔雀的尾羽展示了他的健康和活力（一个不健康的有机体将无法投入稀缺的资源来建造一条长毛绒的尾巴），程序的风格可以揭示很多关于编写它的人的信息。

当我看到格式错误、命名约定不一致和注释稀少的代码时，我会避开它，不仅因为这样的代码本质上不可读，而且因为代码很可能在这个麻烦的表面下隐藏着更严重的问题。

于 2008-09-24T16:02:44.873 回答
1

“他没时间担心风格……” 难怪他们没有给他回电话。他甚至没有参加面对面的采访，他已经拒绝做对他的要求？这是不通过任何专业面试的好方法。

风格是我们所做的一切所固有的。这不是覆盖。它不是一个附加组件。这不是福利。无论我们使用与否，它都存在。事物——程序、产品、你有什么——并没有因风格而得到改进；他们通过拥有良好的风格得到改进（与之相反的只是拥有糟糕的风格）。

从非常注重技术的角度来看，人们的问题是，如果没有任何审美兴趣或欣赏来平衡它，就会认为“风格”是程序员不使用的工具；“风格”的意思是“留给 UI 或营销人员”。这根本不是真的。在努力做到最好的时候，你必须改进工作的各个方面。这不仅意味着执行，还意味着演示。

人类是视觉导向的生物。我们根据它们的外观来选择东西（漂亮女孩！闪亮的包装！）。

在明确宣布他没有时间追求风格时，他基本上给人的印象是他不是微软正在购买的闪亮包装。通过如此明显的预先道歉，他还让评估者更清楚地看到了他缺乏缩进和评论（尽管我相信他们不会仅仅因为他缺乏评论而雇用他）。

于 2008-10-09T20:50:01.873 回答
1

编码风格相当重要。大多数主要的开发公司都有一个文档，其中定义了所需的命名约定、注释指南以及其他与代码样式和架构指南有关的小事。

所有这些都非常好，有助于营造一种工作环境，在这种环境中，团队成员可以对其同事的代码外观抱有良好的期望。

只要确保它不会降低到经理级别，迫使开发人员从这样的代码审查中进行更改：

if( someBool() ) doSomething();
else doNothing();

像这样的事情仅仅是因为他们“感觉”它是“更好”的风格：

if( someBool() )
{
    doSomething();
}
else
{
    doNothing();
}

只是请有比个人偏好更好的理由来满足风格要求，我们都可以更快乐。

于 2008-09-24T17:16:26.817 回答
1

如果您在缩进代码上花费的时间比实际编写代码的时间多，那可能是个问题。但是整个解决方案的源代码样式、约定和一致性很重要。

这就是为什么我依靠工具来做到这一点。Resharper 允许我通过按 Ctrl+F、E 组合键来重新格式化所有代码。

于 2008-09-24T15:39:38.063 回答
1

如果想在编写完源代码后丢弃它，可以忽略样式。这适用于您为任务制作的快速脚本，实际上只运行一次。另一方面，本应仅运行一次的任务将在以后重用的频率。

重用可能没问题，但以后很难理解会发生什么。如果你以后想修改代码，你会失去一些风格。

适当的样式有多重要，取决于您将使用和修改代码多长时间以及将使用多少代码。

如果您在团队中工作，请谈谈应该应用哪些样式。

于 2008-09-24T15:42:30.677 回答
1

您的朋友需要正确处理他的优先事项，在我看来，我相信微软会比您认为的更关心。

于 2008-09-24T15:43:46.370 回答
1

据说一个项目80%的生命周期都花在了维护上。如果您的代码不可读，那么您肯定会为维护您的代码的人浪费大量时间，并且不可避免地会让他们对您产生邪恶的想法。

不过，据我所见，大多数程序员团队（有时甚至是整个公司）都有一个文档或其他东西来解释他们所遵循的代码约定和样式。因此，在您在那里工作的第一天，很容易将他们的规则输入到您的 IDE 中，并让它自动格式化您的代码，这样您就不必担心它了。更好的是，您可能会找到愿意“导出”他们的 prefs 文件的人，因此只需单击几下，直到您在该公司编写的所有代码都被完美格式化。

话虽如此，您并不总是可以访问这些特定于团队的约定（例如，在采访中）。遵循一些有意义的基本约定总是一个好主意。根据您的语言，一个好主意是谷歌“您的语言代码约定”并阅读基础知识。在面试的情况下，重要的是你遵循一些基本的指导方针，并有一个你坚持的格式风格。如果你在同一行的“else”语句后面加上括号，然后在下一行写下一次，你可能是在告诉面试官你不够关心和/或你没有足够的关心体验一种方式已成为您的习惯。

于 2009-02-09T17:23:52.607 回答
1

这就是需要编码标准的原因。团队应该遵守标准，即使这不是他们通常的编码方式。他可以学到很多东西来维护别人的烂摊子，就像我一样。7000 行 C++ 以 C 风格编写，分为 7 个方法（大多数方法是 600 多行），许多包含转到方法内标签的一行宏。还有很多一行 if 语句，以及添加到这些和其他方法调用末尾的宏，因为您必须滚动才能看到它们。再加上可怕的变量名和不一致的括号样式，你会得到一个无法维护的混乱。积极的一面是它运作良好，我们多年来一直依赖它。

于 2008-09-26T17:55:52.517 回答
1

在我看来，说风格不重要就像说拼写不重要一样。如果您的风格（或缺乏风格）导致可读性问题，那么团队将很难处理此人正在编写/编辑的文件。

同样，如果程序员没有花时间在注释块、函数名称等中正确拼写单词……这将导致其他开发人员试图破译代码时出现问题。我总是问自己，“自己，如果你在1周内看这个，你会明白吗？如果你明年再看，你还会明白吗？” （或者至少能够阅读文档/评论来记忆）。

对我来说，当您谈论将花括号放在 if 块的下一行而不是将其放在条件语句的末尾时，样式并不重要......只要它符合您的编码标准，在内部是一致的，并且团队的其他成员使用相同的方法；话虽如此，我觉得如果它影响代码的可读性，风格就非常重要。

由于 MS 是一家如此大的公司，他们可能正在寻找既能成为问题解决者又能成为团队成员的人。对我来说，那些说他们“没有时间做造型”的人会被认为不是团队合作者。

好问题！

于 2008-09-24T17:42:56.473 回答
1

我一直觉得你可以指望的一件事是，在你离开后查看你的代码的人会认为你是个白痴。关键是最大化从第一次查看代码到他们做出决定之间的时间。

良好的格式是增加 N 的一种方法，有用的评论是另一种方法。

于 2008-09-24T15:53:15.830 回答
1

这完全取决于谁是源代码的目标受众。正确答案是“其他程序员”（维护者等）。你的同事认为这并不重要，我完全理解为什么 MS 没有雇用他。如果有大公司愿意雇用他，我会感到惊讶！

我记得在“ACM 通信”上出现了一篇题为“排版风格不仅仅是装饰”的旧文章，该文章对良好格式化代码对生产力的影响进行了实验。

他们带了一群程序员，给他们一个测试来给他们排名。然后他们将小组分成两组，两组相同的任务：修改一个软件以添加一些功能。

只是第一组有一个格式很好的源代码可以处理，而其他组有一个相当混乱的相同代码版本。

他们再次测量了他们的生产力，最终结果是第一组中最差的程序员比第二组中更好的程序员得分更高。

从那时起，我总是付出额外的努力，使我的代码清晰易读。

对于那些对该主题感兴趣的人，我建议阅读有关文学编程、有意编程和其他相关概念的内容。

于 2008-09-24T15:54:01.167 回答
1

关于“风格”（我宁愿称之为“格式”）：这在很大程度上是个人品味的问题，但是在团队中工作非常重要，定义一些每个人都必须遵循的指导方针，如果需要，可以改变他/她的个人喜好（在在 Eclipse 中，我们导出格式化程序配置，并通过按键将文件格式化）。很快每个人都会习惯标准，阅读代码也不会那么疲劳。

关于评论：我更喜欢为我的方法命名，但对最晦涩的部分的两个评论是强制性的。

于 2008-09-24T16:03:07.680 回答
1

您可以争辩说，编写良好的代码不需要注释，或者至少不需要很少的注释。但是没有缩进是不可接受的。编译器确实关心（在大多数情况下），但维护代码的人关心。

于 2008-09-24T16:07:59.900 回答
1

我不介意他没有立即发表评论。但是缩进很重要。当您编写代码时，它很少会在一次打字狂潮中线性出现。

不，即使在测试和可能调试代码之前，通常也需要进行大量编辑，并且能够清楚地看到代码结构很重要。

这让我想起了我职业生涯早期发生的一件事。我是一名初级程序员，另一位初级程序员向我寻求一些关于他的代码的帮助。我们当时正在使用 Pascal。他的代码一团糟。我以前见过没有缩进的代码，但从未见过随机缩进的代码。没有办法跟随它。

所以，我做的第一件事就是修复缩进。他得意地说。“我认为这不会解决它！”。我回头看了看代码。这个错误现在很容易发现，所以我只是指着它走开了。

于 2008-09-24T16:30:26.303 回答
1

嗯，有生活，然后有采访。

问问你的朋友——他会穿着破烂的牛仔裤和肮脏的 T 恤参加面试吗？

他在采访中的任务（无论采用何种形式）是为了给进行采访的人留下深刻印象。给他们留下深刻印象，让他们得到一份工作。

所以如果申请程序员的工作，为什么这个人会提交“破烂牛仔裤和肮脏的T恤”代码？

我真的希望这个人对编码风格、注释和空白有一些线索。在那种情况下，他判断面试官更关心“正确”而不是“善良”（我的解释）。

但是 - 考虑到任务（链表？这对程序员来说应该很容易），看起来任务不仅仅是代码的“正确性”。

我怀疑面试官正在寻找很多东西，包括良好的编码实践（“忘掉”糟糕的编程实践比一开始就做好1000倍难）。面试官可能也在寻找一些东西来表明主动性、良好的假设能力，甚至可能是创造力或创造性。

例如，有很多方法可以编写“正确”的链表，但有些方法（如使用递归）被认为比其他方法更“优雅”。

我怀疑你的朋友在这次采访中的几个层面都没有达到标准。

-R

于 2008-11-04T17:41:21.703 回答
1

我倾向于认为编码风格实际上更多地反映了我们是那种软件程序员。

如果我们编写草率的代码而不关心这个世界，是的，那么我会认为我们表现出一种我们不尊重其他团队成员的态度，但是如果我们花时间以一种可以理解的风格编写并且有意识地尝试确保我们的代码清晰易读且结构正确，那么我们确定我们对团队有尊重的态度吗？

风格更多的是关于我们是谁，而不是关于我们所知道的。

于 2009-07-20T11:41:14.747 回答
0

IDE、编程编辑器和代码重新格式化程序就在那里。商店应采用适合其目的的风格，并根据需要使用重新格式化程序。

简而言之，分隔符的缩进和放置不再是什么大问题了。

于 2008-09-24T20:39:32.117 回答
0

强调可读性很重要的风格。极其重要。

许多程序员争论注释的频率和使用，但大多数人认为它们是必要的。

于 2008-09-24T15:43:52.577 回答
0

我不希望被采访者评论他们的代码（假设他们是在采访中当场编写的）。如果我采访的是有经验的人，但他们没有缩进代码，那么这肯定会对他们不利。我不希望缩进是完美的，或者是我喜欢的风格，或者其他任何东西。但最好是缩进的。这是编写代码的一部分。

如果我正在招聘一个没有经验的人（我通常是），那没关系。但我也不会要求他们写一个双向链表。

于 2008-09-24T15:45:22.467 回答
0

我认为缩进是自然而然的。我只是这样做，每次我自动写一些东西。不这样做会让我感到困惑。

于 2008-09-26T17:26:09.263 回答
0

如果没有缩进，我什至不会阅读他的代码，更不用说标记它。没有时间是一个可怕的借口，在你输入的时候缩进一段代码需要几秒钟的时间……更不用说大多数编辑器自动缩进的事实。评论也许他可能已经没时间了，但即便如此，这仍然是一个非常糟糕的借口。对您刚刚编写的一段代码进行注释并不需要很长时间。

于 2008-09-24T18:01:35.743 回答
0

在面试的编码测试中不显示评论就像参加考试并且没有显示任何工作！

当然，评论应该是对程序员策略和思维的洞察之一？

于 2008-09-25T00:27:20.743 回答
0

我开始注意到代码就像一个蓝图。一个精心策划、美丽、精湛的豪宅设计蓝图将是结构良好且有用的。代码应该是一样的。

于 2008-09-25T00:35:08.883 回答
0

我认为我们被评判的大部分是外观或风格，很难看到没有缩进或注释的一段代码并看到其中的天才。大多数人会认为它太复杂了，让我们重写它。

在提交之前，我可能会阅读 Microsoft 代码样式指南。就像你不会带着脏衣服去面试一样，我不会提交未缩进的不可读代码

俗话说....编写新代码就像性，快速而令人兴奋...维护代码就是照顾因性而产生的孩子，漫长，困难，有时非常令人沮丧...。哦，有益而有趣也...

于 2008-09-24T15:49:57.523 回答
0

我认为评论是一把双刃剑，因为过多的评论肯定会导致可读性降低。杰夫为此写了一篇出色的文章

相反，缩进永远不会伤害并大大增加可读性。这就是为什么这么多人喜欢 Python 的重要原因之一。

于 2008-09-24T15:58:55.880 回答
0

编程风格不仅限于代码识别和注释。
代码标识确实对代码的易懂性非常重要。我从未见过易于阅读的未缩进代码:)。
同样非常重要的是代码是不言自明的，只有当实现由于各种原因变得神秘或代码没有清楚地反映作者为什么这样写时，才应该使用注释。我看到很多过度注释的代码，我可以告诉你，几乎每一行都看到注释就像阅读侮辱性的页面一样。
无论如何，我怀疑微软拒绝你的同事只是因为他没有评论双链表的实现。

于 2008-09-24T16:01:55.217 回答
0

我尝试使用 IDE 格式化样式。因此，我们避免了关于如何编写代码的新的和无聊的定义，因此，由于缩进和格式的差异而导致不必要的合并。

即使是最愚蠢的代码，文档也是强制性的。最好有一个模板来在代码中生成文档行。团队内部的标准化和组织协议是最好的风格。

于 2008-09-24T16:17:54.400 回答
0

上面已经提到了这方面的几种观点。基本上，样式和注释有助于可维护性。

代码是为程序员（包括你自己！）而不是为编译器编写的。如果我们从不需要阅读代码，只需用六角键盘将其打入（就像真正的程序员一样！）并完成它！:-)

但几乎从来都不是这样。在代码的整个生命周期中，编译器可能会花费几秒钟的时间来处理它。但是程序员可能会花几天时间。如果难以阅读或理解，这些天数可能会增加到数周。应该努力使代码自我记录，但不要依赖它。曾经。

缩进显示控制流。一堆没有缩进的行可能有控制流，但这意味着你必须阅读每一行来检测它：

if(someSituation) somethingElse++;

对比

if(someSituation)
    somethingElse++;

第二个版本在视觉上跳出来。您无需阅读和理解代码即可看到做出的决定。在扫描某些代码以快速找到某些内容时非常重要。

大多数 IDE 和编程编辑器都允许您立即缩进一段代码。这非常容易，您应该这样做只是为了确保您没有悬空的“else”或其他一些操作员顶空问题。缺乏缩进是很难证明的。

评论也很重要。如果注释与代码不匹配，那么它们都是错误的（我不记得是谁先说的，但他/她已经死了！）。

我在第一次布局代码时放了一个注释块，然后编码和调试，然后再次检查注释。我可能会发现我误解了问题（更改注释）或者我可能实施了错误的事情（更改代码）。或者我可能会发现我重新实现了一个库函数（暂时将其全部注释掉，以防我需要做一些奇怪的事情）并调用该函数。

有时您必须使用名称错误的库函数。您可以说 RTFM 并继续前进，或者您可以输入摘要评论并为下一个程序员（可能在 6 个月内）节省一些精力。

// This allocates space for the message queue and initializes
// some OS overhead. All that remains after this is adjusting
// priority and content and then send the message.
prepareMessage(&myMessage);

此外，如果您花了 2 天时间解决一个错误并在代码中进行了一些小的更改，那么很有可能在设计时更改并不明显。否则它本来就在那里！因此，需要发表评论以防止将来有人将其更改回“显而易见的”实现。

memset(&myStatus, 0, sizeof(myStatus));

// The size member must be set before getting current values.
// This is used by library function GetCurrentStatus() to infer
// a version of the status structure.
myStatus.length = sizeof(myStatus);

GetCurrentStatus(&myStatus);
于 2008-09-30T18:54:35.070 回答
-1

当谈到申请工作时的编码时，我认为解雇一个没有评论/缩进他编写的代码的候选人有点苛刻，除非他被明确要求这样做。

于 2008-09-24T15:41:52.817 回答
-3

不

编程风格绝对不重要。重要的是可维护性和可读性。

为确保您保持在正轨上，您必须使用同质且可读的代码格式来强制您的团队。哪一个无关紧要：你不能取悦任何人，并且有软件可以更改代码格式。

如果一种语言接受多种范式，不要试图只选择一种。只要代码得到很好的注释并且可以完成工作，谁在乎这个人使用的是函数式还是命令式的风格？

于 2008-09-24T15:50:13.530 回答