Writing in a Dynamic Language? Naming Matters More.(bitnative.com)

20 pointsby housecor13 anni fa7 comments

Writing in a Dynamic Language? Naming Matters More.

http://www.bitnative.com/2013/10/18/dynamic-language-naming-matters-more/

4 comments

wbond13 anni fa

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?

famousactress13 anni fa

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.

housecor13 anni fa

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.

greenlakejake13 anni fa

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.

CmonDev13 anni fa

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.

klibertp13 anni fa

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

adlpz13 anni fa

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.