It’s always better to be explicit! That’s pretty much a programming truism. Rarely directly challenged, lest one betray the foundational tenors of Proper Programming. But challenge it we should, and head on.
The standard justification for being maximally explicit is a kind one. Give a programmer looking at the code everything they need to understand how it works, right there, as if they knew nothing already. It’s an optimization for fresh eyes, those who see without knowing a surrounding context.
So to challenge explicitness as a core value, we need to start by questioning that optimizing for those fresh eyes. Should their needs really to be the main objective for a programming environment?
It could be. If you expect to have rapid churn of the people working on the code, it’s a fair trade to burden those who’ve acclimated with laborious ceremony, if it means those fresh eyes will have an easier time.
That’s a value judgment based on circumstance and experience. To value the experience of the newcomer at the expense of the productivity of the veteran and the succinctness of the code. In some environments, that’ll be the reasonable choice.
But that’s not the environment I’m interested in. At all. I love implicit code, or, as we call it in Ruby on Rails, Convention over Configuration. Consider this tiny snippet of code:
class Person < ApplicationRecord
belongs_to :company
has_many :assignments
end
This beautiful excerpt is bursting with implicitness. Just on the database side, it implies that there’s a “people” table backing the “Person” record. It implies that there’s a single “id” primary key for that table. It infers that there’ll be a “company_id” foreign key linking rows in “people” to rows in “companies”.
Here’s an explicit version that expands those contextual assumptions:
class Person < ApplicationRecord
table_name “people”
primary_key “id”
belongs_to :company, foreign_key: “company_id”, class_name: “Company”
has_many :assignments, foreign_key: “person_id”, class_name: “Assignment”
end
And that’s just the tip of the iceberg. It doesn’t even talk about the implicit validation of a belongs_to relationship or the introspection of columns to create attribute methods.
I’d hate to have to write explicit code like that all day, every day. I’m willing to trade the need for someone to learn the conventional context of Active Record in favor of being able to write succinct, clear, and, yes, implicit code. Slightly higher upfront costs, perhaps, but amortized over a lifetime of working with Rails.
This gets to the heart of examining the values of programming environments. A value stated in isolation does not illuminate. Saying “I like explicit code” without also accepting that this means “I like [writing a lot more, often repetitive, frequently boiler-plated] explicit code” is a disingenuous. Values only shine the light for choices when they’re voiced in opposition to different values that others might reasonably prefer.
It’s the same story with product values. If you say your product is “simple” or “easy”, you’re rarely saying much. Few are the competitors who’d take the opposite side of that plank, selling products that are “complicated” and “hard” (though it does happen occasionally!).
To carve out a meaningful, effective belief system, you must be willing to give up something. To embrace explicit code, you must be willing to accept laborious ceremony and the boilerplate. To embrace implicit code, you must teach the context and unpack its at-first bewildering magic.
I embrace implicit code. I embrace the context. I swoon over magic. If you too fancy such sparkle, Ruby on Rails will probably resonate. If not, no worries, most other programming environments pledge allegiance to the defeat of magic and oppose the implicit. Pick your poison.
