Comments on: Most confused discussion in the known universe http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/ Dagfinn Reiersøl on PHP, agile development, Ruby and other addictive substances Fri, 23 Jul 2010 20:17:39 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: In Defense Of Commenting | BrandonSavage.net http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-460 In Defense Of Commenting | BrandonSavage.net Tue, 05 May 2009 11:21:34 +0000 http://blog.agilephp.com/?p=1573#comment-460 [...] week, “On Code Commenting and Technical Debt” raised a lot of response throughout the community. I think that discussion is great, and I’m all for a debate that enhances the community. But [...] [...] week, “On Code Commenting and Technical Debt” raised a lot of response throughout the community. I think that discussion is great, and I’m all for a debate that enhances the community. But [...]

]]> By: Community News: Comments on Commenting | Cole Design Studios http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-454 Community News: Comments on Commenting | Cole Design Studios Mon, 04 May 2009 17:14:18 +0000 http://blog.agilephp.com/?p=1573#comment-454 [...] Allen’s opinions on Benjamin Eberlei’s [...] [...] Allen’s opinions on Benjamin Eberlei’s [...]

]]> By: fqqdk http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-445 fqqdk Mon, 04 May 2009 08:58:54 +0000 http://blog.agilephp.com/?p=1573#comment-445 I was a tad bit nearer to insulting Marco (not a tiny bit intentionally), so allow me to explain myself: I have read Marco's post about testing, so yes, it has occured to me that he does indeed unittests his code ;) Actually testability can be measured, and a constructor that does those things I've enlisted, is more difficult to test than a constructor that does not do these things. Constructor does real work: http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/ is a very good reading, skim through it :) Your other points are infalsifiably truthful, though :) I was a tad bit nearer to insulting Marco (not a tiny bit intentionally), so allow me to explain myself:
I have read Marco’s post about testing, so yes, it has occured to me that he does indeed unittests his code ;)
Actually testability can be measured, and a constructor that does those things I’ve enlisted, is more difficult to test than a constructor that does not do these things.
Constructor does real work: http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/ is a very good reading, skim through it :)
Your other points are infalsifiably truthful, though :)

]]> By: dagfinn http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-428 dagfinn Sun, 03 May 2009 17:51:11 +0000 http://blog.agilephp.com/?p=1573#comment-428 @Greg: No one except you has generalized about who writes unit tests and who doesn't. This is a discussion about a specific code example, not an attempt to insult the people who developed it. It's just a piece of code; I don't care who wrote it, and have nothing against Marco Tabini and associates. It might as well have been my own. My code is not always 100% perfect (what a surprise!). In short, there is absolutely no reason to take this personally (on behalf of someone else). The tone of your comment makes me wonder what's behind it. And if you think the discussion is a waste of time, why participate? @Greg: No one except you has generalized about who writes unit tests and who doesn’t. This is a discussion about a specific code example, not an attempt to insult the people who developed it. It’s just a piece of code; I don’t care who wrote it, and have nothing against Marco Tabini and associates. It might as well have been my own. My code is not always 100% perfect (what a surprise!). In short, there is absolutely no reason to take this personally (on behalf of someone else).

The tone of your comment makes me wonder what’s behind it. And if you think the discussion is a waste of time, why participate?

]]> By: Greg Beaver http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-422 Greg Beaver Sun, 03 May 2009 15:14:19 +0000 http://blog.agilephp.com/?p=1573#comment-422 Has it occurred to you that perhaps Marco Tabini and Associates does in fact unit test? Especially since he has blogged about this explicitly? :) There is nothing about the design of his simple, 5-line constructor that is difficult to unit test. The whole "debate" over the idea of commenting as good or bad is laughable. Intelligent developers write good code and good comments, and all the dogma is irrelevant to making this possible. Experience and careful study of the mistakes of the past (which includes design patterns and all the other solutions to learning from mistakes) are all that is needed, end of story. Has it occurred to you that perhaps Marco Tabini and Associates does in fact unit test? Especially since he has blogged about this explicitly? :)

There is nothing about the design of his simple, 5-line constructor that is difficult to unit test. The whole “debate” over the idea of commenting as good or bad is laughable.

Intelligent developers write good code and good comments, and all the dogma is irrelevant to making this possible. Experience and careful study of the mistakes of the past (which includes design patterns and all the other solutions to learning from mistakes) are all that is needed, end of story.

]]> By: dagfinn http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-402 dagfinn Sun, 03 May 2009 06:53:49 +0000 http://blog.agilephp.com/?p=1573#comment-402 You're absolutely right, I agree with all of what you're saying. You touch on several things I've been thinking about. Above all, the discussion of comments is going on without a foundation. Unless you understand code smells and refactoring properly, the idea of using fewer comments is probably more or less incomprehensible. In a comment to Benjamin Eberlei's post I suggested something similar to what you're saying: Instead of his refactoring, you could extract a class to handle the file system aspect. Another way of looking at it is that the original code does not suffer from the Long Method smell. Primitive Obsession is more like it. Therefore Extract Class should be more relevant than Extract Method. You’re absolutely right, I agree with all of what you’re saying. You touch on several things I’ve been thinking about. Above all, the discussion of comments is going on without a foundation. Unless you understand code smells and refactoring properly, the idea of using fewer comments is probably more or less incomprehensible.

In a comment to Benjamin Eberlei’s post I suggested something similar to what you’re saying: Instead of his refactoring, you could extract a class to handle the file system aspect. Another way of looking at it is that the original code does not suffer from the Long Method smell. Primitive Obsession is more like it. Therefore Extract Class should be more relevant than Extract Method.

]]> By: fqqdk http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-391 fqqdk Sat, 02 May 2009 22:40:55 +0000 http://blog.agilephp.com/?p=1573#comment-391 upsz, I screwed up the parentheses in the middle. it should read: ...XSL transformation (possibly in the parent class), the file resource lookup, and the interpretation of the pathinfo... upsz, I screwed up the parentheses in the middle. it should read: …XSL transformation (possibly in the parent class), the file resource lookup, and the interpretation of the pathinfo…

]]> By: fqqdk http://blog.agilephp.com/2009/05/02/most-confused-discussion-in-the-known-universe/comment-page-1/#comment-390 fqqdk Sat, 02 May 2009 22:37:58 +0000 http://blog.agilephp.com/?p=1573#comment-390 Still... You can't refactor without unittests in place. Everyone always forgets about the unittests when talking about refactoring. And that takes me to my point, which also has nothing to do with the original argument about code needing or not needing any kind of comments. If that original snippet was designed with testing in mind, it never were one function in the first place, let alone a constructor. It wouldn't be a bunch of method on one class either, because a lot of separate responsibilities are intertwined in it: XSL transformation (possibly in the parent class, the file resource lookup, and the interpretation of the pathinfo). So I guess it's really some sort of a "strawman snippet". :) And I guess you're right. And then again, anyone can argue that it's really not worth it, to blow up that snippet to THREE classes (and possibly at least two interfaces, to loosen the coupling between said classes). But eventually you'll get to a state, where that code is not only readable, but easily testable. Because that code, in its original form is not easily testable. It does work in a constructor, talks to global variables (via a singleton), and to the filesystem. (I recommend http://misko.hevery.com/ to everyone, lots of great posts about testable design.) Still… You can’t refactor without unittests in place. Everyone always forgets about the unittests when talking about refactoring. And that takes me to my point, which also has nothing to do with the original argument about code needing or not needing any kind of comments.
If that original snippet was designed with testing in mind, it never were one function in the first place, let alone a constructor. It wouldn’t be a bunch of method on one class either, because a lot of separate responsibilities are intertwined in it: XSL transformation (possibly in the parent class, the file resource lookup, and the interpretation of the pathinfo). So I guess it’s really some sort of a “strawman snippet”. :) And I guess you’re right.
And then again, anyone can argue that it’s really not worth it, to blow up that snippet to THREE classes (and possibly at least two interfaces, to loosen the coupling between said classes). But eventually you’ll get to a state, where that code is not only readable, but easily testable. Because that code, in its original form is not easily testable. It does work in a constructor, talks to global variables (via a singleton), and to the filesystem. (I recommend http://misko.hevery.com/ to everyone, lots of great posts about testable design.)

]]>