Style question: when to use underscores

[francisrammeloo]

When should you use underscores to
separate words in variable names or
function definitions? Always?

I tend to use them always for
function definitions like:

calculate_sum
extract_lines
....

But the Ruby built in classes
do not always use them.
For example: IO#readlines
Why not: IO#read_lines ?

Are there any guidelines on this
subject? How do think they should
be used?

 

[EdUarDo]

When should you use underscores to
separate words in variable names or
function definitions? Always?

Never, I use capital letters to separate words.

calculate_sum
extract_lines

calculateSum
extractLines

 

[Daniel Tse]

Sometimes tradition (read: C function names) overrides any other
concerns, but the libraries are usually named such that words are
separated by underscores.
Variable names seem to be a matter of choice but I use the same
convention. Class names, I believe, mandatorily begin with a capital in
Ruby.

jogloran

 

[Florian Frank]

Never, I use capital letters to separate words.

I use spaces to separate words:

class A
define_method('foo bar') do
'foo bar'
end
end
A.new.__send__ 'foo bar'

I think, you should use my way, too.

 

[Austin Ziegler]

Never, I use capital letters to separate words.

This is common in Java and C++, but very uncommon in Ruby except in class n=
ames.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Gene Tani]

(They're not functions, they're methods)

There's also this, it's kinda thin:
http://www.rubygarden.org/ruby?RubyStyleGuide

 

[Brian Schröder]

=20
Never, I use capital letters to separate words.
=20
=20
=20
calculateSum
extractLines
=20
=20

Convention is, that ClassNames are written in CamelCase while
variable_names and function_names are written in snake_case. Obviously
that is not mandatory, but its good to follow conventions like this,
to make the source easier understandable by fellow programmers.

I personally dislake snakeCamels because they are neither here nor there.

regards,

Brian

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

 

[David A. Black]

Hi --

When should you use underscores to
separate words in variable names or
function definitions? Always?

Always or almost always.

I tend to use them always for
function definitions like:

calculate_sum
extract_lines
....

But the Ruby built in classes
do not always use them.
For example: IO#readlines
Why not: IO#read_lines ?

Maybe just because of the familiarity of readline from the readline
library.

Are there any guidelines on this
subject? How do think they should
be used?

A good style guide is:

http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=RubyCodingConvention


David

 

[david]

=20
But the Ruby built in classes
do not always use them.
For example: IO#readlines
Why not: IO#read_lines ?
=20

I find that to be very rare in the standard libs, and almost exclusively =
when
the library in question is a relatively thin C binding. In that specific =
case,
I prefer to iterate over the lines of a file to avoid loading the whole t=
hing
into memory. It's a habit you get into the first time you do a script wor=
king
with 200MB log files

For the love of god, resist the urge to use PascalCase or CamelCase for m=
ethod
names, or more insane conventions like the one with defining and calling
methods reflexively (abandon all hope of an eventual Rite optimizing that=
).
Almost the whole core API and all of the standard lib I've used so far us=
es
underscores everywhere, both of the style guides recommend doing that, an=
d
that's reason enough to do so. A convention should always take preference=
over
personal taste.

Side note: minor snags go to the Python standard lib for using every poss=
ible
convention, not so minor fluffs go to the wxRuby people for ruby-izing th=
e
method names, although I'd welcome the get_foo and set_foo methods to be =
made
into proper accessors while it's still morally acceptable to cause that m=
uch
breakage.

David

 

[Florian Frank]

For the love of god, resist the urge to use PascalCase or CamelCase for method
names, or more insane conventions like the one with defining and calling
methods reflexively (abandon all hope of an eventual Rite optimizing that).

It was a joke, not a serious advice. Come on, laugh, it's funny. Hahaha...

 

[Mohammad Khan]

I use spaces to separate words:

class A
define_method('foo bar') do
'foo bar'
end
end
A.new.__send__ 'foo bar'

why not, just A.new.send 'foo bar' ?

MOhammad

 

[Bill Atkins]

------=_Part_1042_258512.1123095040668
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It's generally better practice to use "__send__" to preven name clashes wit=
h=20
methods named "send". Using #__send__ helps ensure that you're actually=20
sending a message to the object rather than calling a user-defined method=
=20
that does something totally different (like Socket#send in the standard=20
library).

Bill

=20

=20
why not, just A.new.send 'foo bar' ?
=20
MOhammad
=20
=20
=20
=20
=20
=20

--=20
Bill Atkins

------=_Part_1042_258512.1123095040668--

 

[Mohammad Khan]

Yes,, I agree with you.
Thanks for describing it.

MOhammad

 

[Bertram Scharpf]

Hi,

Am Dienstag, 02. Aug 2005, 19:09:16 +0900 schrieb Florian Frank:

I use spaces to separate words:

class A
define_method('foo bar') do
'foo bar'
end
end
A.new.__send__ 'foo bar'

A nice idea. Using spaces instead of underscores and then
calling `__send__'.

Another underscore could be avoided by calling

__send__( 'define method'.gsub( / /, "_")) do ...

;-)

Bertram