From: Gavin Sinclair Date: 2002-09-27T08:51:04+09:00 Subject: Re: Ruby - common pitfalls? ----- Original Message ----- From: "Rudolf Polzer" > The problem is just that this if line is equal to Pascal's: > > if foo = nil then > begin > { ... } > end > > Note that the first line is completely equal. When reading the above > code, I'm tempted to "parse" it as Pascal code and oversee the > assignment. > > > Also, you know, the parentheses are really > > optional in the condition, independent of all other things. > > The problem is just, that it: > > - looks better with the "then" > - if the "then" is there, it looks like Pascal > > But I just found a workaround (which already works): > > if foo == nil; then # bash-like > # ... > end > > Maybe it's less tempting to write a Pascal-style equality test if the if > syntax does not look exactly like Pascal. Instead of finding "workarounds" to make Ruby look like Pascal or Bash, why not just learn Ruby properly? Use -w always. > > ---------------------------------------------------------------------------- > > > - accessing one character in a string. > > > > > s[3] does not do what most programmers would expect: > > > it returns a *number*. JavaScript is cleaner in this thing - there > > > are both .charAt () and .charCodeAt (). IMHO s[n] should return the > > > character as a string of length one, not the value - but now it's > > > too late to change this. The current meaning is not bad, it's just > > > unusual. > > > s[3, 1] is to be used instead. This is a good point. Did you know that where you expect to write if string[3] == "e" you can write if string[3] == ?e or if string[3].chr == "e" so all is not lost. > > > ---------------------------------------------------------------------------- > > > - a %= b versus %=...=. A syntax highlighter gets into big trouble when > > > seeing this construct. Nothing really seriuos, but I already had to > > > insert "useless" comments to fix vim's highlighting - which is unable > > > to correctly highlight if-then-end expressions. Perhaps it would help > > > to deprecate %=...= as string separator (any other character could be > > > used with less problems). > > So use another character. Cheers, Gavin