[megaduck]

As a dynamic language guy, I can't help but look at the static analysis here and feel a twinge of jealousy. There really isn't anything like this in the Ruby world.

Some stuff is starting to emerge, but we're still largely dependent on tests to catch stupid mistakes. When I'm chasing down a bug, it would be nice to have a variety of tools to throw at the problem.

[jbjohns]

You don't have to have static typing to do type analysis. Look at what these guys are/were doing: http://www.strongtalk.org/

[sruffell]

I spend most of my time writing C code, but like to work with Python when I get the chance. There isn't anything like pylint for Ruby? A dynamic runtime doesn't necessarily mean you have to give up static analysis.

[riffraff]

roody, rufus, reek, flay, flog, probably more. Sadly, in the current state of the ruby community it's even hard to find a library that will run with ruby's own warnings enabled.

[eru]

Isn't clean code valued in the Ruby community?

As a contrast, I had the impression that the Python guys care more about this in their code. They also avoid eval and other runtime code generation. (Though I do not if that's related.) It seems these two languages are further apart than in their culture than anything else.

[riffraff]

clean code, yes, but some of the warnings are actually generated in situations where the code won't be cleaner (e.g. lazy initializing an instance variable not declared in the initialization method) and since quite a lot of the most common libraries have _a lot_ of warnings, it becomes unlikely that you will have them enabled in your app, and so the thing self propagates

[eru]

OK. So people should suppress the warning in those cases, so as not to desensitize?

[riffraff]

well, I do, but I understand why people don't. The likely better solution would be to have structured warnings you can enable/disable by, selector such as warning class, declaring namespace, using namespace or whatever, but that seems quite unlikely :)