Published: October 14, 2022 • 2 min read
It’s hard to enforce unconventional preferences on a team. Default to convention.
Consider this contrived example. Imagine that you don’t like Ruby accessors, which work like this:
class Dog attr_accessor :bark end > Dog.instance_methods.take(2) => [:bark, :bark=] # Dog has a gettor and a settor for @bark
Preferring the verbose alternatives:
class Dog def bark @bark end def bark=(sound) @bark = sound end end > Dog.instance_methods.take(2) => [:bark, :bark=] # Same gettor and settor
You advocate for this more verbose style on your team and expect to see it in code reviews.
The challenge with this preference is that this style of accessors is a Ruby convention. It’s been part of the standard library for a long time. Everyone understands it. It’s boring.
By bucking convention, you’re inviting inconsistency into your code.
Programmers may follow the pattern on existing files, but they’ll forget to on
new files. Unless you’re watching every PR or have installed tooling to
enforce your preference,
attr_accessor will drift into your code.
Get better at programming by learning with me. Subscribe to my newsletter for weekly ideas, creations, and curated resources from across the world of programming. Join me today!