CamelCase issues

[Michael Neumann]

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

 

[Robert Klemme]

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

 

[Michael Neumann]

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 ;-)

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

 

[George Moschovitis]

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

 

[Michael Neumann]

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)?

Regards,

Michael

 

[Robert Klemme]

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

 

[Austin Ziegler]

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)?

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

 

[Nikolai Weibull]

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

 

[trans. (T. Onoma)]

On Thursday 21 October 2004 05:12 am, Michael Neumann wrote:
| 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.

 

[Stefan Schmiedl]

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

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

s.

 

[Michael DeHaan]

Some more examples:
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

--MPD

 

[Michael Neumann]

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

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

Regards,

Michael

 

[Richard Dale]

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

 

[Michael Neumann]

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

any answer is

Regards,

Michael

 

[Gavin Sinclair]

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().

Gavin

 

[Gavin Kistner]

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

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=

 

[trans. (T. Onoma)]

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().

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.

 

[trans. (T. Onoma)]

Brief and interesting read.

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


T.

 

[Stefan Schmiedl]

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 There must be a better way
to do this.

any answer is

I'll remember this, Michael ;>

s.

 

[Stefan Schmiedl]

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.

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

Kind regards,
s.