Class variables (@@) and their dangers in Ruby - Step-by-Step Execution

Concept Flow - Class variables (@@) and their dangers

Define class with @@var

↓

Create instance 1

↓

Modify @@var via instance 1

↓

Create instance 2

↓

Access @@var via instance 2

↓

Observe shared @@var value

↓

Potential unexpected shared state

↓

END

Class variables (@@) are shared across all instances and subclasses, so changing them in one place affects all others, which can cause unexpected behavior.

Execution Sample

Ruby

class MyClass
  @@count = 0
  def increment
    @@count += 1
  end
  def count
    @@count
  end
end
obj1 = MyClass.new
obj1.increment
obj2 = MyClass.new
obj2.count

This code shows how @@count is shared between obj1 and obj2, so incrementing in obj1 affects obj2's count.

Execution Table

Step	Action	@@count Value	Instance	Output
1	Define class MyClass with @@count = 0	0	none	none
2	Create obj1 = MyClass.new	0	obj1	none
3	obj1.increment called: @@count += 1	1	obj1	none
4	Create obj2 = MyClass.new	1	obj2	none
5	obj2.count called: returns @@count	1	obj2	1
6	End of execution	1	obj1, obj2	1

💡 @@count is shared, so after increment by obj1, obj2 sees updated value 1

Variable Tracker

Variable	Start	After Step 3	After Step 5	Final
@@count	0	1	1	1

Key Moments - 3 Insights

Why does obj2.count return 1 even though we never called increment on obj2?

Because @@count is a class variable shared by all instances, so when obj1 increments it, obj2 sees the updated value (see execution_table step 3 and 5).

What happens if a subclass also modifies @@count?

The subclass shares the same @@count variable, so changes affect the parent class and all instances, which can cause unexpected side effects.

Why can using @@ variables be dangerous in larger programs?

Because they are shared across the whole class hierarchy, accidental changes in one place can affect unrelated parts, making bugs hard to find.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of @@count after obj1.increment is called?

A 1

B 0

C 2

D undefined

💡 Hint

Check execution_table row 3 where obj1.increment updates @@count

At which step does obj2.count return the updated @@count value?

A Step 2

B Step 5

C Step 3

D Step 4

💡 Hint

Look at execution_table row 5 where obj2.count is called and output is shown

If we create a subclass and increment @@count there, what happens to the value seen by obj1?

A It stays the same as before

B It resets to zero

C It increases because @@count is shared

D It becomes nil

💡 Hint

Remember @@count is shared across subclasses as explained in key_moments

Concept Snapshot

Class variables (@@) belong to the class and are shared by all instances and subclasses.
Changing @@var in one instance affects all others.
This shared state can cause unexpected bugs.
Use with caution or prefer class instance variables or constants instead.

Full Transcript

This visual execution shows how Ruby class variables (@@) work. We define a class with @@count set to 0. When we create obj1 and call increment, @@count increases to 1. Creating obj2 and calling count returns 1 because @@count is shared. This means all instances see the same @@count value. This shared behavior can cause unexpected results if subclasses or other instances modify @@count. Beginners often get confused why changes in one instance affect others. The key is that @@ variables belong to the class itself, not individual objects. This example helps visualize the shared state and why it can be dangerous in larger programs.