-
明确目标，你要编写什么？
- 不要陷入语言细节，保持专注于目标
- 明确、明显、明晰等，还能减少BUG
-
保持冷静，保持编码！KEEP CALM,KEEP CODE
-
保持简洁！KEEP IT SIMPLE, STUPID
- 保持代码简洁，易读易理解
- 保持结构简洁，易查错
- 单一职责，做好即可
- 将重复代码简化
- 通常，漂亮的代码通常是正确的代码
-
人生苦短，善用工具，多读他人代码！
- 多使用工具，快速实现目标才是最重要的。
- 多用别人的代码，DON’T REPEAT YOURSELF
- 不要被极客荣誉所束缚，你根本没有那么大的影响力
- 不要复制代码
-
写新代码之前，先思考，先修复BUG
-
能用即可 DO THE SIMPLEST THING THAT COULD POSSIBLY WORK
- 不要过度设计，不要为了设计而设计
- 拥抱变化。没有完美的代码，只有永恒的需求
- 现在用不到的功能，以后也用不到！YOU ARE’NT GOING TO NEED IT
- 避免过早优化
- 重功能需求，而不是语言细节
- 要相信，没有多少人会真正看你的代码。
- 软件永远没有完工的时刻
-
每隔一个小时，离开电脑！
-
Write For People first, compute second
-
Plan for failure - loggin and error handling
-
测试驱动开发
-
模块化设计，快速迭代
- 分离，分离，尽可能分离
- 组合，组合，尽可能组合
- 统一，统一，尽可能统一
始终保持一致性！
方法应返回单个值，或者不返回值。
将对象引用作为第一个参数传递给方法。
在方法内部使用“ self”来引用对象引用。
始终在非void函数中使用
return（永远不要在void函数中使用return）。当您从网络中读取输入时，请假定发件人是恶意心理变态者。如果输入太长，请将其切碎并丢弃多余的部分。
使用断言来捕获不可能的条件。失败的速度越快，恢复的速度就越快。
当系统运行超过50％的容量时，它已经过载。始终将磁盘，内存，CPU和网络的使用率控制在50％以下。
您导出的API在
include中。所有其他来源都进入src。 禁止使用静态/全局变量和互斥锁。可伸缩的C开发人员从不共享线程之间的可变状态一百步比一个大飞跃更好。
Don’t bother with object oriented programming, it’s not helpful
Try to keep functions having 1 task, not multiple (depending on extra passed in booleans etc.)
Learn to program a real machine, not a virtual machine. e.g. use C, not java
Don’t keep global state. Functions should have all inputs they need
“Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.”
“Write your code for this game only – not for a future game. You’re going to be writing new code later because you’ll be smarter.”
“It will take you 10 years of constant programming and pushing yourself before you will be able to do something important. Study coders you respect and see how long they were programming before their big hit. Read Outliers by Malcolm Gladwell. There are no shortcuts.”
“Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task and get feedback and advice. Do not treat game programming like each coder is a black box. The project could go off the rails and cause delays.”
“Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters.”
“If you’re making a game with a small team, Try not to branch. Always keep your code current as often as possible. Everyone should be able to make a full build and run the game at any time.”
“Programmers should code as if the QA team does not exist. When you find a bug, fix it immediately. Do not code further. You risk your codebase depending on that bug. id Software did not have a QA team before I left after Quake 1.”
“Object-oriented programming is really great, but only if you use the bare basics of what it’s great at: encapsulation and inheritance. Stay away from polymorphism, multiple inheritance, and other advanced features because they will get you in big trouble when you try to put your game on multiple platforms – not all compilers treat your code the same.”
“Learning to program in C is really important and it’s also tedious. If you’re going to be an engine programmer, you better know C and C++. If you’re a gameplay programmer, you can get away with a high-level language like Lua, Python, Java, etc. – just know that you’re limiting your career options by not knowing how things work under the hood. You will make more money if you know more, it’s a simple fact.”
“There’s a saying that making a game is like doing major reconstruction work on your airplane while you’re flying it; I heavily recommend having an old airplane needing reconstruction in the first place!”
“I see some sense in the classical one class per real-world concept OOP design style in the highest levels of gameplay code, e.g. having one object of class “Unit” for each, uhm, unit in the game, and where performance is the least concern.”
“I see some value in the idea of “design patterns” as a common language; we say let’s use the reasons pattern and everyone knows what we’re talking about here. I don’t get the religious attitude towards the book, and the treating of its list of patterns as end-all, be-all - something I’m sure the authors never intended.”
“I never got the point of UML. Pick a high-enough level language and you won’t need diagrams - you’ll fit the “big picture” on a screen, then zoom as appropriate.”
“A modern game contains many different subsystems, and what is true of code that is executed once per (one of ten thousand) object per frame is not as applicable of code that is executed once in a few seconds per human player. Writing code carefully considering the hardware is very rewarding, and very much necessary in the first case; unfortunately, it’s also much harder, and working via abstractions can be forgiven in the second.”
“The first thing new recruits need to unlearn is the love for their own code. New programmers love nothing more than to produce code - pages and pages of elaborate, complex code. But code is a liability, not an asset. The job of a programmer is to think first, and to solve problems of his customers (e.g. designers and artists in a game team) second. Not to produce code. Programmers need to learn to love deleting code more than they love writing new code. Programmers need to learn to let their code go and mercilessly delete and simplify when a better, or simpler solution presents itself.”
“I think an important habit to have is to resist the temptation to abstract and create “general solutions” the first time you encounter a problem. It is better to implement simple, concrete solutions to the first and even the second occurrence of a similar problem. Only the third time you know enough about the problem to think of generalising - and even then you can’t be sure you’ve seen it all.”
“Anyone with a desire to delve in engine code should get a good understanding of C, a decent understanding of C++, and a cursory understanding of the assembly language of the machine they’re targeting.”
“Nowadays it’s hard to evade JavaScript - it’s not a very good language, but it’s ubiquitous in large portions of the IT industry. C# is also a good bet, being embedded in Unity and also potentially useful in the real world, if you decide games aren’t for you after all.”
“I like the Handmade Hero project by Casey Muratori. It’s a series of videos showing how a non-trivial game is made from first principles, without using any middleware or “game engines”. It’s very instructional, and Casey is a gifted comedian just wasting his talent as a programming superstar.”
“Yes! You know what it is, don’t you boy? Shall I tell you? It’s the least I can do. Steel isn’t strong, boy, flesh is stronger!”