C(或c++)应该是第一种编程语言

第一语言不应该是简单的，它应该是建立学生的思想，为严肃的计算机科学做准备的语言。 C语言是完美的，它迫使学生考虑内存和所有低级别的东西，同时他们可以学习如何构造代码(它有函数!)

c++有一个额外的优势，它真的很糟糕:)这样学生就会明白为什么人们必须想出Java和c#

应该要求所有项目经理都有编码任务

在我工作过的团队中，项目经理实际上是一个程序员，他非常了解代码的技术问题，足以完成编码任务，所做的决策缺乏沟通脱节，而在项目经理不参与代码的团队中经常发生这种情况。

大于运算符(>，>=)应该被弃用

我试着用“小于”而不是“大于”的偏好编码了一段时间，它卡住了!我不想回去，事实上，我觉得在这种情况下，每个人都应该按照我的方式去做。

考虑常见的数学“范围”符号:0 <= i < 10

这很容易在代码中近似，你已经习惯了在中间重复变量并用&&连接:

if (0 <= i && i < 10)
    return true;
else
    return false;

一旦你习惯了这种模式，你就再也不会觉得愚蠢了

if ( ! (i < 0 || i >= 9))
    return true;

同样的方法。

长序列的关系变得更容易处理，因为操作数倾向于非递减顺序。

此外，操作符<的优先级被铭记在c++标准中。在某些情况下，operator=是根据it来定义的!(a<b || b<a))

现代c++是一门美丽的语言。

我说出来了。很多人真的很讨厌c++，但说实话，我发现现代c++与STL/Boost风格的编程在大多数时候是一种非常有表现力、优雅和令人难以置信的高效语言。

我认为大多数讨厌c++的人都是基于使用OO的糟糕经历。c++在面向对象方面做得不是很好，因为多态性通常依赖于堆分配对象，而且c++没有自动垃圾收集。

但c++真正的亮点在于泛型库和函数式编程技术，这使得构建难以置信的大型、高度可维护的系统成为可能。很多人说c++试图做所有事情，但最终什么都做不好。我可能同意它在面向对象方面不如其他语言，但它在泛型编程和函数编程方面比任何其他主流的基于c的语言都要好。(c++ 0x只会进一步强调这一事实。)

我也很欣赏c++如何让我在必要时获得底层，并提供对操作系统的完全访问。

加上RAII。认真对待。当我用其他c语言编程时，我真的很想念析构函数。(不，垃圾回收不会使析构函数无用。)

关系数据库系统将是自切片面包以来最好的东西……

．.． 那就是当我们(希望)得到它们的时候。SQL数据库太糟糕了，一点都不好笑。

我觉得有趣的是，认证dba认为SQL数据库系统是关系数据库系统。这说明了上述认证的质量。

困惑吗?读c·j·戴特的书。

edit

为什么叫关系?这个词是什么意思?

如今，拥有强大(哎呀，任何)数学背景的程序员(或认证DBA, wink)是例外，而不是常见情况(我也是常见情况的一个实例)。SQL的表、列和行，以及被称为实体/关系建模的笑话，只是在伤害上加了侮辱。难怪有一种误解，认为关系数据库系统之所以这样叫，是因为实体(表)之间的某些关系(外键?)是如此普遍。

事实上，关系源于关系的数学概念，因此与集合理论和函数密切相关(在数学意义上，而不是任何编程意义上)。

[http://en.wikipedia.org/wiki/Finitary_relation][2]:

In mathematics (more specifically, in set theory and logic), a relation is a property that assigns truth values to combinations (k-tuples) of k individuals. Typically, the property describes a possible connection between the components of a k-tuple. For a given set of k-tuples, a truth value is assigned to each k-tuple according to whether the property does or does not hold. An example of a ternary relation (i.e., between three individuals) is: "X was-introduced-to Y by Z", where (X,Y,Z) is a 3-tuple of persons; for example, "Beatrice Wood was introduced to Henri-Pierre Roché by Marcel Duchamp" is true, while "Karl Marx was introduced to Friedrich Engels by Queen Victoria" is false.

维基百科说得很清楚:在SQL数据库管理系统中，这样的三元关系将是一个“表”，而不是一个“外键”(我冒昧地重命名了关系的“列”:X = who, Y = to, Z = by):

CREATE TABLE introduction (
  who INDIVIDUAL NOT NULL
, to INDIVIDUAL NOT NULL
, by INDIVIDUAL NOT NULL
, PRIMARY KEY (who, to, by)
);

此外，它将包含(可能在其他中)这个“row”:

INSERT INTO introduction (
  who
, to
, by
) VALUES (
  'Beatrice Wood'
, 'Henri-Pierre Roché'
, 'Marcel Duchamp'
);

但不是这个:

INSERT INTO introduction (
  who
, to
, by
) VALUES (
  'Karl Marx'
, 'Friedrich Engels'
, 'Queen Victoria'
);

关系数据库字典:

relation (mathematics) Given sets s1, s2, ..., sn, not necessarily distinct, r is a relation on those sets if and only if it's a set of n-tuples each of which has its first element from s1, its second element from s2, and so on. (Equivalently, r is a subset of the Cartesian product s1 x s2 x ... x sn.) Set si is the ith domain of r (i = 1, ..., n). Note: There are several important logical differences between relations in mathematics and their relational model counterparts. Here are some of them: Mathematical relations have a left-to-right ordering to their attributes. Actually, mathematical relations have, at best, only a very rudimentary concept of attributes anyway. Certainly their attributes aren't named, other than by their ordinal position. As a consequence, mathematical relations don't really have either a heading or a type in the relational model sense. Mathematical relations are usually either binary or, just occasionally, unary. By contrast, relations in the relational model are of degree n, where n can be any nonnegative integer. Relational operators such as JOIN, EXTEND, and the rest were first defined in the context of the relational model specifically; the mathematical theory of relations includes few such operators. And so on (the foregoing isn't meant to be an exhaustive list).

异常应该只在真正异常的情况下使用

在我最近参与的项目中，异常的使用似乎非常猖獗。

这里有一个例子:

我们有拦截网络请求的过滤器。筛选器调用筛选器，筛选器的任务是检查请求是否具有某些输入参数并验证这些参数。你设置了要检查的字段，并且抽象类确保参数不为空，然后调用一个由你的特定类实现的screen()方法来进行更多的扩展验证:

public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{           
            // 
            if (!checkFieldExistence(req)){
                    return false;
            }
            return screen(req,resp,filterConfig);
    }

checkFieldExistance(req)方法从不返回false。如果所有字段都不缺少，则返回true，如果缺少字段则抛出异常。

我知道这是一种糟糕的设计，但部分问题在于，这里的一些架构师认为，每次遇到意外情况时都需要抛出异常。

此外，我知道checkFieldExistance(req)的签名确实抛出了一个异常，这只是我们几乎所有的方法都这样做-所以我没有想到这个方法可能会抛出一个异常而不是返回false。直到我翻遍代码才发现。