[Monodevelop-devel] Per-project styles & policies

[Michael Hutchinson]

Hi everyone,

Here are my current thoughts concerning per-project styles and
policies, so that we can discuss it before I go ahead and implement
it. I also have an number of questions that are interspersed
throughout this email.

Rationale
=======
There are a number of settings and preferences in MD that should be
customisable for different solutions/projects. Basically, anything
that affects the style of the code you write should be able to be set
for a particular project, since different projects have different
styles and policies. I've lumped "Styles and Policies" together into
one heading since I believe they are related.

Text Editor Settings
==============
These are the ones that most people care about -- per-mimetype
settings for the general text editor behaviour such as tabs-to-spaces,
editor width, tab width, standard headers. Some languages may add to
this, e.g. C# indenter behaviour, and in future things like
auto-formatting. There should also be a "default" style, and the
per-mimetype settings should override this.

* Should we allow users to add custom mimetypes for their own file
formats, or just support the "major" text/code mimetypes registered in
MD?
* Should we list only the mimetypes used in the project?
* For each mimetype, should there be a checkbox to override the
"default" text style? Or should there be a UI for adding/removing text
styles to the tree?

Policies
======
There are a number of other per-project settings that aren't quite
styles, but also aren't really build options or project properties.
I'm calling these "policies" for now. The only existing one is
changelog policies; in future, we could add settings such as "pass
tests before checkin", "check style before checkin", "must include
changelog entry", etc.

Settings Infrastructure
================
Many of these settings may need to be overridable for individual
projects within a solution, because a solution's projects may have
been imported from elsewhere with different coding style. For this
reason, we need an infrastructure that can be used to get the setting
for a project, and if the setting has not been overridden, will grab
the setting from the parent solution.

* How important is this feature?
* How many of the settings really need to be overridable at project level?
* Should settings be overridable at "solution folder" level too, hence
allowing a cascade of settings?
* Should settings or group of settings be individually overridable? Or
should it just allow a project to override *all* settings? Does this
really need any granularity?
* Where should settings be stored? The solution file and the project
files? I feel this is better than a .userprefs-like file, since it
makes sure the settings stay with the project/solution.
* Should setting be duplicated in the project in case it's opened
without the solution? Or should the project have a flag to say that it
expects settings to be stored in a solution, so MD can warn when the
solution isn't present?
* What settings do we default to when opening projects that don't
contain settings Do we automatically add default settings to the
solution files? Or fall back to a set of user preferences?

GUI Infrastructure
=============
It's difficult to present all of these options in the GUI in a
scalable way, particularly the per-mimetype editor settings
* Should the settings be in the main "Project options" dialog or a
separate "Styles and policies" dialog? The separate dialog has the
advantage that the same dialog can be used to edit the user's named
styles and default style. It would also help to not overload the
setting treeview in the existing project options dialog.
* Should each panel have "use parent solution's style", "load/save
named style" etc options? Or should these apply to all styles?
* VS has a setting panel that can be used to add "file types" and set
the editing experience that's used for them. maybe we could do
something similar with per-mimetype styles -- the top-level panel for
editor setting would contain this list, and adding a file type would
cause it and its options to appear in the tree. Files not handled this
way would fall back to the "Other files" style (VS has an "All files"
option which aggregates the common settings from all files, with
tri-state checkboxes etc, but I feel this is overcomplex).

Named Styles
==========
It should be possible to save a project's style, and apply this style
to other solutions/projects. However, I don't think it's viable or
desirable to synchronise these in any way. Once a project is created,
its settings should remain constant unless they are explicitly
changed.

I also have a number of mockups on my whiteboard which aren't so easy
to express in email :-)

-- 
Michael Hutchinson
http://mjhutchinson.com