| Re: simpletest vs phpunit vs ... [message #180537 is a reply to message #180520] |
Mon, 25 February 2013 00:03   |
legalize+jeeves
Messages: 21
Registered: September 2010
Karma:
|
Junior Member |
|
|
[Please do not mail me a copy of your followup]
Anders Wegge Keller <wegge(at)wegge(dot)dk> spake the secret code
<87wqtzo752(dot)fsf(at)huddi(dot)jernurt(dot)dk> thusly:
> legalize+jeeves(at)mail(dot)xmission(dot)com (Richard) writes:
>
>> [Please do not mail me a copy of your followup]
>>
>> Anders Wegge Keller <wegge(at)wegge(dot)dk> spake the secret code
>> <87ehg8ozce(dot)fsf(at)huddi(dot)jernurt(dot)dk> thusly:
>>
>>> If on the other hand, you had been working in a project organization,
>>> like I do, you would have known that there isn't enough time to
>>> refactor all 600.000 lines of code[1], for each of the 600 projects
>>> that has 92-96% of the code in common.
>>
>> This is a straw-man argument, because I didn't assert any such thing.
>
> Didn't you say that refactoring could eliminate the need for
> comments?
Which is not the same thing as me telling you to go refactor half a
million lines of code. Where did I tell you to do that? Nowhere.
I also did not say that refactoring eliminates the *need* for comments.
In fact, I specifically stated an example where comments *are* needed
(i.e. bibliographic citation of an algorithm).
So yes, making these assertions is indeed a straw-man argument because
you're arguing against a point that I did not make and specifically
stated the opposite of the point you are arguing against.
> But that aside, I only did mention this example, because this is the
> reality I have to work with. And although I'm in favor of writing easy
> understood code, I also know that it becomes impractical at codebases
> this large.
There's a difference between commenting every block of code and
providing documentation in a very large codebase.
Very large code bases have their own set of problems that arise simply
due to the scale of the project. In a very large code base, you need
some kind of documentation and such documentation often takes the form
of doxygen (or some other system) style comments that can be processed
to produce documentation directly from the source code.
If you read the references I've been citing they do not say that comments
per se are bad. I have not said comments are bad. However, inside a
method or function implementation if I have a small block of code,
which people tend to offset from neighbouring blocks by blank lines,
and I feel that this block of code needs a comment to explain what
it's doing, then chances are that block of code has details that are
best moved off into a separate method or function and what we need in
place of this comment is simply a call to a well named method.
Note that the above statement does not define an axiomatic MUST ALWAYS
process, but employs human judgment in deciding when to extract method
or not. That is why such indications are referred to as "code smells"
and not "code errors".
If my entire point of view in this thread seems alien to you, then I
suggest you read "Refactoring" by Martin Fowler and/or "Refactoring to
Patterns" by Joshua Kierievsky.
< http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485 672>
<http://www.amazon.com/Refactoring-Patterns-Joshua-Kerievsky/dp/0321213351>
If you don't like reading books, go find some Smalltalk guys and talk
to them about how refactoring.
Seriously, these ideas are not new (Refactoring is almost 15 years in
print and the idea was not new when it came out), they are not mine, and
they are pretty pervasive in the software engineering industry.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]