While I think it is great to put together information like this and I look forward to it becoming more useful as it is expanded, these wiki pages are currently woefully short and contain generalizations that could do more harm than good.
Some examples:
- Only the Code Tells the Truth: "Remember that useful code is used much longer than ever intended."
The author was trying to make the point that you should name variables, methods, etc. well and write code that is not too spaghetti-like, such that those reading your code will easily make sense of it. This statement doesn't convey that.
- Speed Kills: "Professionals do not write bad code — ever."
The point that the author is trying to make is that you should take your time with coding. But professionals do make mistakes, including writing bad code, and they learn from them.
- The Golden Rule of API Design: "That's where the Golden Rule of API Design fits in: It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. When you do, you learn first-hand the hurdles that your users will have to overcome when they try to test their code independently."
The point the author is trying to make is that you should use the API you are writing. That is not what is necessarily conveyed.
- Write Tests for People: "It is also a good idea to test your tests."
What this means is tweaking the test/etc. so it fails under each circumstance that it is supposed to test, as much as that is feasible to do. But it sounds like the author is saying to write tests for your tests... Noooooooo! Don't do that, unless absolutely necessary, or an infinite loop of writing tests for tests awaits.
There are a number of other generalizations in them, but basically- there is good intent there, but it is way too early to be looking to these for guidance. Please contribute to them, though.
Some examples:
- Only the Code Tells the Truth: "Remember that useful code is used much longer than ever intended."
The author was trying to make the point that you should name variables, methods, etc. well and write code that is not too spaghetti-like, such that those reading your code will easily make sense of it. This statement doesn't convey that.
- Speed Kills: "Professionals do not write bad code — ever."
The point that the author is trying to make is that you should take your time with coding. But professionals do make mistakes, including writing bad code, and they learn from them.
- The Golden Rule of API Design: "That's where the Golden Rule of API Design fits in: It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. When you do, you learn first-hand the hurdles that your users will have to overcome when they try to test their code independently."
The point the author is trying to make is that you should use the API you are writing. That is not what is necessarily conveyed.
- Write Tests for People: "It is also a good idea to test your tests."
What this means is tweaking the test/etc. so it fails under each circumstance that it is supposed to test, as much as that is feasible to do. But it sounds like the author is saying to write tests for your tests... Noooooooo! Don't do that, unless absolutely necessary, or an infinite loop of writing tests for tests awaits.
There are a number of other generalizations in them, but basically- there is good intent there, but it is way too early to be looking to these for guidance. Please contribute to them, though.