I was looking at the WPF MVVM framework Caliburn.Micro and read that a lot of standard things are based on naming conventions.

For example, automatic binding of properties in the View to properties in the ViewModel. Although this seems to be convenient (removes some boilerplate code), my first instinct reaction is that it isn't completely obvious to a new programmer that will read this code. In other words, the functionality of the application is not completely explained by its own code, but also by the documentation of the framework.

EDIT:

So this approach is called convention over configuration. Since I could not find any questions concerning this, I altered my question:

My question is:

Is convention over configuration a correct way of simplifying things, or is it violating some programming principles (and if so, which ones)?

I don't consider "an application should be fully explained by its own code" a fundamental programming principle. There are lots and lots of things which are not explained by just looking at the code of an application. Apart from knowing the basic things of the programming language itself (syntax and semantics), you need to know the conventions. If an identifier in Java starts with a capital letter, it is a type. There are lots of these conventions you need to know.

Convention over configuration is about reducing the amount of decisions the programmer has to make about things. For some things this is obvious -- nobody would consider having a language where the capitalization of types is something you need to declare at the top of your program -- but for other things it is not so obvious.

Balancing convention and configuration is a difficult task. Too much convention can make code confusing (take Perl's implicit variables, for example). Too much freedom on the programmer's side can make systems difficult to understand, since the knowledge gained from one system is rarely useful when studying another. 

A good example of where convention aids the programmer is when writing Eclipse plugins. When looking at a plugin I've never seen, I immediately know many things about it. The list of dependencies is in MANIFEST.MF, the extension points are in plugin.xml, the source code is under "src", and so on. If these things were up to the programmer to define, every single Eclipse plugin would be different, and code navigation would be much more difficult.
