*Spiral,*
spiralofhope 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
···
On Sun, 27 Mar 2011 05:12:51 +0900 > Ryan Davis<ryand-ruby@zenspider.com> wrote:
*