看看下面的代码的命名： 给你一分钟的思考时间，你能明白她的意思吗？
反正，我看了半天也没有搞明白 1 ，2 ，3 ，4 是什么意思？
这个东西，就是 一开的时候，命名不好，后来，新来的同事，一开始的时候，也会有跟我一样的疑惑，但是，过不了几天，他们就会搞明白，这结果色值分别代表什么意思。但是，they don't 去改的，因为，他们已经习惯了。这里的问题，出在一开始 创建项目 制定规范的老大的身上，他的命名的能力，真的让人 无语。 或者说，他根本就不在乎这个的命名。
有的时候，我宁愿多花的时间，去想一个 简洁的名字。 我觉的起一个好名字，作为一名，牛逼的程序员的基础。
关于： 色值这个东西，一开始的时候，就会定义好的。但是，后来的人，并不知道，所以，又他妈的定义了一大堆的色值，后期维护的就会很麻烦的。我们的项目很大了，我看了一下，我们 colors 里面，大概有他妈的300 多行，然后，我下午有活了，下面是我代码精简之后的 colors.xml
我很开心，I cut down 将近 200 多行，Because 这 88 行里面还有将近 20行的注释。这样，新人来的时候就会可读懂， 这个色值是干嘛的，那个色值是干嘛的！
说实在的，我已经很庆幸了，我的前辈们很给力了。你想想，如果这个地方，很多人用硬编码:就是set 色值，直接写到了layout.xml 布局文件之中，我是没有勇气修改的。除非我是傻逼。但是，硬编码是初学者 很容易犯得错误，为什么呢？因为，硬编码，可以很快的出来，再就是，很多的书籍上因为书本身的限制，还有一些水平很低的人出的视频教程，他们本身就没有什么规范可言的，说白了就是瞎鸡巴写。只要能跑就行！他们不用写出简洁的代码。想要写出简介代码的人是对自己的技术很高的要求的人，我会觉的写出简洁的代码是一种艺术！
下面写一下我的感悟：
1 命名要简短
一开的时候，我只在乎命名的意义了，但是忽略的长度的影响。我不愿阅读很长的代码，至于名字也是一样的。我不喜欢名字很长的变量和引用。因为，他会让你的代码一行里面，变的很长很长
例如：
2 命名要有意义
至少，你看到名字的时候，你要知道他是什么意思，不能，让你的同事，看了半天的名字，不知道什么意思。还要去问你，这样的效率很低很低。
给烂代码添加注释，不如起一个好名字，其实相对而言，起名字的时间会更少的！
如果，你项目已经很大了，修改名字的代价太大了。我建议，你添加一些注释，简要的说明，她的作用就好了
今天，我将 font_black_2 名字改成了， font_base_color. 自己起名的时间花少了。一开始觉的这个不错，但是，我修改引用，改到一半的时候，突然觉的font_normal_color 会更好点！不愿意改了，就为了修个font_black_2 这个无意义的名字，我起名字话了一分钟，但是，修改整个项目中的引用，我花费了2个小时！
她麻痹的，我的手指都他妈的敲疼了~
但是，我看最终的结果，我很开心
以后来的写项目的哥们。不用那么累了， 可以更快的明白，什么意思！
我会告诫他们，
当你想往 colors.xml 里面添加 色值的时候，一定要，先搜索有以下有没有重复的色值，有的话直接用。 但是，有的时候，你会觉的名字起得不贴切。这个时候，你就要有重构代码的勇气。其实，名字起得越抽象越好。 太具体的名字，你自然会知道问题出在哪里！
个人的小建议：
1 色值这个东西， 在APP初期的时候，一定要 定好。 修改是不可避免的。但是，大体的框架是要定好的，例如：
背景色值： Activity Fragment View CustomerView item
字体的色值： font_title_color， font_normal_color, font_hint_color
还有主色调和副色调，
primary_color auxiliary_color
2 硬编码的孩子 直接 辞掉
3 命名简洁
4 布局中，最好多使用 style.
这种情况，大多是应对 布局很相似的View.
如果，你的项目，对style 抽取的好的话，基本上，修改色值的时候，就会变的更加的简单！
灵活的使用 style 是很好的习惯奥！
但是，不是每个人都会有这种意识，Do the best one!
If you have the heart , You can do it! because clean code is art!
No comments:
Post a Comment