Instance variables @ vs self

uberdwang — Fri, 27 Sep 2019 05:32:08 +0000

In a class sometimes I see attributes with @ or a self. At a quick glance they seem to do the same thing.

class MyClass
  def initialize(arg)
    @my_attribute = arg
  end

  def my_attribute
    @my_attribute
  end

  def output_attribute
    puts @my_attribute
    puts self.my_attribute
  end
end

my_instance = MyClass.new("testing123")
my_instance.output_attribute

Output:

testing123
testing123

From what I learned @ returns the instance variable, and self calls the getter method to return @. So I can see the difference if I modify the variable in the accessor method. For example for my FakeId class, self.age adds 10 years to the @age and returns that value.

class FakeId
  def initialize(arg)
    @age = arg
  end

  def age
    @age + 10
  end

  def output_age
    puts "Real age: #{@age}"
    puts "Fake ID age: #{self.age}"
  end
end

fake_id = FakeId.new(15)
fake_id.output_age

Output:

Real age: 15
Fake ID age: 25

Let's Read Eloquent Ruby Chapter 1

uberdwang — Thu, 26 Sep 2019 19:15:59 +0000

I just picked up Ruby for fun so I'm a noob. Here are some notes and self lessons while reading.

Spaces vs Indent

The Ruby convention is to never use tabs to indent. Ever.

I use Atom editor. By default it enables soft tabs and use two spaces per indention level.

Comments

Good Ruby code should speak for itself, and most of the time you should let it do its own talking.

This reminds me of my Comp Sci classes where I commented everything. At work I usually only comment methods, rationale of business rules, and todo. It looks like yard documents your code from comments. I will look into this.

Names

With a few notable exceptions, you should use lowercase_words_separated_by_underscores. Almost everything in this context means methods, arguments, and variables, including instance variables

Everything is snake case except for Classes. Classes are camelcase: DocumentType. Constants are screaming snake case: HOURLY_WAGE.

Parentheses

def find_document( title, author )

In the books example there are spaces before and after the parameters. Based on this style guide by Rubocop no spaces after (,[ or before ],). Use spaces around { and before }.

def find_document(title, author)

fruits = ["apple", "banana", "pineapple", "pen"]

fruits.each { |fruit| puts fruit }

Parentheses are optional, which bothers me as a Java programmer. Parentheses help make it clearer for me on my methods and conditionals. But the styling rule is:

if method has no parameter, no parentheses
if method have parameters, add parentheses
conditionals, no parentheses

def hello
  put "hello"
end

def initialize(name, age, gender)
  @name = name
  @age = age
  @gender =gender
end

if age < 21
  put "hello youngin'"
end

One-liners

Semicolons allow multiple lines of code to be on one line. This should be avoided unless it's something like a simple class or method.

class DocumentException < Exception; end

def method_to_be_overriden; end

Code blocks

If it's a single statement in a block, put it into a single line surrounded by braces. Otherwise use the multiline form.

10.times { |n| puts "The number is: #{n}" }

#vs

10.times do |n|
  puts "The number is: #{n}"
  puts "Twice the number is #{n*2}"
end

Readability vs Style

Sometimes following the style guide makes things unreadable. So for example, if a single statement is inside a do/end use brackets. It's unreadable since the word is bunched together on one line. Or if the statement is so long it should be broken into the multiline form.

doc.words.each do |word|
  puts word
end

#vs

doc.words.each { |word| puts word }

#vs

doc.words.each { |word| some_really_really_long_expression( ... with lots of args ...) }

Another example is to add parentheses if there's arguments to a method. Omiting the parentheses make is readable.

puts(doc.author)
doc.instance_of?(Document)

#vs

puts doc.author
doc.instance_of? Document

Sometimes there's an exception to the exception 😜

puts doc.instance_of? self.class.superclass.class

#vs

puts doc.instance_of?( self.class.superclass.class )

The best part of having rules is that they inevitably create rule breakers—and it’s even better when the rule breakers are the authorities.

DEV Community: uberdwang