Hugh Laurie's song for America

The OMG Cat / Az "Óh, jajj, Istenem!" macska

Original / Eredeti

~ sees car accident / ~ autóbalesetet lát

OMG Cat sees Car Accident - watch more funny videos

Ruby is not good at comments

Problem

Imagine that you are hard-coding some long list into your Ruby code and you need to

• wrap the long line into multiple lines
• comment on some items

Let's look at the 1st goal (imagine a lot longer list)!

@@import_fields = [ \
    "Name" \
    , "Organization" \
    , "Role" \
    , "Internal ID" \
];

Pretty ugly, because the statement separator is the newline and you should escape it. But doable. Let's move on!

Completing the second goal is not possible. The only commenting option is the line-commenting which is starts with the # sign and ends when the line ends. If you place the comment before the backslash (\), your interpreter will not detect the newline escaper backslash. If you place the comment after it, then it stops being a newline escaper.

Nonexistent solutions

• The Ruby guys failed to add statement separators / terminators to the language and that remains this way. I think the intention was to make life easier, but I believe they made it harder. Someone someday may enlighten me.
• They should introduce block comments. It would be backward compatible and would make the World a better place.
• Or they should detect the newline escaping after the # sign.

Workaround

@@import_fields = []
@@import_fields << "Name"
@@import_fields << "Organization" # Some clever saying about this field
@@import_fields << "Role"
@@import_fields << "Internal ID" # And some eternal wisdom about this

If you know a better way, don't hesitate to tell me!

Indent with TABs, format with spaces

TABs vs spaces

1st: Visible with

They say that TABs are rendered differently by different softwares and devices. I cannot accept that. Read on.

UNICODE 2.0 released in year 1996. In around 2001 people wanted to kill me because I used UTF-8 characters on IRC, and they argued that their [not so good] software cannot render them correctly. I ignored them. Their [not so good] software became advanced, their minds became open.

Editors and devices where the visible width of TAB characters cannot be adjusted are not so good. TAB is not a new invention at all.

2nd: Formatting

TABs are not for formatting. They are only for indenting.

int·main()
{
→   printf("Hello·%s!\n",·//·I·like·to·move·it,
→   ·······"World");······//·move·it.
→   return 0;
}

If you want to graphically align something then you should use SPACES. If you are expressing the depth of control, then you should use TAB. The above code will maintain it's visual, see:

int·main()
{
→   {·//·Ad-hoc·block·begin
→   →   printf("Hello·%s!\n",·//·I·like·to·move·it,
→   →   ·······"World");······//·move·it.
→   →   return·0;
→   }·//·Ad-hoc·block·end
}

3rd: Freedom

See what happens when visible with of TAB is set to 8, because someone may like it that way:

int·main()
{
→       {·//·Ad-hoc·block·begin
→       →       printf("Hello·%s!\n",·//·I·like·to·move·it,
→       →       ·······"World");······//·move·it.
→       →       return·0;
→       }·//·Ad-hoc·block·end
}

The hairdo is still tight.

What if someone's favorite visual TAB size is 2?

int·main()
{
→ {·//·Ad-hoc·block·begin
→ → printf("Hello·%s!\n",·//·I·like·to·move·it,
→ → ·······"World");······//·move·it.
→ → return·0;
→ }·//·Ad-hoc·block·end
}

The hairdo is still tight.

4th: Symbolism

From my heart: http://www.mail-archive.com/vim_use@googlegroups.com/msg18895.html

Favorite part: ... tabs for leading indent, spaces everywhere else. I prefer this strategy for the same reason I prefer to use symbolic names for constants, rather than embedding numeric literals throughout my source code ...