I did a fair amount of experimenting with Ruby on Rails and its convention over configuration, which gave me a lot of functionality automatically. But later I found that I wasn't sure I like the paradigm. It seemed to get in the way when dealing with my database and having to make sure everything was named just so, etc.
Is there a huge benefit to convention over configuration or is it to each his/her own?
Convention over configuration should be a good thing:
One disadvantage of it is for guys who are new to the language itself. He might miss some detail from the convention and have weird behavior; or have some problem understanding what a portion of code does (or how the design work).
I sense a bit of a cultural divide here...
Convention over configuration can befuddle C# and Java guys like me, who are used to reading a line of code and knowing exactly and explicitly what it means and does, without wondering (or remembering) what sort of "magic" is taking place under the covers.
Many of the benefits of convention over configuration can be realized by providing constructor or method overloads, and selecting "intelligent defaults" for some parameters in overloads with fewer parameters. This provides a highly visible means to establish some convention.
The best of both worlds is to provide a mechanism for establishing convention "policies" that are clear and visible, and building up from there. Fluent nHibernate does that.
http://wiki.fluentnhibernate.org/show/GettingStarted%3A+Introduction
After working with Java and then Ruby/Rails my feeling is that there is definitely a huge benefit to "convention over configuration." The benefit is in not having to specify information that the framework can deduce for itself. This saves a lot of time and reduces the amount and complexity of the code you write.
In dealing with technologies such as Struts and Hibernate, you have to write a lot of XML. You have to tell Hibernate about every column and key. Having all that information just be implicit is an huge time saver.
"It seemed to get in the way when dealing with my database and having to make sure everything was named just so, etc."
I guess I'd have to disagree with you on that one. The DB naming convention is pretty simple and logical. In fact, rather than being a burden, I'd say the naming convention is, in itself, a benefit. You see a col called id and you instantly know exactly what role it's playing in the schema. Or if you see something_id it's clear at a glance what that column does.
And if you have to use different names, it's possible to do so. You just need to tell Rails you're being unconventional, which you do by adding params in your models.
In Rails, the concept of "DRY" (Don't Repeat Yourself) is closely related to "convention over configuration." I've worked on Struts/Hibernate apps where the same field is declared, mentioned, or otherwise specified in five different places involving four different languages:
And that was considered an exceedingly simple architecture. Oh the hours we spent keeping all that in sync.
For non-key fields, Rails pares that down to two places and two languages:
Building the app on a set of conventions allows you to avoid repeating yourself unnecessarily.
I've struggled with frameworks that use convention to define function. It can be very hard to understand the flow and structure of a framework when there's magic happening all over the place.
Especially when you just want to jump in and get things done. You already know how to program, so it's much easier to understand well-named functions or methods, than framework specific name mangling magic.
IMHO, ideally convention should be optional, so you can use it once you've grokked the framework/system.
I find convention over configuration to be a good thing for the main reason that I can look at someone else's code and figure it out pretty quickly, rather than trying to figure out how everything is set up.
Technologies that rely on convention can be difficult to apply to legacy systems that were not built following those conventions. For something like Ruby on Rails I don't think this is a big deal as you likely are not integrating controllers from legacy systems. For something like an ORM this can be problematic as you likely want to integrate schemas from legacy systems.
This is a consideration that would hopefully be addressed by keeping a good configuration system as an alternative.