Naming the World

Posted by Flatiron School  /  November 14, 2013

The following is a guest post by Rosie Hoyem and originally appeared on her blog. Rosie is currently in the Ruby-003 class at The Flatiron School. You can follow her on Twitter here.

We’re coming up on National write a Novel Month. In November you can join thousands of aspiring writers from around the country for National Novel Writing Month (NaNoWriMo). This event involves writing 1,800 words a day, which after 30 days, will equal the length as a respectable novel. My attempt to log 50,000 words last year was thwarted by a nasty flu in week two that set me hopelessly behind on my word count and work (that’s my excuse and I’m sticking to it), but NaNoWriMo and I will meet again!

NaNoWri was founded to make a point about writing; the difference between a good writer and a great writer that you may have heard of is largely the number of words a person logs everyday. Sucessful writers write a lot.

The next measure of a great writer vs. a good writer is the quality of the details—are they true and believeable? Do they contribute to building the story? Language is a dynamic thing, and the art of picking the right word for the right ocassion and expressing ideas clearly is both a skill that comes with experience and an art. I’ve been thinking a lot about writing as I learn how to program.

I’ve been reading a lot because I spend nearly two hours a day on the train. My current train reading is Jeff Atwood’s Effective Programming: More Than Writing Code (Get your copy here!). He is the master mind behind the Coding Horror Blog and also co-founded Stack Overflow. In the chapter entitled ‘How to Write Without Writing’ he emphasizes how important it is for programmers to have good writing and communication skills. I found it quite amusing that he claims part of the reason he founded Stack Overflow was to “trick” programers into writing. Writing about code forces programmers to communicate more clearly about what they are doing and why.

Writing, clear communication skills, picking works appropriatelly are all important skills for programmers. I want to hit a few relevant topics for programmers that demonstrate this point.

Naming Things Well

“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.” Martin Fowler

Part of clear communcation in code is naming things well. The names programmers give to variables and methods in their programs matter. Naming things is often sited as one of the most difficult aspects of programing to do well. Jeff’s Attwood’s post I Shall Call It.. SomethingManagerlays out several very important reasons why naming things well really matters in programming.

For one, carfully paying attention to naming things clearly and concisely simply makes your program better. It helps to provide better understanding in the future should your code reused after a long interval of time. It not only makes it easier to read through code and understanding what is going on, it is perhaps low hanging fruit for newbies to attain the professional appearance of work product. It may seem funny in the moment to use cute or comical names. Don’t do it. Overly long names or single letter variables also make code more difficult to understand. Don’t do it.

Naming things well can also act as a form of metadata for your program. If you feel like you need comments, reconsider how you’ve used names for your variables and methods in your code. Comments shouldn’t need to explain what a piece of code is doing, they should be used sparingly only to describe why you’ve constructed your code the way you have. Use clear and consistent names to promote consistency within a project and on a development team. Everyone’s productivity will benefit.

Naming Conventions that Make Rack Frameworks Work

Beyond the somewhat subjective benefits of making our code more clear and concise, the most popular Ruby Frameworks, including Sinatra and Rails, are constructed around a variety of naming conventions. Not abiding by these conventions will make your programs not work. When working with ruby frameworks

Just last week my group found this out the hard way. When naming a Sequel table we used candyfor our class Candy rather than candiesThis didn’t seem like a major difference… ? Low and behold, Sequal would not recognize our table because it was looking for the exact plural of our class.

These strict naming conventions will only become more important as we move into Active Record and Rails. Attention to these seemingly small details will be the difference between a things working and not.


The idea of namespaces is a broader topic in programming that also amplifies the importance of choosing names well and communicating clearly to the surrounding context. A namespace is a defined area or domain for a set of identifiers or names. Namespaces allows the disambiguation of homonym identifiers residing in different namespaces. Namespaces usually group names based on their functionality, so it is possible to do an endless number of things with limited sets of words.

In Summary.

Programming has more in common with creative writing than most would guess. The careful use of words to describe the world around us and inside our programs will make both work better.