CamelCase issues

ruby-talk
1

Hi,

For method names that contain up to two words, I really prefer the
underscore-case (e.g., has_key?, method_missing). But if the method name
contains more than two words that starts to look ugly IMO. It even looks
strange (IMO) if you use underscore-case very often in your program
(everything is small, no contrast for your eyes):

  c.form.url("foo").with {
    c.table {
      c.table_row.id("myrow").with {
        c.table_data.align_top.col_span(3).with("Hello world")
      }
      c.table_row_with_data {
        c << "Foo:"
        c.text_input.value(myobject.foo).callback(myobject, :foo=)
      }
    }
  }

Versus:

  c.form.url("foo").with {
    c.table {
      c.tableRow.id("myrow").with {
        c.tableData.alignTop.colSpan(3).with("Hello world")
      }
      c.tableRowWithData {
        c << "Foo:"
        c.textInput.value(myobject.foo).callback(myobject, :foo=)
      }
    }
  }

(and if you know that there's a class TableData, shouldn't the method be
named tableData instead of table_data ?)

I know that underscore-case is the perfered way in Ruby.

Some more examples:

  render_content_on <-> renderContentOn
  render_table_header_on <-> renderTableHeaderOn

Which one would you prefer? Thanks.

Regards,

  Michael

2

"Michael Neumann" <mneumann@ntecs.de> schrieb im Newsbeitrag
news:20041021091218.GC983@miya.intranet.ntecs.de...

Hi,

For method names that contain up to two words, I really prefer the
underscore-case (e.g., has_key?, method_missing). But if the method name
contains more than two words that starts to look ugly IMO. It even looks
strange (IMO) if you use underscore-case very often in your program
(everything is small, no contrast for your eyes):

  c.form.url("foo").with {
    c.table {
      c.table_row.id("myrow").with {
        c.table_data.align_top.col_span(3).with("Hello world")
      }
      c.table_row_with_data {
        c << "Foo:"
        c.text_input.value(myobject.foo).callback(myobject, :foo=)
      }
    }
  }

Versus:

  c.form.url("foo").with {
    c.table {
      c.tableRow.id("myrow").with {
        c.tableData.alignTop.colSpan(3).with("Hello world")
      }
      c.tableRowWithData {
        c << "Foo:"
        c.textInput.value(myobject.foo).callback(myobject, :foo=)
      }
    }
  }

(and if you know that there's a class TableData, shouldn't the method be
named tableData instead of table_data ?)

I know that underscore-case is the perfered way in Ruby.

Some more examples:

  render_content_on <-> renderContentOn
  render_table_header_on <-> renderTableHeaderOn

Which one would you prefer? Thanks.

I'd stick with underscore style. IMHO readability is not really improved
with camel case (might depend on screen, font and coloring though) and the
only advantage is that you save some chars.

It might be different for you but I have to use more than three
identifiers separated by a dot very rarely; so from my personal experience
the example you showed seems to be rather exceptional than regular - YMMV
though. I don't know the classes of your example so I don't know whether
these chains *have* to be there because all invocations create new
instance. If not, i.e., if some of those methods just return self, I'd
rather resort to multiple lines with individual invocations.

My 0.02EUR...

Kind regards

    robert

3

Hi,

For method names that contain up to two words, I really prefer the
underscore-case (e.g., has_key?, method_missing). But if the method name
contains more than two words that starts to look ugly IMO. It even looks
strange (IMO) if you use underscore-case very often in your program
(everything is small, no contrast for your eyes):

  c.form.url("foo").with {
    c.table {
      c.table_row.id("myrow").with {
        c.table_data.align_top.col_span(3).with("Hello world")
      }
      c.table_row_with_data {
        c << "Foo:"
        c.text_input.value(myobject.foo).callback(myobject, :foo=)
      }
    }
  }

Versus:

  c.form.url("foo").with {
    c.table {
      c.tableRow.id("myrow").with {
        c.tableData.alignTop.colSpan(3).with("Hello world")
      }
      c.tableRowWithData {
        c << "Foo:"
        c.textInput.value(myobject.foo).callback(myobject, :foo=)
      }
    }
  }

Not every single word need to be divided. There is a balance I think:

   c.form.url("foo").with {
     c.table {
       c.tablerow.id("myrow").with {
         c.tabledata.aligntop.colspan(3).with("Hello world")
       }
       c.tablerow_with_data {
         c << "Foo:"
         c.textinput.value(myobject.foo).callback(myobject, :foo=)
       }
     }
   }

(and if you know that there's a class TableData, shouldn't the method be
named tableData instead of table_data ?)

I know that underscore-case is the perfered way in Ruby.

Actually I would like to see Ruby move away from the significance of
capitalization if possible.

T.

···

On Thursday 21 October 2004 05:12 am, Michael Neumann wrote:

4

Actually, I'd prefer

content.render_on and
table.header.render_on

but I'm not sure if that's an answer to your question :slight_smile:

s.

···

On Thu, 21 Oct 2004 18:12:23 +0900, Michael Neumann <mneumann@ntecs.de> wrote:

Some more examples:

  render_content_on <-> renderContentOn
  render_table_header_on <-> renderTableHeaderOn

Which one would you prefer? Thanks.

5

"Michael Neumann" <mneumann@ntecs.de> schrieb im Newsbeitrag
news:20041021091218.GC983@miya.intranet.ntecs.de...
> Hi,
>
> For method names that contain up to two words, I really prefer the
> underscore-case (e.g., has_key?, method_missing). But if the method name
> contains more than two words that starts to look ugly IMO. It even looks
> strange (IMO) if you use underscore-case very often in your program
> (everything is small, no contrast for your eyes):
>
> c.form.url("foo").with {
> c.table {
> c.table_row.id("myrow").with {
> c.table_data.align_top.col_span(3).with("Hello world")
> }
> c.table_row_with_data {
> c << "Foo:"
> c.text_input.value(myobject.foo).callback(myobject, :foo=)
> }
> }
> }
>
> Versus:
>
> c.form.url("foo").with {
> c.table {
> c.tableRow.id("myrow").with {
> c.tableData.alignTop.colSpan(3).with("Hello world")
> }
> c.tableRowWithData {
> c << "Foo:"
> c.textInput.value(myobject.foo).callback(myobject, :foo=)
> }
> }
> }
>
> (and if you know that there's a class TableData, shouldn't the method be
> named tableData instead of table_data ?)
>
> I know that underscore-case is the perfered way in Ruby.
>
> Some more examples:
>
> render_content_on <-> renderContentOn
> render_table_header_on <-> renderTableHeaderOn
>
> Which one would you prefer? Thanks.

I'd stick with underscore style. IMHO readability is not really improved
with camel case (might depend on screen, font and coloring though) and the
only advantage is that you save some chars.

I usually agree. Hmm strange, now the example with underscores starts to
look better :wink:

It might be different for you but I have to use more than three
identifiers separated by a dot very rarely; so from my personal experience
the example you showed seems to be rather exceptional than regular - YMMV
though. I don't know the classes of your example so I don't know whether
these chains *have* to be there because all invocations create new
instance. If not, i.e., if some of those methods just return self, I'd
rather resort to multiple lines with individual invocations.

No, these chains are not exceptional! And yes, they return self most of
the time. It's a port of Seaside2's new Html rendering scheme.

My 0.02EUR...

Thanks.

Regards,

  Michael

···

On Thu, Oct 21, 2004 at 06:34:20PM +0900, Robert Klemme wrote:

6

Then, how about file names? Do you prefer underscore-style, too?
For example:

  session_store.rb vs.
  SessionStore.rb

Shouldn't they be named after the class (camelcase)?

Regards,

  Michael

···

On Thu, Oct 21, 2004 at 06:34:20PM +0900, Robert Klemme wrote:

> Which one would you prefer? Thanks.

I'd stick with underscore style. IMHO readability is not really improved
with camel case (might depend on screen, font and coloring though) and the
only advantage is that you save some chars.

7

> Some more examples:
>
> render_content_on <-> renderContentOn
> render_table_header_on <-> renderTableHeaderOn
>

To add more confusion to this thread ...

A user of this API might have a question. Does render_content_on
change a value or return the current one, based on whether it has
parameters? It's hard to tell.

To clean this up, I'd be apt to use attr_reader and attr_writer, while
overriding the render_content= function.

Trivial accessor and mutator methods are not something I'm a fan of,
I'd like to keep field syntax when things are simple. I mean, we
could write a render_content? kind of query function, but what would
be the point?

Let me know if that's totally evil, I'm new here :slight_smile:

--MPD

8

trans. (T. Onoma) wrote:

Actually I would like to see Ruby move away from the significance of
capitalization if possible.

In the QtRuby/Korundum api, I've allowed both camel case and lower case with
underscores method naming - they are equivalent. You can write;

slottest.caption = a.makeStdCaption("DCOP Slot Test")

Or:

slottest.caption = a.make_std_caption("DCOP Slot Test")

Or:

slottest.setCaption(a.makeStdCaption("DCOP Slot Test")

Or:

slottest.set_caption(a.make_std_caption("DCOP Slot Test")

Depending on whether you prefer camel case or using the caption=() as
opposed to the setCaption() or set_caption() method naming.

-- Richard

9

> Some more examples:
>
> render_content_on <-> renderContentOn
> render_table_header_on <-> renderTableHeaderOn
>
> Which one would you prefer? Thanks.

Actually, I'd prefer

content.render_on and
table.header.render_on

Hm, sure, but I've to create the content or table.header object
somewhere.

It's similar as in the following example (where render_table_header_on =~ draw_line_on):

  def draw_line_on(canvas, x, y, w, h)
    ...
  end

  def draw_box_on(canvas, x, y, w, h)
    ...
  end

  def draw_on(canvas)
    draw_line_on(canvas, ....)
    draw_box_on(canvas, ...)
  end

Of course I'd removed the "_on" in the GUI case.
The actual "drawing" is done this way (inside render_xxxx_on):

  renderer.table {
    renderer.row {
      ...
    }
  }

but I'm not sure if that's an answer to your question :slight_smile:

any answer is :slight_smile:

Regards,

  Michael

···

On Fri, Oct 22, 2004 at 05:49:20AM +0900, Stefan Schmiedl wrote:

On Thu, 21 Oct 2004 18:12:23 +0900, > Michael Neumann <mneumann@ntecs.de> wrote:

10

The only significance of capitalisation in Ruby is a single rule:

  * if it begins with a capital letter, it's (probably) a constant

That's quite justifiable and shouldn't change, IMO. The only change
I'd like to see is the "(probably)" removed, which would outlaw
methods like Kernel.Integer().

Gavin

···

On Friday, October 22, 2004, 3:27:47 AM, trans. wrote:

Actually I would like to see Ruby move away from the significance of
capitalization if possible.

11

Then, how about file names? Do you prefer underscore-style, too?
For example:
  session_store.rb vs.
  SessionStore.rb

Shouldn't they be named after the class (camelcase)?

I prefer session-store.rb (like many filenames in the standard Ruby dist). There is no reason to use SessionStore. A Ruby source file
may contain multiple Ruby classes.

George

···

--
www.navel.gr | tel: +30 2106898050 | fax: +30 2106898437

Navel does not accept liability for any errors, viruses or omissions in the contents of this message. The full corporate policy is available on our site.

have fun: www.joy.gr

12

"Michael Neumann" <mneumann@ntecs.de> schrieb im Newsbeitrag
news:20041021100547.GF983@miya.intranet.ntecs.de...

> > Which one would you prefer? Thanks.
>
> I'd stick with underscore style. IMHO readability is not really

improved

> with camel case (might depend on screen, font and coloring though) and

the

> only advantage is that you save some chars.

Then, how about file names? Do you prefer underscore-style, too?
For example:

  session_store.rb vs.
  SessionStore.rb

Shouldn't they be named after the class (camelcase)?

Hm, never though of that much. But I'd say, if a file contains only one
class, name it after that class, otherwise choose the name that seems most
appropriate (whatever that is :-)).

Kind regards

    robert

···

On Thu, Oct 21, 2004 at 06:34:20PM +0900, Robert Klemme wrote:

13

In this case, I would simply call it:

    sessionstore.rb

In other words, I deal with filenames that contain a single class (or
the main class, even) as class.to_s.downcase for the filename.

-austin

···

On Thu, 21 Oct 2004 19:05:54 +0900, Michael Neumann <mneumann@ntecs.de> wrote:

On Thu, Oct 21, 2004 at 06:34:20PM +0900, Robert Klemme wrote:
> > Which one would you prefer? Thanks.
> I'd stick with underscore style. IMHO readability is not really improved
> with camel case (might depend on screen, font and coloring though) and the
> only advantage is that you save some chars.
Then, how about file names? Do you prefer underscore-style, too?
For example:

  session_store.rb vs.
  SessionStore.rb

Shouldn't they be named after the class (camelcase)?

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca
: as of this email, I have [ 5 ] Gmail invitations

14

> > Some more examples:
> >
> > render_content_on <-> renderContentOn
> > render_table_header_on <-> renderTableHeaderOn
> >

To add more confusion to this thread ...

A user of this API might have a question. Does render_content_on
change a value or return the current one, based on whether it has
parameters? It's hard to tell.

  def render_content_on(renderer)
    renderer << "<html>...</html>"
  end

It renders content on a "canvas" (in GUI-speak if you like).

It always takes one parameter.

To clean this up, I'd be apt to use attr_reader and attr_writer, while
overriding the render_content= function.

Trivial accessor and mutator methods are not something I'm a fan of,
I'd like to keep field syntax when things are simple. I mean, we
could write a render_content? kind of query function, but what would
be the point?

Let me know if that's totally evil, I'm new here :slight_smile:

I don't really understand your last sentences...

Regards,

  Michael

···

On Fri, Oct 22, 2004 at 06:17:47AM +0900, Michael DeHaan wrote:

15

I do this for some of my own libraries (because I want the method to be RDoc'd as an attribute, but need to do something custom when setting), but be forewarned that this will cause Ruby to throw a warning about redefining the foo= method:

# The Dir instance or path to the directory to watch.
attr_accessor :directory
def directory=( dir ) #:nodoc:
    @directory = dir.is_a?(Dir) ? dir : Dir.new( dir )
end

[Slim:~/Sites/_rubylibs] gavinkis% ruby DirectoryWatcher.rb
[Slim:~/Sites/_rubylibs] gavinkis% ruby -w DirectoryWatcher.rb
DirectoryWatcher.rb:98: warning: method redefined; discarding old directory=

···

On Oct 21, 2004, at 3:17 PM, Michael DeHaan wrote:

To clean this up, I'd be apt to use attr_reader and attr_writer, while
overriding the render_content= function.

16

Understood. Consistency in whatever form is nice. I have a made a few
different suggestions in the past related to this. On one occasion someone
(and I can't recall who it was unfortunately) made a fair argument against
dependency on capitalization, as it also hampers progression into
internationalization. Perhaps that's too forward looking --maybe Ruby will
never be coded in Bengali, for instance, or any other language which have no
capitalized forms. But I would like to look in that direction at least.

T.

···

On Thursday 21 October 2004 08:28 pm, Gavin Sinclair wrote:

On Friday, October 22, 2004, 3:27:47 AM, trans. wrote:
> Actually I would like to see Ruby move away from the significance of
> capitalization if possible.

The only significance of capitalisation in Ruby is a single rule:

  * if it begins with a capital letter, it's (probably) a constant

That's quite justifiable and shouldn't change, IMO. The only change
I'd like to see is the "(probably)" removed, which would outlaw
methods like Kernel.Integer().

17

> Some more examples:
>
> render_content_on <-> renderContentOn
> render_table_header_on <-> renderTableHeaderOn
>
> Which one would you prefer? Thanks.

Actually, I'd prefer

content.render_on and
table.header.render_on

Hm, sure, but I've to create the content or table.header object
somewhere.

Yes, that's the point. Long method names as in your example
sometimes point towards missing objects.

It's similar as in the following example (where render_table_header_on =~ draw_line_on):

  def draw_line_on(canvas, x, y, w, h)
    ...
  end

  def draw_box_on(canvas, x, y, w, h)
    ...
  end

  def draw_on(canvas)
    draw_line_on(canvas, ....)
    draw_box_on(canvas, ...)
  end

Who does all of this drawing? It looks like some unknown power is doing
(and knowing) way too much.

class Painter
  def draw_on(canvas)
    canvas.draw(contents)
  end
end

module Canvas
  def draw(commands)
    commands.each do |cmd| ... end
  end
end

class GUICanvas
include Canvas
  def line(x0, y0, x1, y1)
    moveto(x0, y0)
    lineto(x1, y1)
  end
  def box(l, t, w, h)
    line(l, t, l+w, t)
    ... etc
  end
end

def PSCanvas
include Canvas
  def initialize(out)
    @out=out
  end
  def line(x0, y0, x1, y1)
    out.puts "#{x0} #{y0} moveto"
    out.puts "#{x1} #{y1} lineto"
  end
  ... etc
end

Of course I'd removed the "_on" in the GUI case.
The actual "drawing" is done this way (inside render_xxxx_on):

  renderer.table {
    renderer.row {
      ...

If I were the renderer, I'd have a headache from all the knowledge that
you must have stuffed into my poor brain :slight_smile: There must be a better way
to do this.

but I'm not sure if that's an answer to your question :slight_smile:

any answer is :slight_smile:

I'll remember this, Michael ;>

s.

···

On Fri, 22 Oct 2004 07:36:12 +0900, Michael Neumann <mneumann@ntecs.de> wrote:

On Fri, Oct 22, 2004 at 05:49:20AM +0900, Stefan Schmiedl wrote:

On Thu, 21 Oct 2004 18:12:23 +0900, >> Michael Neumann <mneumann@ntecs.de> wrote:

18

* George Moschovitis <gm@navel.gr> [Oct 21, 2004 12:20]:

> Then, how about file names? Do you prefer underscore-style, too?
> For example:

> session_store.rb vs.
> SessionStore.rb

> Shouldn't they be named after the class (camelcase)?

I prefer session-store.rb (like many filenames in the standard Ruby
dist). There is no reason to use SessionStore. A Ruby source file
may contain multiple Ruby classes.

definitely,
  nikolai

···

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

19

Brief and interesting read.

  http://en.wikipedia.org/wiki/CamelCase

T.

20

errrrr... what would I do with Bengali source code?

Kind regards,
s.

···

On Fri, 22 Oct 2004 10:56:34 +0900, trans. (T. Onoma) <transami@runbox.com> wrote:

On one occasion someone (and I can't recall who it was unfortunately)
made a fair argument against dependency on capitalization, as it also
hampers progression into internationalization. Perhaps that's too
forward looking --maybe Ruby will never be coded in Bengali, for
instance, or any other language which have no capitalized forms. But I
would like to look in that direction at least.