On this page you can put tables that describe articles that you have written that are up on our website, or on other websites. New ones at the top please!
!|Author||
|Date||
|Title||
|link||
|Synopsis||
| Author | Uncle Bob |
| Date | 25 Aug, 2009 |
| Title | Clean Code Tip #12: Eliminate Boolean Arguments |
| link | http://www.informit.com/articles/article.aspx?p=1392524 |
| Synopsis | the crew learns that Boolean arguments loudly declare that the function does more than one thing. They are confusing and should be eliminated. |
| Author | Uncle Bob |
| Date | 28 Jul, 2009 |
| Title | Clean Code Tip #11: Output Arguments are Counterintuitive |
| link | http://www.informit.com/articles/article.aspx?p=1382188 |
| Synopsis | the crew learns that if your function must change the state of something, have it change the state of the object it is called on. |
| Author | Uncle Bob |
| Date | 6 July, 2009 |
| Title | Clean Code Tip #10: Too Many Arguments |
| link | http://www.informit.com/articles/article.aspx?p=1375308 |
| Synopsis | the crew learns that functions should have a small number of arguments. |
| Author | Uncle Bob |
| Date | 12 June, 2009 |
| Title | Clean Code Tip #9: One Step Test |
| link | http://www.informit.com/articles/article.aspx?p=1355312 |
| Synopsis | the crew learns that being able to run all the unit tests with just one command is imperative. |
| Author | Uncle Bob |
| Date | 16 May, 2009 |
| Title | Clean Code Tip of the Week #8: Your Build Shouldn't Require More Than One Step |
| link | http://www.informit.com/articles/article.aspx?p=1350506 |
| Synopsis | The crewmen learn that building a project should be a single trivial operation. |
| Author | Uncle Bob |
| Date | 30 Mar, 2009 |
| Title | Clean Code Tip of the Week #7: Clean up Old Commented Out Code |
| link | http://www.informit.com/articles/article.aspx?p=1334908 |
| Synopsis | The crewmen reflect on why old commented-out code is an abomination. |
| Author | Uncle Bob |
| Date | 27 Feb, 2009 |
| Title | Clean Code Tip of the Week #6: Avoid Poorly Written Comments |
| link | http://www.informit.com/articles/article.aspx?p=1328957 |
| Synopsis | In this sixth tip in the series, the crewmen try to interpret a poorly worded comment. |
| Author | Uncle Bob |
| Date | 18 Feb, 2009 |
| Title | Clean Code Tip of the Week #5: Avoid Redundant Comments |
| link | http://www.informit.com/articles/article.aspx?p=1327761 |
| Synopsis | The programmers discuss redundant comments, which describe something that adequately describes itself. |
| Author | Uncle Bob |
| Date | 11 Feb 2009 |
| Title | Clean Code Tip of the Week #4: Avoid Obsolete Comments |
| link | http://www.informit.com/articles/article.aspx?p=1326509 |
| Synopsis | We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this fourth tip in the series, the programmers examine the problem with obsolete comments, which tend to migrate away from the code they once described and become floating islands of irrelevance and misdirection. |
| Author | Uncle Bob |
| Date | 28 Jan 2009 |
| Title | Clean Code Tip of the Week #3: Avoid Inappropriate Information |
| link | http://www.informit.com/articles/article.aspx?p=1323427 |
| Synopsis | We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this third tip of the series, the programmers discuss how to avoid inappropriate information. |
| Author | Uncle Bob |
| Date | 21 Jan 2009 |
| Title | Clean Code Tip of the Week #2: The Inverse Scope Law of Function Names |
| link | http://www.informit.com/articles/article.aspx?p=1323426 |
| Synopsis | The longer the scope of a function, the shorter its name should be. Functions that are called locally from a few nearby places should have long descriptive names, and the longest function names should be given to those functions that are called from just one place. |
| Author | Uncle Bob |
| Date | 7 Jan 2009 |
| Title | Clean Code Tip of the week #1: An Accidental Doppelgänger in Ruby |
| link | http://www.informit.com/articles/article.aspx?p=1313447 |
| Synopsis | Robert C. Martin investigates an interesting dilemma: if the implementation of two functions is identical, yet their intent is completely different, is it still duplicate code? |
Add Child Page to ArticlePage