内含C语言、java、数据库新手错误集锦
还记得你刚学C语言的情形吗？当初看上他，可能是因为入门学的，可能是因为他既强大，又灵活；不管因为什么原因，你都入了C语言这个坑，现在回想起来，刚入坑那会，是不是也犯过一些初级的错误呢？比如说：
1、标识符不区分大小写
C语言习惯上，符号常量名用大写，变量名用小写表示，以增加可读性；
2、忽略了变量的类型，进行了不合法的运算
%是求余运算，得到a/b的整余数。整型变量a和b可以进行求余运算，而实型变量则不允许进行“求余”运算。
3、将字符常量与字符串常量混淆
char c;
c="a";
在这里就混淆了字符常量与字符串常量，字符常量是由一对单引号括起来的单个字符，字符串常量是一对双引号括起来的字符序列。C规定以“\”作字符串结束标志，它是由系统自动加上的，所以字符串“a”实际上包含两个字符：‘a'和‘\'，而把它赋给一个字符变量是不行的。
4、忽略了“=”与“==”的区别。
在许多高级语言中，用“=”符号作为关系运算符“等于”。如在BASIC程序中可以写
if (a=3) then …
但C语言中，“=”是赋值运算符，“==”是关系运算符。如：
if (a==3) a=b;
前者是进行比较，a是否和3相等，后者表示如果a和3相等，把b值赋给a。由于习惯问题，初学者往往会犯这样的错误。
5、该加分号的时候忘记加，不该加的时候又加上了
少加分号的情况：
多加分号的情况：
最重要的是，在编辑器报错时，你却查不到错误，最后发现把;写成了；
同比，虽然java和C是不一样的语言，但是我们可以看到，新手期犯的错还都差不多，比如说：
1、不区分大小写的情况
变量money和Money，虽然是一个单词，但是不一样的，一定要记得；
2、将数组转化为列表
将数组转化为一个列表时，程序员们经常这样做：
3、判断一个数组是否包含一个值
程序员们经常这样做：
4、一个等号和两个等号的不同
在Java程序中，一个等号是赋值操作符，而两个等号则是比较操作符。在java新手的程序中经常出现这样的代码：
5、空引用的错误
这类错误也是最令人头疼的，属于逻辑性错误，编译器可以正常编译，但是在某种情况下执行出错，出错信息是java.lang.NullPointerException。
这是由于在对象的引用没有被初始化的情况下而调用这个对象的属性或者方法而造成的，比如下面的例子：
说完语言，我们再来看看数据库新手们，都常犯什么错误：
1、Storing images储存图片
数据库里不应该放图片。你可以做的事情并不代表你就应该去做。图片会占用数据库里相当大的空间，吃掉不必要的IO资源从而拖慢应用。这个错误最常出现的情况，就是新人将图片用base64编码，然后将其储存在很大的text/blob字段当中。
2、Limit/Offset
分页在很多应用中都非常常见。从你开始学习SQL，（你就该知道）最直接的分页方法就是先用ORDER BY对数据库的一些列进行排序，然后LIMIT返回的结果数，对除第一页外的每一页使用OFFSET。这看起来很符合逻辑，直到你处理中等规模应用时才意识到：
它对数据库施加的负载是非常痛苦的。
它具有不确定性，记录应该随着用户翻页而改变。
3、用整数做primary key
在创建primary key的时候，几乎所有的ORM（Object Relational Mapping对象关系映射）的默认做法都是创建一个串行字段，它是按顺序自动生成的，然后你就可以用它（这些自动生成的数字）作为你的primary key。在管理员看来，这是非常直观的，因为可以由用户1到用户2这样依次查看。对大多数的应用来说，这种做法通常是不错的。但是随着这些整数primary key不断变大，你很快就会意识到处理他们会让人筋疲力尽。对于大规模系统，这是很不理想的处理方法。此外，你还会依赖生成这些key的那个系统，在你必须要扩大规模的时候，会非常痛苦。更好的解决办法是从一开始就利用好UUID（Universally Unique Identifier通用唯一识别码）的优势。
4、新列中的默认值
无论你做这个工作有多久，都不会一次就创建出一个完美的schema。最好是将数据库schema视为一个持续演化的文档。不幸的是：向数据库中添加一列是件很容易的事，这也就意味着在添加列的时候把工作搞砸同样很容易。默认情况下，如果你新添加了一列，通常是允许有NULL值的。这个操作速度很快，但大多数应用实际上不太想让他们的数据里有null值，他们会想要设置默认值。
如果你在表里添加设置了默认值的新列，会对这张表触发一次完全的重写。注意：这对应用中的任何（数据量）很大的表都非常不利。（正确的方法）恰恰相反，最好是先允许null值存在，这样操作就是即时的，接下来再设置默认值，再用后台进程去回溯更新数据。
5、过度标准化
开始学习数据库的标准化的时候，（标准化）感觉就像是很正确的事。你创建了一个posts的表，里面包含authors，每篇文章（post）都属于一个条目（category），所以你又创建了一个categories的表，然后再创建一个把它们俩join在一起的表，post_categories。从根本上来说，这样做标准化也没什么原则上的错误，但是某种程度上，标准化的收益正在递减。
在上述实例中，categories可以简单地作为post里的一个varchar字段。标准化是件很有意义的工作，但是每次处理包含多对多关系的表时都要深思熟虑，想想你是不是真的需要在关系的两边都各用一个单独的表。
欢迎各位看官们补充~
吃瓜观众可点一波关注压压惊（还好我绕过了这些坑）
恒生开发者社区-恒生电子面向所有开发者提供的服务分享、技术交流和互联共通等一站式服务平台。