Question about length of ActionDispatch::Routing::Mapper class file

Hello Rails team,

I posted this question in the Ruby on Rails Talk mailing list a week ago. However, I wasn’t able to get a lot of replies there. I’m hoping I’d have better luck here :slight_smile:

Our team lead and I recently discussed the pros and cons of breaking up a long source file into multiple source files. I tend to prefer one class per file, because I find the individual files easier to read and easier to find (with ctrl-p in Sublime). On the other hand, our team lead doesn’t have issues with long source files. He argues that they are quite common in open-source projects. As an example, he pointed to the ActionDispatch::Routing::Mapper class in Rails as a case of a long file with multiple inline classes.

I’m curious to learn the intent behind keeping all the contents of Mapper class within a single file. What were the advantages of taking this approach?


George Mendoza


Hi, I also have a great curiosity about it. Beautiful question.

I’ll share my point of view.

In general, in programming I don’t think there are many rules that apply in every single scenario. Programming is not an axiomatic system.

In this case, one class/module == one file may be a good guideline sometimes (app/models), maybe not so much in other cases. It depends, and in addition it depends on personal preferences, so maybe you would organize the code in a different way and that would be fine.

In a large codebase like Rails, sometimes you organize the code in higher-level units. Why? Because splitting every single class/module into their own file, while may give you uniformity with regards to that a priori rule, comes at the cost of loosing context when understanding that unit of code.

When you open that file as a reader, the message is: here’s a cluster of classes or modules together concerned with this high level functionality. If you sit down and go through this file you’ll understand a piece of something. Otherwise you’d need to open 7 tabs, switch context, and nothing would convey they are closely related as the single file approach (except your inference, perhaps).

Hi Xavier,

I agree that it boils down to personal preference. For me, switching contexts “horizontally” (via tabs) is easier than switching contexts “vertically” (by using bookmarks to jump up/down a single file). To convey that the subfiles are closely related together, I would put them in a single directory named after the parent class.

Thanks for providing us some insight about the Rails code. Much appreciated.


By the way, I would like to expand a bit on the Ctrl-P argument.

In my mind, code has to be written according to principles that concern the code itself. How does client code look like, usage, readability, performance, good organization, maintenance, etc.

I never design code to bend to anything outside the code itself. Like tests, docs, or editors. Code is first, it is the duty of tests and docs to adapt to code, not the other way around.

So, either I am fine with the limitarions of Ctrl-P navigation and run the occasional grep, or else I add ctags to the project, or use RubyMine that is able to go to definitions robustly out-of-the-box. I would not organize my code to satisfy the shortcomings of tool.

(Again, sharing points of view, not meaning others should think like me.)

Thanks for sharing your thoughts on the Ctrl-P argument. I agree that code should be first, and that we should not bend code just to adapt to its supporting environment. I guess the bigger issues for long/short files are readability and maintainability. But that’s for another discussion :slight_smile: