Agile Otter Blog

The excitement (aside from work and family travel) lately has been at Agile In A Flash , where we released a new blog and card which reveals a process for naming tests . After the naming papers I've written while at Object Mentor, and the chapter I supplied to Bob Martin's Clean Code  and the subsequent video episode , I am known as a "naming guy."  I'm expected to always have a choice name in mind, in line with my own naming rules , for any circumstance in which I might find myself. True to form, anyone pairing with me runs the risk of being exasperated at my constant two-step of "What's that for, really?" and "Can we rename it right now?" My coworkers are often surprised when they see me use a silly or meaningless name early in a test or body of code. Why would I not know exactly what to name a variable, class, method, or test? How is a test fixture not obvious to me from the very beginning? Roy Osherove , in initial shock at the...

A nice discussion about things that should not be done in Python code, but frequently are. Nice mention of Clean Code's naming rules (I'm a proud daddy).

It is a tempest in a teakettle, to be sure, but among the points of friction and discovery today was one about the use of the letter 'u' as a variable name. The case in point was a nice, small function, not much larger or more complex than this stupid example: public void Whatever() { User u = new User(); if (u.hasSomeAttribute()) { u.setSomeValue(); } } The focal point is the letter U as a variable name. Because of my involvement in a particular book project, I was summoned into the conversation and carried half of it for some time. I would rather see "user" than "u" because of my rules about pronounceable, grep-able names that don't require any mental mapping. That is my preference. Therefore, I can clearly NOT choose the variable name "u." I also have publicly stood by James Grenning's assertion that the length of a name should have some correlation with its scope...