PS. My mum can code better than your dad!<br>PPS :-)<br><br><div class="gmail_quote">On Fri, Feb 20, 2009 at 2:40 PM, Vahagn Hayrapetyan <span dir="ltr"><<a href="mailto:vahagnh@gmail.com">vahagnh@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Code isn't for computers, it's for people, and if it's not readable by
people it isn't fit for purpose. Therefore I'd rather a codebase
written with an engaging and legible style that I can sit down and read
as hard copy than a mountain of specs and tests. YMMV.<br>
</blockquote>
<br></div>
I think we're communicating about different things here. Code
readability is an asset, for sure. However the 2 important points to
make are these:<br>
<br>
1) Code has a managerial dimension to it. YOU may be great at reading
your own (clean) code. This isn't enough for places where code serves
other purposes than theoretical exercise. Generations of developers
could potentially work with code that you write today.<br>
Saving money and effort by not supplying a test suite where appropriate
could be the most costly decision in the long run (average employee
loyalty today is about 6 months. So every 6 month, a developer could
come in that inherits code that has grown since the previous developer,
which he had inherited from the previous developer, etc. If an average
new developer spends about double as much time trying to comprehend
undocumented legacy code vs well-documented legacy code, it's a matter
of simple arithmetic to produce a cost model that will demonstrate how
much of a "saving" this would have been.)<br>
<br>
2) Engaging and legible style is not a formal proof of correctness.
Even if you did decide to supply each and every line of your code with
formal proofs of correctness, that would only prove the <b>correctness of your programs</b>, not the <b>expected behaviour of your software</b>.
In Object-Oriented systems change can occur at the structural seams of
an application: how objects aggregate and reference each other. Say you
have a class that manipulates objects of a certain interface type.
Then, you refactor the existing object or you introduce a new object
that implements the same interface type. Then, via an object reference
somewhere, you reference "the wrong object".<br>
<br>
Your programs are still formally correct, but <b>at the architectural / structural level</b>
your application has mutated. Now, unless one has special mental
abilities for analyzing the configuration of objects in the VM at
runtime, I wouldn't recommend relying on legibility and aesthetics to
catch the errors or faults.<br>
<br>
Point being made: automated code testing is the most sustainable and
ecological (both in digital and organic aspects of the word) way to
ensure and document the expected behaviour of software. It can also be
used as a productivity / creativity enhancement, but as you also seem
to mean, that part depends entirely on the programmer. <br><font color="#888888">
<br>
/ Vahagn</font><div><div></div><div class="Wj3C7c"><br>
<br><div class="gmail_quote">On Fri, Feb 20, 2009 at 1:01 PM, Eleanor McHugh <span dir="ltr"><<a href="mailto:eleanor@games-with-brains.com" target="_blank">eleanor@games-with-brains.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div>On 19 Feb 2009, at 13:48, Vahagn Hayrapetyan wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But what if eliminating ninety percent of those defects can be achieved without a test suite (which in my experience it can) then the role of testing in a 30K codebase is restricted even further to finding just 10 defects. How well that expense can then be justified will vary from project to project, just as the defect count varies based on team experience, but I don't believe it's a priori demonstrable for all projects that a test suite is a desirable investment of developer effort.<br>



<br>
Fast-forward 2 years. You're working in another company and making big $$$. An bright but not-so-experienced programmer now has to work with legacy code (yours!), and he just hasn't had enough experience to be able to spot errors just by looking at other peoples' code.<br>



<br>
Now, wouldn't it be nice to have a documentation for this code in the form of a robust, explicit, "spelled-out" test suite? (Or worthy of investment?)<br>
</blockquote>
<br></div>
Code isn't for computers, it's for people, and if it's not readable by people it isn't fit for purpose. Therefore I'd rather a codebase written with an engaging and legible style that I can sit down and read as hard copy than a mountain of specs and tests. YMMV.<div>


<div></div><div><br>
<br>
Ellie<br>
<br>
Eleanor McHugh<br>
Games With Brains<br>
<a href="http://slides.games-with-brains.net" target="_blank">http://slides.games-with-brains.net</a><br>
----<br>
raise ArgumentError unless @reality.responds_to? :reason<br>
<br>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>