Even comments can be eliminated if coded correctly, take this garbled mess, as if you just found this in the middle of a procedure:
Code:
r = n / 2
While Abs( r - (n/r) ) > 0
r = 0.5 * ( r + (n/r) )
Wend
Debug "r = " + StrD(r)
What are r and n? What does this actually do?
Okay, so that's obviously BAD. How about this then?
Code:
result = number / 2
While Abs( result - (number/result) ) > 0
result = 0.5 * ( result + (number/result) )
Wend
Debug "result = " + StrD(result)
It's still bad, but a bit more readable... but we still don't understand what it's doing!
So how about this:
Code:
; Square Root of a number with Newton-Raphson approximation
result = number / 2
While Abs( result - (number/result) ) > 0
result = 0.5 * ( result + (number/result) )
Wend
Debug "result = " + StrD(result)
Ah ha! We understand what is going on now!
But could it be better?
Code:
Procedure.d SquareRootApproximation(number.d)
Protected result.d = number / 2
While Abs( result - (number/result) ) > 0
result = 0.5 * ( result + (number/result) )
Wend
ProcedureReturn result
EndProcedure
Debug "result = " + StrD(SquareRootApproximation(16))
Why yes, yes it can, and without a single comment!
If coders have a priority of keeping everything readable is maintained, then procedures should be short and well named, variables should be well named, and use logical spacing to separate sections. Comments should be used for the "Whys?" of programming, not the "What?"
I'll admit of failing on these more often than I care to admit, but when I have to revisit code I end up refactoring it all to do it anyway.
We aren't hurting for memory or performance any more, if by doing this your source code inflates by 10kb... well, who cares?
And if you do care, why are you using a single sided 5.25" floppy disk on a modern computer? I'll let you in on a secret - usb pen drives!
