你最具争议的编程观点是什么?

这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。

这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。

那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。

请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。

当前回答

Variable_Names_With_Bloody_Underscores

或者更糟

CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES

应该在全球范围内清除……与偏见!CamelCapsAreJustFine。 (全局常数不承受)

GOTO语句仅供11岁以下的开发人员使用

任何不支持指针的语言都名不副实

.Net = .Bloat 微软网站开发的最佳范例(无表情web 2) 是缓慢膨胀的最好的例子cr@pw@re曾经写过。 (可以试试Web Studio)

回应: 好的，让我来谈谈下划线的问题。从你提供的C链接:

-全局常量应该全部大写，用“_”分隔符。我实际上同意这一点，因为这太明显了

-以NetworkABCKey为例。注意ABC中的C和调音中的K是如何混淆的。有些人不介意这一点，有些人只是讨厌它，所以你会在不同的代码中发现不同的策略，所以你永远不知道该如何调用某个东西。

我属于前者。我选择名字非常谨慎，如果你不能一眼看出K属于Key，那么英语可能不是你的第一语言。

C函数名在c++项目中应该有很少的C函数。对于C函数，使用GNU约定的所有小写字母，以'_'作为单词分隔符。

的理由

* It makes C functions very different from any C++ related names.

例子

int some_bloody_function () ｛｝

这些“标准”和惯例只不过是随时间而传下来的任意决定。我认为，虽然它们有一定的逻辑意义，但它们使代码变得混乱，使一些本应简短而易于阅读的东西变得笨拙、冗长和混乱。

C被采纳为事实上的标准，不是因为它友好，而是因为它无处不在。我可以用一种语法友好的高级语言用20行代码编写100行C代码。

这使得程序流易于阅读，并且我们都知道，在一年或更长时间后重新访问代码意味着要到处跟踪面包屑。

我确实使用下划线，但只对全局变量，因为它们很少，而且它们很明显。除此之外，一个经过深思熟虑的CamelCaps()函数/变量名还没有让我失望!

2009-01-03 10:27:29

其他回答

这是有可能保护您的应用程序。

每次有人问如何防止用户盗版他们的应用，或者如何保护应用不受黑客攻击，答案都是不可能的。无稽之谈。如果你真的相信这一点，那就不锁门(或者直接把门拿出来!)。也不用去看医生了。你是凡人——试图治愈疾病只是推迟了不可避免的事情。

仅仅因为有人可能会盗版你的应用或入侵你的系统，并不意味着你不应该试图减少这样做的人。你真正要做的是让入侵者/海盗需要比他们愿意做的更多的工作。

就像在你的房子上安装门闩和ADT可以防止窃贼，合理的反盗版和安全措施可以让黑客和海盗远离你的路。当然，他们越想闯入，你就越需要安全保障。

2009-03-17 13:59:16

web的MVC应该比传统的MVC简单得多。

Traditional MVC involves code that "listens" for "events" so that the view can continually be updated to reflect the current state of the model. In the web paradigm however, the web server already does the listening, and the request is the event. Therefore MVC for the web need only be a specific instance of the mediator pattern: controllers mediating between views and the model. If a web framework is crafted properly, a re-usable core should probably not be more than 100 lines. That core need only implement the "page controller" paradigm but should be extensible so as to be able to support the "front controller" paradigm.

下面是我自己的框架的核心方法，它成功地应用于一家财富100强的网络硬件制造商为一家财富50强的媒体公司生产的嵌入式消费设备。我的方法被一位前Smalltalk程序员和Oreilly一本关于有史以来最杰出的Java web框架的书的作者比作Smalltalk;此外，我已经将相同的框架移植到mod_python/psp。

static function sendResponse(IBareBonesController $controller) {
  $controller->setMto($controller->applyInputToModel());
  $controller->mto->applyModelToView();
}

2009-01-02 14:53:48

不应该允许非开发人员管理开发人员。

更正:没有开发经验的员工不应该被允许管理开发人员。

2009-01-05 14:12:35

依赖管理软件弊大于利

我在Java项目中工作过，其中包括超过100个不同的库。在大多数情况下，每个库都有自己的依赖项，而这些依赖库也有自己的依赖项。

像Maven或Ivy这样的软件应该通过自动获取每个库的正确版本，然后递归获取其所有依赖项来“管理”这个问题。

问题解决了，对吧?

错了。

下载库是依赖项管理的简单部分。困难的部分是创建软件的心理模型，以及它如何与所有这些库交互。

我不受欢迎的观点是:

如果你不能口头解释，在你的头脑中，你的项目中所有库之间的基本交互，你应该消除依赖直到你可以。