Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Writing in a Dynamic Language? Naming Matters More. (bitnative.com)
20 points by housecor on Oct 21, 2013 | hide | past | favorite | 7 comments


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.


Great point. I didn't mention findability but that's a struggle in dynamic languages since you must resort to searching for strings. Thus in dynamic languages similar/duplicate function names hinder refactoring and navigation.


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.


This is a flamebait, of course. No need to think how to respond any longer, just move along.


I don't believe there is any reason to go to those extremes. Proper Object-orientation and well structured context can go a long way.

I'm not dropping a language just because of how functions are defined.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: