Just copied from an old email.

This was something I wrote in response.

---

Below would be a full working bit of code. It’s rather pointlessly simple but it demonstrates my “way”.

(Test::Unit, minitest)

require 'minitest/autorun'
 
class Whatever
 
  def foo( string )
    return string + '!'
  end # def foo( string )
 
end # class Whatever
 
class Test_Whatever < MiniTest::Unit::TestCase
 
  def setup()
    @o = Whatever.new
  end # def setup()
 
  def test_foo()
    assert_equal(
      ( 'yay!' ),
      ( @o.foo( 'yay' ) ),
    )
  end # def test_foo()
 
end # class Test_Whatever < MiniTest::Unit::TestCase

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.

---

For very long methods, it’s useful to have a comment at its final end. When that method is expanded it can take up several screens and I can get lost easily. It’s hidden when the code is collapsed though, so it’s not generally in the way.

Advice from Cynbe ∞

(of Mythryl)

Note – The code presentation likely wrong – it is not meant to wrap. Cynbe intentionally kept very long trailing comments, meant for the reader’s view to be shifted over in a sort of “comment mode”.

As a really teeny but useful hint, I find that two blanks is visually
easy to confuse with a single blank; when I want to be absolutely
clear in introducing a distinction I usually go to three blanks,
but if I just want a subliminal hint I’ll use two:

foo =   bar zot   +   wam bam;        # Triple-spacing jumps off page for separating single-spaced groups.


foo =  bar zot  +  wam bam;           # Double-spacing emphasizes the grouping without being quite so blatant about it.


foo = bar zot + wam bam;              # Uniform single-spacing dazzles the eye, brings speed-reading to a screeching halt.


foo=(bar zot)+(wam bam);              # Parens alone do more harm than good.  Whitespace is almost always better than parens.

Line-up similar-looking code.

But don’t worry so much about dissimilar code. For that kind of code, just indent effectively.

my (f, e)  
    =  
    if   (f <   1.0)    scale_up (f, e);  
    elif (f >= 10.0)    scale_dn (f, e);  
    else                         (f, e);  # This is fine
    fi;

for the sake of exposing the parellelism of the (f, e) constructs.
If the code was something more like

my (f, e)  
    =  
    if   (f <   1.0)    scale_up (f, e);  
    elif (f >= 10.0)    scale_dn (f, e);  
    else                (foo, bar, zot);  # This wasn't indented further like (f, e).  So just left-align it within the column formed by scale_up and scale_dn.
    fi;

Terms, from Cynbe ∞

(of Mythryl)

()     # "parentheses" or just "parens".
[]     # "brackets"
{}     # "curly brackets" or (sometimes) just "curlies".
<>     # "angle brackets" or (sometimes) "brokets".