Any guides for good coding in Ruby?

ruby-talk
21

James Edward Gray II <james@grayproductions.net> writes:

I can't decide if it's just the example or the whole section, but this
one just doesn't feel right to me. I would much rather have a class
rendering itself (who better qualified?), then providing accessor like
data for others to do it. Push, don't pull, right?

If you have a class just providing data for others to render then you
can much more easily implement renderers than if you have to modify
your data class for each format you care to render it into.

-=Eric

···

--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.

22

I can't decide if it's just the example or the whole section, but this
one just doesn't feel right to me. I would much rather have a class
rendering itself (who better qualified?), then providing accessor like
data for others to do it. Push, don't pull, right?

I see what you mean, and I agree with you about that particular
section. ( also, it's especially noted in the title that is not a
specific Ruby idiom.)

I believe that this pattern may well be domain-specific to a certain
technique of graphics rendering, and that's probably not the best
place to put that piece of code.
(but it's a wiki, you know...)
  
wrt that specific section, I would also argue that I can barely see
the need for abstract classes like that in any Ruby code.

An excellent book on this topic is Holub on Patterns, if you're
interested.
Anyway, just wanted to share. I really did love the page.

Thank you for the recommendation.
cheers,
                        vruz

23

James Edward Gray II wrote:

It's not a Ruby API design idiom, but anyway (perhaps we should split this page in two: Ruby API idioms and design advices).

Classes are supposed to reflect reality. Thus, you should generally put your methods where they belong, to reduce coupling. For example, typical "data classes" should not have "actions", but methods to access their data.

Example:
  #
  # Bad API
  #
  class GraphicElement
     def draw(canvas)
        raise "Implement me!"
     end
  end
  class Circle < GraphicElement
     def draw(canvas)
        # Draw directly into the canvas
        # (couples Circle with the canvas, as Circle
        # follows this particular canvas API)
     end
  end

  #
  # Good API (definitely better than above, perhaps not the best)
  #
  class GraphicElement
     def to_canvas(resolution)
        raise "Implement me!"
     end
  end
  class Circle < GraphicElement
     def to_canvas(resolution)
        # Convert circle to an array of arrays of pixels,
        # taking into account the resolution parameter
     end
  end
  class CanvasPainter
     def paint(elmt, canvas, color=Color::BLACK,
                             centerX=0, centerY=0)
        elmt.to_canvas.each do |x,y|
           canvas.put(centerX+x, centerY+y, color)
        end
     end
  end

I can't decide if it's just the example or the whole section, but this one just doesn't feel right to me. I would much rather have a class rendering itself (who better qualified?), then providing accessor like data for others to do it. Push, don't pull, right?

I think this is related to double dispatch. There'll probably be a Surface#draw that takes an object and calls #to_canvas on it. This way both objects can handle part of the drawing contract by meeting in the middle.

24

Florian Gross wrote:

Nifty code, though I wonder if it could be simplified by using String#rindex?

I do not see any use of String#rindex that would simplify the code but
String#scan can do something for us:

def threepack(x)
   return x unless x.class == String
   if /^[-+]?\d+\.\d+$/.match(x)
     match = /((\d\d\d)+)(?=\.)/.match(x)
   elsif /^[-+]?\d+$/.match(x)
     match = /((\d\d\d)+)$/.match(x)
   end
   return x if match.nil?
   result = match.pre_match
   result << ',' unless ['', '-', '+'].member?(result)
   result << match[1].scan(/.../).join(',')
   result << match.post_match unless match.post_match.nil?
   result
end

An alternative solution using a complex Regexp is:

def threepack(x)
   return x unless x.class == String
   match = /^([-+]?)((\d{1,2})?)((\d{3})+)((\.\d+)?)$/.match(x)
   return x if match.nil?
   result = match[2].empty? ? match[1] : match[1] + match[2] + ','
   result + match[4].scan(/.../).join(',') + match[6]
end

match[1] is the sign, match[2] is the digits before the three-digit
blocks, match[4] is the concatenation of all three-digit blocks,
match[6] is what follows the three-digit blocks. The strings are empty
if the given part is absent.

Josef 'Jupp' Schugt

···

--
Damnant quod non intelligunt.

25

* Jon A. Lambert <jlsysinc@alltel.net> [2005-04-24 19:47:10 +0900]:

This would make an excellent addition and possibly foundation for Ruby
report writing applications.

As a somewhat related aside, in my own little language, I implement a fixed
decimal type in addition to float and binary along the same lines of IBM's
C extension which was submitted to ANSI many years ago.

decimal(15,2) x;

Hmm, could this be emulated with a wrapper around BigDecimal?

···

--
Jim Freeze
Code Red. Code Ruby

26

According to my COBOL tutorial (I currently don't have a COBOL
compiler up and running) COBOL uses "DB".

After some careful analysis of the PIC strings I came to the
conclusion that they have too many shortcomings. I am presently
considering some "%xyz" notation that removes them. Only non-digits
are used so that prefixing xyz with a digit string can be used to
express repetition. I tried my best to make the formatting strings
mnemonic. It seems to make sense to allow for customization of what
'c' and 'd' are displayed as. Comments are welcome and essential:

1 digit ("_")
  digit is displayed using "_". prefix controls zero.

  1.1 blank zero ("_" or " _")
      prefix " " displays zero as " ". default.

  1.2 show zero ("!_")
      prefix "!" displays zero as "0".

  1.3 secure ("*_")
      prefix "*" displays zero as '*'.

2 sign ("-")
  sign is displayed using '-'. prefix controls non-negative sign.

  2.1 blank non-negative sign (" -")
      prefix " " displays non-negative sign as " ". default. prefix
      controls zero's sign.

      2.1.1 blank zero's sign (" -")
      prefix " " displays zero's sign as " ". default.

      2.1.2 positive zero's sign ("+ -")
      prefix "+" displays zero's sign as "+".

      2.1.3 negative zero's sign ("- -")
      prefix "-" displays zero's sign as "-".

      2.1.4. secure zero's sign ("* -")
       prefix "*" displays zero's sign as "*".

  2.2 show non-negative (sign ("+-")
      prefix "+" displays non-negative sign as "+".

      2.2.1 blank zero's sign
      prefix " " displays zero's sign as " ".

      2.2.2 positive zero's sign
      prefix "+" displays zero's sign as "+". default.

      2.2.3 negative zero's sign
      prefix "-" displays zero's sign as "-".

      2.2.4 secure zero's sign
      prefix "*" displays zero's sign as '*'

  2.3 secure non-negative sign ("*-")
      prefix "*" displays non-negative sign as "*". prefix controls
      display of zero's sign. note that prefix " " is prohibited
      because it would contradict purpose of "*".
      
      2.3.1 positive zero's sign ("+*-")
      prefix "+" displays zero's sign as "+".

      2.3.2 negative zero's sign ("-*-")
      prefix "-" displays zero's sign as "-"

      2.3.3 secure zero's sign ("**-")
      prefix "*" displays zero's sign as "*". default.

  2.4 shortcuts
      default rules are such that shorthands exist for most likely
      displays of sign (most likely is only displaying negative sign,
      next is displaying zero's sign as if zero were positive).

      2.4.1 "-" has same meaning as " -" and " -":
      displays "-" if negative, ' ' otherwise

      2.4.2 "+-" has same meaning as "++-":
      displays "-" if negative, "+" otherwise.

      2.4.3 "*-" has same meaning as "**-":
      displays "-" if negative, "*" otherwise.

3 separator (",")
  separator is displayed using ",". Prefix controls behavior if no
  non-zero digits preceed.

  3.1 blank separator (" ,")
      displays " " in place of "," if no non-zero digits
      preceede. default.

  3.2 secure separator ("*,")
      displays "*" in place of "," if no non-zero digits preceed.

4. decimal point (".")
   decimal point is displayed using "."

5. currency symbol ("$")
   currency symbol is displayed using "$".

6. credit ("c")
   displays 'CR' in the case of credit (i.e. a value smaller than
   zero). prefix controls display in case of non-credit.

   6.1 blank credit (" c")
       displays two blanks (" ") in case of non-credit

   6.2 secure credit ("*c")
       displays two asterisks ("**") in case of non-credit

   6.3 zero is credit ("!c", "! c", "!*c")
       zero is assumed to be credit. default is not to do this.

7. debit ("d")
   displays 'DB' in the case of debit (i.e. a value not smaller than
   zero). prefix controls display in case of non-debit

   7.1 blank debit (" d")
       displays two blanks (" ") in case of non-debit.

   7.2 secure debit ("*d")
       displays two asterisks ("**") in case of non-debit.

   7.3 zero is debit ("!d", "! d", "!*d")
       zero is assumed to be debit. default is not to do this.

Josef 'Jupp' Schugt

···

At Mon, 25 Apr 2005 03:35:09 +0900, Michael Campbell wrote:

One small nit; "Debit" is usually indicated (counter-intuitively) by
"DR", not "DB" (though I have seen both.) No idea if there is a
standard for this, or what it says.

--
Hab nun ach, Thunderbird, Mutt, Mew, Pine und leider auch Outlook
durchaus studiert, mit heissem Bemuehn. Hier steh ich nun, ich armer
Tor - und kram den Wanderlust hervor :slight_smile:

27

I don't know why the world doesn't code everything the way I do. It makes the
most sense to me!

···

On Tuesday 22 March 2005 02:48 pm, James Edward Gray II wrote:

On Mar 22, 2005, at 4:24 PM, Martin Ankerl wrote:
> I also do this, but there is one thing I cannot stand: every ruby lib
> uses 2 spaces for indentation! IMHO it should be tabs, and *only*
> tabs. This is much better, because in almost every editor it is
> possible to set the tab width to whatever one likes. I hate 2 spaced
> sourcecode, because I usually set one tab == 8 spaces, and use a
> non-fixed font.

Amen! I don't know who thought up the two space thing, but they were
out of line. :slight_smile: In Ruby, you don't even need the extra characters to
keep lines short, generally. I'm set tabs to four spaces wide, but
it's definitely tabs all the way.

And while we're getting things off our chest, it really bugs me when
people don't keep their code within the 80 character boundary
guideline. I've been reading all the links posted in this thread and
they've all recommended it, but I can sure tell you from running Ruby
Quiz that not everyone is listening. :wink:

James Edward Gray II

28

Quoting bg-rubytalk@infofiend.com, on Wed, Mar 23, 2005 at 08:17:53AM +0900:

Martin Ankerl wrote:
>>I try to follow the style that is predominant in the Ruby parts of the
>>Ruby source. Also, see:
>
>I also do this, but there is one thing I cannot stand: every ruby lib
>uses 2 spaces for indentation! IMHO it should be tabs, and *only* tabs.
>This is much better, because in almost every editor it is possible to
>set the tab width to whatever one likes. I hate 2 spaced sourcecode,
>because I usually set one tab == 8 spaces, and use a non-fixed font.

Yay! Let's start a tabs vs. spaces flame war!!

My view? Tabs should never, ever be used in a file. (Ever) Can you
have a source code file without spaces? I doubt it. Can you have a
file without tabs? Certainly. Is mixing the two the main problem?
Yup. Use only spaces.

It's funny though. I think this eternal flame war is related to the
other eternal flame war: vi vs. emacs. In Emacs, the 'tab' button is
most often bound to 'indent-command'. This and 'indent-region' makes it
really easy to use spaces for indentation, and to adjust/fix someone
else's indentation when it's bad. On the other hand, I think vi makes

Select the area, or whole file (%=), and press "=" in vim to do this. I
suspect = is standard on the ancient vi as well.

it much harder to use spaces for indentation, so tabs seem more attractive.

That's funny, I haven't found that emacs uses spaces to indent by
default. Its supposed to default to the GNU coding standard, though what
it does on any machine is pretty subject to the whims of who installed
it. The emacs standard/GNU indent style is the weirdest around, IMO.

foo()
  {
    int ;

    if()
      {
        ...

It uses TAB by default (every time indent gets over 8 chars, it uses a
TAB). I've always though the GNU coding style was specified to showcase
the power of the emacs indentation engine. I never got vim to do it, but
I just fed my functions through GNU indent, and whatever it looked like,
I comitted. Can't be acused of not following the GNU coding standards
then, GNU indents output is supposed to follow it!

I'm pretty easy about coding styles, everwhere I've worked has a
different one, the important thing is that people have the same one if
they work on their code a bunch. I do confess agreement with the 8th
commandment for C programmers:

  Thou shalt make thy program's purpose and structure clear to thy
  fellow man by using the One True Brace Style, even if thou likest it
  not, for thy creativity is better used in solving problems than in
  creating beautiful new impediments to understanding.

Particularly the last phrase abou where your creativity should be
focussed...

The only one style actually dislike is the GNU one. Also I think any
standard that I can't remember is way too detailed.

I'm averse to indents over about 4, and I think tabs are lame. They work
fine if everybody on your team uses the same settings, but when anybody
else looks at your code, it will look bad.

I think a bunch or ruby core developers (matz, for one) use emacs, so
many of the files use tabs, and indent two char widths per nesting
level. Not all, though.

Cheers,
Sam

29

Ok, I did (some) of the required reading, and found some of those
people are crazier than I am (which says a lot, but it's probably a
good thing).

My issue with tabs is mostly due to working on the web a lot, and
using admins that are composed of many textareas. AFAIK, there's not
a browser out there that lets you configure tab width in textareas,
and they all seem to default to the "traditional" 8 spaces.

btw, Mozilla 1.7.2 here, and if you know how to set that, I'll be
happy to hear it, but I'll continue to use my 2 spaces :slight_smile:

Whatever you use (or come across in a file), shouldn't matter too
much, as most programmer's editors allow that to be changed fairly
easily.

···

On Wed, 23 Mar 2005 08:17:53 +0900, Ben Giddings <bg-rubytalk@infofiend.com> wrote:

Martin Ankerl wrote:
>> I try to follow the style that is predominant in the Ruby parts of the
>> Ruby source. Also, see:
>
> I also do this, but there is one thing I cannot stand: every ruby lib
> uses 2 spaces for indentation! IMHO it should be tabs, and *only* tabs.
> This is much better, because in almost every editor it is possible to
> set the tab width to whatever one likes. I hate 2 spaced sourcecode,
> because I usually set one tab == 8 spaces, and use a non-fixed font.

Yay! Let's start a tabs vs. spaces flame war!!

My view? Tabs should never, ever be used in a file. (Ever) Can you
have a source code file without spaces? I doubt it. Can you have a
file without tabs? Certainly. Is mixing the two the main problem?
Yup. Use only spaces.

It's funny though. I think this eternal flame war is related to the
other eternal flame war: vi vs. emacs. In Emacs, the 'tab' button is
most often bound to 'indent-command'. This and 'indent-region' makes it
really easy to use spaces for indentation, and to adjust/fix someone
else's indentation when it's bad. On the other hand, I think vi makes
it much harder to use spaces for indentation, so tabs seem more attractive.

Anyhow, before throwing in your views, at least read up on other
people's arguments. :slight_smile:

"tabs vs spaces" - Google Search

--
Bill Guindon (aka aGorilla)

30

* James Edward Gray II (Mar 22, 2005 23:50):

Amen! I don't know who thought up the two space thing, but they were
out of line. :slight_smile: In Ruby, you don't even need the extra characters to
keep lines short, generally. I'm set tabs to four spaces wide, but
it's definitely tabs all the way.

Messing with the width of tabs is always crazier than using two-space
indents.

I don't see why you would need the extra indent in Ruby anyway, it's
pretty clear without the additional horizontal whitespace.

I began writing Ruby-code with an eight-space tab indent, but it made my
code look chubby (it was wider than it was long).

And while we're getting things off our chest, it really bugs me when
people don't keep their code within the 80 character boundary
guideline. I've been reading all the links posted in this thread and
they've all recommended it, but I can sure tell you from running Ruby
Quiz that not everyone is listening. :wink:

Actually, for the Quiz, 72 would be a better limit, as that works best
for mails.

Seriously, though, the 80 character boundary is a thing of the past.
Terminals (not to mention emulators) can be made wider, 132 being a good
"standard" setting, so it's not even about backwards compatibility
anymore. I find that I can write code the way I want it if I'm not
constrained to 80 characters per line. (I only switched to a
132-character-wide terminal about 3 months ago, though, so I may change
my mind yet again.),
        nikolai

···

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

31

* Eric Schwartz (Mar 23, 2005 01:00):

> I can't decide if it's just the example or the whole section, but
> this one just doesn't feel right to me. I would much rather have a
> class rendering itself (who better qualified?), then providing
> accessor like data for others to do it. Push, don't pull, right?

I agree with you in this instance. It does depend on the setting,
though.

If you have a class just providing data for others to render then you
can much more easily implement renderers than if you have to modify
your data class for each format you care to render it into.

Actually, the best way to solve this problem would be to use the Visitor
pattern, right?,
        nikolai

···

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

32

Nice to have so many experts here :slight_smile: I have actually been fighting around with this issue. I have found that using tabs always gives me headaches somewhere. For example when I paste code examples into emails.

What do I have to set in vim if I always want two spaces (also when I press the tab key)? No exceptions. I essentially want this:

class PageController
   def edit
     case @request.method
       when :get
         @page = Page.find(@params['id'])
       when :post
     ...
   end
end

Sascha

33

In article <4240A7A2.4050703@infofiend.com>,

Martin Ankerl wrote:

I try to follow the style that is predominant in the Ruby parts of the
Ruby source. Also, see:

I also do this, but there is one thing I cannot stand: every ruby lib
uses 2 spaces for indentation! IMHO it should be tabs, and *only* tabs.
This is much better, because in almost every editor it is possible to
set the tab width to whatever one likes. I hate 2 spaced sourcecode,
because I usually set one tab == 8 spaces, and use a non-fixed font.

Yay! Let's start a tabs vs. spaces flame war!!

My view? Tabs should never, ever be used in a file. (Ever) Can you
have a source code file without spaces? I doubt it. Can you have a
file without tabs? Certainly. Is mixing the two the main problem?
Yup. Use only spaces.

Amen. and I am a vi user (see below).
The lucky thing for us Ruby users is that the number of spaces/tabs (while
the two might look the same on the screen) doesn't matter to the
interpreter as it does with another language that starts with a P.

It's funny though. I think this eternal flame war is related to the
other eternal flame war: vi vs. emacs. In Emacs, the 'tab' button is
most often bound to 'indent-command'. This and 'indent-region' makes it
really easy to use spaces for indentation, and to adjust/fix someone
else's indentation when it's bad. On the other hand, I think vi makes
it much harder to use spaces for indentation, so tabs seem more attractive.

Actually, there are autoindent modes for vim - there's one for Ruby code.

Phil

···

Ben Giddings <bg-rubytalk@infofiend.com> wrote:

34

James Edward Gray II wrote:

[... questionable OO design advice ...]

> I can't decide if it's just the example or the whole section, but this
> one just doesn't feel right to me. I would much rather have a class
> rendering itself (who better qualified?), then providing accessor like
> data for others to do it. Push, don't pull, right?

I think this is related to double dispatch. There'll probably be a
Surface#draw that takes an object and calls #to_canvas on it. This way
both objects can handle part of the drawing contract by meeting in the
middle.

This is often handled by the bridge pattern. The canvas object provides low
level primitives (which can be reimplemented for different media) and the
graphical objects draw themselves using the facilities provided by the canvas
objects.

The problem with that particular example is (1) it has little to do with API
design (as it internally admits) and (2) the advice itself is questionable.
Although there are times a pure data object makes sense, the advice is worded
in a way that seems to recommend it. That kind of thought leads to anemic
domain models that are all data and little behavior.

···

On Tuesday 22 March 2005 09:09 pm, Florian Gross wrote:

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

35

Jim Freeze wrote:

* Jon A. Lambert <jlsysinc@alltel.net> [2005-04-24 19:47:10 +0900]:

decimal(15,2) x;
   

Hmm, could this be emulated with a wrapper around BigDecimal?

In the office I have a little something to parse or generate mainframe-style data files. There I can write things like

FooData < AbstractDataRecord
  decimal :some_field, 15, 2
  fixed_ebcdic :some_other_field, 35
end

FooHeader < AbstractDataRecord ...
FooTrailer < AbstractDataRecord ...

FooBarFile < AbstractDataFile
  header FooHeader
  many FooData
  trailer FooTrailer
end

I played with the idea of using BigDecimal, but eventually used strings for internal representation of everything, because it is much easier that way and fast enough for my purposes. If I were to make a report generator, it would probably be the same choice.

···

--
Best regards,

Alexey Verkhovsky

Ruby Forum: http://ruby-forum.org (moderator)
RForum: http://rforum.andreas-s.net (co-author)
Instiki: http://instiki.org (maintainer)

36

Jim Freeze wrote:

Hmm, could this be emulated with a wrapper around BigDecimal?

Certainly. It's only practical purpose would be to automatically keep track of the decimal point during operations. That is I wasn't thinking of actually storing and reading decimals in packed decimal or zoned decimal format.

···

--
J. Lambert

37

* Kent Loobey <kent@darkwing.uoregon.edu> [2005-03-23 08:08:18 +0900]:

···

On Tuesday 22 March 2005 02:48 pm, James Edward Gray II wrote:
> On Mar 22, 2005, at 4:24 PM, Martin Ankerl wrote:

Now that you guys have had a chance to air your feelings,
let's all get back to work, writing Ruby code with 2 spaces,
just as Matz does.

Oh, and by the way, it's four spaces if you are using Ruby C.

:slight_smile:
--
Jim Freeze
Code Red. Code Ruby

38

* Sam Roberts (Mar 23, 2005 00:50):

That's funny, I haven't found that emacs uses spaces to indent by
default. Its supposed to default to the GNU coding standard, though
what it does on any machine is pretty subject to the whims of who
installed it. The emacs standard/GNU indent style is the weirdest
around, IMO.

Yes, but you aren't using it in your example:

foo()
  {
    int ;

    if()
      {
        ...

That would be

<type>
foo(void)
{
  int i;

  if (<test>)
    {
      ...
    }
}

And there is a good reason for doing it that way: the name of the
function appears in column one, making it easy to grep for and for
certain utilities to parse the file. The default
indent-size is two spaces, as can be seen in the third line and also
note how the curly-brackets are in column 1 for a function body. For
the if, the bracket-group is the statement associated with and inside
it, code is indented another level. See how consistent it is? See how
the bracket-delimited block is indented like a single statement to the
if would have been? It's very, very consistent. It's also very, very
ugly.

It uses TAB by default (every time indent gets over 8 chars, it uses a
TAB). I've always though the GNU coding style was specified to showcase
the power of the emacs indentation engine. I never got vim to do it, but
I just fed my functions through GNU indent, and whatever it looked like,
I comitted. Can't be acused of not following the GNU coding standards
then, GNU indents output is supposed to follow it!

It's very easy to do with vim. Simply leave your 'ts' alone, set 'sw' to
8, don't set 'sts' and don't set 'et'. Those are all default settings
by the way.

GNU indent can be set to use any of a variety of indentation
"standards". It can also be configured to your hearts delight.

I'm averse to indents over about 4, and I think tabs are lame. They work
fine if everybody on your team uses the same settings, but when anybody
else looks at your code, it will look bad.

In a perfect world, people would actually use tabs appropriately. Until
they do, the best solution is to not use them,
        nikolai

···

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

39

* Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> [2005-03-23 09:11:59 +0900]:

* James Edward Gray II (Mar 22, 2005 23:50):
> Amen! I don't know who thought up the two space thing, but they were
> out of line. :slight_smile: In Ruby, you don't even need the extra characters to
> keep lines short, generally. I'm set tabs to four spaces wide, but
> it's definitely tabs all the way.

Messing with the width of tabs is always crazier than using two-space
indents.

Boy, I don't know where all this came from, I thought the majority
were all on the same page, but maybe it is because of
all the new people. Maybe we should have a coding standard
linked from ruby-lang.

One problem with tabs is that people tend to mix tabs and spaces,
then, when I set the tab to be 2-spaces, I may get 2,3 or 4 spaced
indents.

···

--
Jim Freeze
Code Red. Code Ruby

40

All space and tab holy war fun aside, I strongly disagree on this point and would like a chance to plead my case. Here's some food for thought: If it's so in the past, why does almost everyone still recommend it?

The truth is that is has nothing to do with terminals anymore, in my not at all humble opinion. You've just pointed out a great reason above: email clients. Here's another one: Web pages. 90% of the problems I have with the current Ruby Quiz site are that the code often overflows the boxes. I hand edit each and every chunk of code in a never-ending battle against this. I'm trying to come up with a good solution for it in the Ruby Quiz 2.0 site, but that's harder than it sounds. I want the new site to include the code as that'll open up a lot of exciting options, but I have to figure out how to do this realistically first and this issue is the biggest hurdle.

Ironically, I still don't think those are the biggest reason to do it.

I believe the number one reason you should still keep code at 80 characters per line is to help authors put your work in their books. It just so happens that a typical programming book with reasonable fonts and light indenting of the code examples has darn near 80 characters of space to play with. You do want everyone writing about your code don't you? I bet you'll shorten that margin back up when you begin writing your first masterpiece. :wink:

To summarize, it isn't just about terminals. Be kind to your email reader, webmaster, and author. Stick with 80.

James Edward Gray II

···

On Mar 22, 2005, at 6:11 PM, Nikolai Weibull wrote:

And while we're getting things off our chest, it really bugs me when
people don't keep their code within the 80 character boundary
guideline. I've been reading all the links posted in this thread and
they've all recommended it, but I can sure tell you from running Ruby
Quiz that not everyone is listening. :wink:

Actually, for the Quiz, 72 would be a better limit, as that works best
for mails.

Seriously, though, the 80 character boundary is a thing of the past.