Timeline for Hiding away complexity with sub functions
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 15, 2012 at 5:59 | history | edited | Doc Brown | CC BY-SA 3.0 |
typo fixed
|
| Aug 14, 2012 at 15:46 | comment | added | Winston Ewert | The problem with the example Uncle Bob shows there is that he's increased the scope of all the local variables into instance members. As a result whatever gain he might have by his function decomposition is lost because of the increased variable scope. | |
| Aug 14, 2012 at 14:54 | comment | added | rlperez | @DocBrown I am very open to new ideas. I spend a lot of free time learning best practices and new techniques. The book is poor because the way he proposes those ideas as the only possible solution, the writing is pretty poor, and I don't need 3 word sentences to tell me what is right or wrong. There are better books on the market to describe quality code which left me surprised how much hype that book has. I don't need or want to be told. Explain. Don't tell. | |
| Aug 14, 2012 at 14:50 | comment | added | Doc Brown | @Rig: IMHO throwing a book into trash is not really a sign of beeing open for new ideas of in coding. Perhaps you are a little bit too self-confident in your believe what "common sense" is? But alas, I guess you are not alone, Bob Martin's ideas are a foundation of endless discussions and holy-wars in the community. | |
| Aug 14, 2012 at 14:41 | history | edited | Doc Brown | CC BY-SA 3.0 |
added another comment; added 21 characters in body; edited body
|
| Aug 14, 2012 at 14:35 | comment | added | rlperez | I agree with @Stargazer712. That dude has some serious dogma issues. I threw that book in the trash because its like he has no common sense. Its his way or no way. | |
| Aug 14, 2012 at 14:30 | comment | added | Doc Brown | @Stargazer712: Bob Martin takes it to the extreme, of course. But typically, I don't start with refactoring to functions. First I write/add some code to a function, and when seeing that the function now does too many things at once, then I refactor until I feel it is small enough. Often, this will make a lot of comments obsolet (at least when choosing good names). And it saves debugging time, because readable code to my experience has much less bugs. | |
| Aug 14, 2012 at 13:59 | comment | added | riwalk | I followed Robert Martin's advice once. Not twice, but once. My code had me using the "Go To Definition" feature of visual studio like there was no tomorrow. Eventually, there's a point where you need to stop writing functions and start writing code. | |
| Aug 14, 2012 at 12:12 | history | edited | Doc Brown | CC BY-SA 3.0 |
comment about good naimg added; added 57 characters in body
|
| Aug 14, 2012 at 12:04 | history | answered | Doc Brown | CC BY-SA 3.0 |