摘自architecture-performance-and-games
You jammed a bit more code into your game, but you don’t want the next person to come along to trip over the wrinkles you left throughout the source. Unless the change is minor, there’s usually a bit of reorganization to do to make your new code integrate seamlessly with the rest of the program. If you do it right, the next person to come along won’t be able to tell when any line of code was written.
上面这条是讲写完代码之后应该要学会clean your code.但当我搜索clean code时我又发现了一些争议。比如这个问题do-you-actually-write-clean-code下面的最高分回答说，当任务迫在眉睫的时候，重点不是代码整不整洁，而是要把代码写完。尽量保持那些写代码的原则，但也不要介意用点“复制黏贴”，即不要介意代码里有一些重复，毕竟你可以在之后重新整理代码。
这让我想起，我和狗这次做的这个游戏，被要求参加一个比赛，但因为我们错过了截止的日期而无缘比赛。这很遗憾，我假装并不在乎，但还是有点难过，毕竟我熬了一个周的夜去赶进度但还是失败了。我反思这个事情，发现大部分时间我都花在怎么让代码更结构化更整洁上，而后期写的时候，这些结构并没有让我觉得有多轻松。
You can define “decoupling” a bunch of ways, but I think if two pieces of code are coupled, it means you can’t understand one without understanding the other. If you de-couple them, you can reason about either side independently. That’s great because if only one of those pieces is relevant to your problem, you just need to load it into your monkey brain and not the other half too.
key goal of software architecture: minimize the amount of knowledge you need to have in-cranium before you can make progress.
Whenever you add a layer of abstraction or a place where extensibility is supported, you’re speculating that you will need that flexibility later. You’re adding code and complexity to your game that takes time to develop, debug, and maintain.
之前拿到老师以前做的游戏的代码研究时，把其结构照搬到自己的游戏里面。虽然其中大部分都很有用，但我还是会觉得其中有些结构对我的游戏来说大而不当，比如说技能系统的结构，因为我的主角是像超级玛丽一样只有两到三个攻击动作，根本没有必要抽象出来然后写三个子类。因为这样每个子类的代码可能只有两个方法。
In theory, all of this decoupling means you have less code to understand before you can extend it, but the layers of abstraction themselves end up filling your mental scratch disk.
Simplicity：Lately, I feel like if there is any method that eases these constraints, it’s simplicity. In my code today, I try very hard to write the cleanest, most direct solution to the problem. The kind of code where after you read it, you understand exactly what it does and can’t imagine any other possible solution.I aim to get the data structures and algorithms right (in about that order) and then go from there. I find if I can keep things simple, there’s less code overall. That means less code to load into my head in order to change it.
上面这段很有意思，因为我发现在我写代码时我只是想到一种可能性就开始写，但事后没有对自己的代码进行处理和修改。我认为修改是很重要的，在我所有获得成功的领域里，最重要的过程都是要不停修正自己。
But, most of all, if you want to make something fun, have fun making it.
读完这一章之后我又深入研究了一下怎么写clean code
clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer
这个链接里面的几条规定我可是经常违反啊
2.4. Less arguments are better：More than three arguments are evil.
我的博弈程序里面有些函数有时候有六七个参数..我也觉得惨不忍睹，但也不得不怪罪于这个项目本身就是从示例项目的非面向对象的代码里直接勉强建了几个类出来的。
2.5. No side effects：Functions must only do what the name suggests and nothing else.
2.7. Error Handling is one thing：
Throwing exceptions is better than returning different codes dependent on errors.
Asking for forgiveness is easier than requesting permission. Use try/catch instead of conditions if possible
说起来，我的代码里还从来没有用到过“异常”。搜了一下异常的用法，how-using-try-catch-for-exception-handling-is-best-practice 好像多数用于在用户提出错误请求的时候（比如输入了个非法数字）弹出一个对话框提示错误之类的。
而这个链接writingcleancode.pdf 里面这条也很有用：
Make your comments say something about the code that the code can’t say about itself.
网友评论