Re: Scripting style

*Spiral,*


spiralofhope wrote:
> On Sun, 27 Mar 2011 05:12:51 +0900
> Ryan Davis<[e-mail]>  wrote:
>
>    
>> You don't actually write your code that way, do you?
>>      
> More or less.  I'm assuming you're commenting on my general style.
> Below would be a full working bit of code.  It's rather pointlessly
> simple but it demonstrates my "way".
>
> ---
> require 'minitest/autorun'
>
> class Whatever
>
>    def foo( string )
>      return string + '!'
>    end
>
> end
>
> class Test_Whatever<  MiniTest::Unit::TestCase
>
>    def setup()
>      @o = Whatever.new
>    end
>
>    def test_foo()
>      assert_equal(
>        ( 'yay!' ),
>        ( @o.foo( 'yay' ) ),
>      )
>    end
>
> end
> ---
>
> I've taken extreme measures to make my code more readable.  While I
> have exceptionally lucid times, I often have a _very_ hard time
> "fitting a program into my head".
>
> The real problem arises when I create magical code on one day and then
> on some other day I am completely unable to comprehend it.
>
> To help, I've been
>
> - Breaking my problems down into sometimes embarrassingly-small pieces
> - .. Each with its own test
> - .. Usually with somewhat redundant comments.
> - I've also thrown away regular alignment conventions.
> - Ignoring performance improvements, preferring clearer and even
>    redundant code. (lots of brackets, stuff on separate lines, trailing
>    commas, etc)
> - Using a very small subset of Ruby's functionality.  Doing things with
>    brute force and which are far less pretty than possible.
>
> In some cases I might even coerce code into something monstrous like
> this:
>
>    def test_foo()
>      assert_equal(
>                ( 'yay!' ),
>        ( @o.foo( 'yay'  ) ),
>      )
>    end
>
> The difference to me is that a bunch of programming that initially took
> me a very long time has now taken me a very short time to rewrite from
> scratch.  Think years to weeks.  The end result is vastly superior in
> every way to me.  Faster, clearer, fully tested.  Most importantly I'm
> enjoying myself!
>
> I know that this means that if I ever manage to function with regular
> style conventions I will be forced to re-rewrite everything to follow
> them.  If it came to that, I would be pleased to do it.. I love that
> kind of grunt work.  =)
>
> I know I'm learning bad habits, my code will be "unreadable" to others,
> I may not be able to read the source of others very well, and there are
> probably lots of other issues.. but I needed a new way to approach
> programming.  It's either that or I just give up.
>    
*Hurrrah for you. There is a growing body of people out there who have 
realized that shorthand is idiosyncratic and often unreadable except to 
the "literati" in any special group. I've listened to them since the 
days of COBOL (which is still around and fairly healthy) and before. The 
problem with COBOL was not it's verbosity, but it's lack of modern 
structure and object orientation. These deficits have been largely dealt 
with in recent versions, so COBOL continues to go forward. The 
generation of programmers who wrote COBOL were in many cases converted 
accountants and other business types, so they really did not care about 
constructs like +=, -=, etc., etc., ad infinitum. What they wanted was 
readable code, and through COBOL, they largely got it. Now do understand 
that the most horrendous spaghetti code could be written in COBOL, but 
there were many who understood that and wrote beautifully structured 
code back before that was even a popular term. Now, all that was not 
meant to suggest the use of COBOL, but to suggest that maximizing source 
code rather than minimizing it will pay off in the long run.

In the day, I was as good as any at writing really tricky, fast, and 
short code until I could not move on to other things because no one 
could maintain my code but me. Then, I adopted a different idea. Except 
for extremely time critical code, I put together the "two o'clock rule", 
which basically said that if this code is not going to look familiar and 
largely self documenting at 2am, 6 months from now, I should find 
another way to write it. Outside of those critical pieces of code, which 
should be documented as heavily as possible, performance should be a 
product of the compiler, not the programmer, and that is the weakness of 
almost all of the smaller languages, that their compilers just do not 
receive the resources necessary to produce really powerful optimization. 
Variable names should be largely self-documenting, even if that requires 
more characters than the geeks are willing to type, and the omission or 
inclusion of some special prefix, post-fix, or infix character should 
not change the meaning of the code, especially not in subtle ways. Where 
possible, variables should be static rather than dynamic, even if that 
means a few extra copies or transforms. At least with static variables, 
debugging is a whole lot easier, and compiler level optimization is 
orders of magnitude easier. And, for every byte lost to those static 
variables, there are a few mega or gigabytes lost to dynamic variables 
that are not garbage collected correctly or that are just created in error.

For all those verbose code sequences (usually much easier for the 
compiler to handle) and variables, there are auto-completion 
editors/IDE's that can save most of the keystrokes. Having worked as a 
maintenance programmer in my early years and as a diagnostician on just 
anything that came by when I was a Senior Systems Programmer, I can 
testify to the beauty of the type of code that you are attempting to 
apologize for. Keep writing it and try to make it the standard wherever 
you work. If the compiler you are using cannot sufficiently optimize, 
get another for that language, or get another language, but don't worry 
too much about that side of things. Almost any modern, well supported 
language can be used for almost any project, though there are lots of 
aspects to such selections. Continue to use as small a subset of the 
language as is necessary to keep your code clear and understandable, and 
require massive documentation when trickier facets are used.

There will always be coders who can produce unreadable garbage, but 
every company who employs such should ride herd on them to do what I 
have noted above. It is still true that the cost of writing code is only 
10-20% of the life-cycle cost of a program. I have gone so far as to 
mandate the use of code beautifiers, so that all code will look like 
what you have written. The size of the source code is completely 
irrelevant, and the size of the object code is increasingly so.

Everett L.(Rett) Williams II
*