Writing in a Dynamic Language? Naming Matters More.

Here's an interesting observation I've found related naming in dynamic languages. As I've been working more with Ruby and Python over the past few years, I've been using and debugging more and more open source code. In the process, I've noticed how naming affects trying to work with and debug code in these languages. In general I've found it more difficult to jump in and figure out code written in ruby than python.

Part of this seems to be the grep-ability of identifiers. In the ruby community there seems to be more of a push towards constructing DSLs, which seems to cause developers to write more generic single word methods and variable names. Searching through a decent sized codebase tends to result in a lot of noise/reuse. In the python world, it seems that methods at least tend to be a little more verbose and more easily identifiable. Explicit imports in python do help quite a bit also.

Has anyone else noticed a similar pattern, or am I being biased here?

Yeah, definitely. Since jumping from full time Java to full time Python a few years ago I've learned this lesson the hard way a number of times.. It's definitely worth naming for grep-ability to ease refactorings. I'm sure this post will garner at least a few STATIC TYPING > SCRIPTING LANGUAGE comments, but I think that's short sighted. There are definitely advantages and disadvantages to both. Refactoring and code-findability is where static languages shine. We're lucky that it's a relatively simple problem to solve in dynamic languages via thoughtful naming and unit tests.

I don't think the authors's GetByPersonId() goes far enough. I suggest PersonFromPersonID() which puts the return type and the parameter in the function name.

Even better approach would be to minimize having business logic in dynamic/weakly typed languages at all. Scripts like JS are most suited for rich GUIs.