[MonoDevelop] Code cleanup options

Michael Hutchinson m.j.hutchinson at gmail.com
Mon Oct 11 17:25:07 EDT 2010


On Thu, Sep 16, 2010 at 4:05 PM, IBBoard <ibboard at gmail.com> wrote:
> On 15/09/10 21:36, Anirudh wrote:
>>> In terms of available options, I think MD is fairly close to the core of
>>> the options that Eclipse has, but a bit more boolean. Some of the
>>> Eclipse options can take numbers (like the amount of new lines to
>>> maintain, which is useful for pruning down gaps). Some of the other
>>> options are also a bit more flexible (I think it is a "always, never,
>>> when necessary" option) but that might be less important.
>>
>> Hey, I don't know if enabling "Format on save" is such a good idea.
>> There have been some very weird edge cases (that I can't reproduce)
>> where my file's syntax has been modified and didn't compile after
>> formatting.
>>
>> Normally if I format it from the keystroke (Alt-E F F) I understand
>> that the file can get altered, and always compile to make sure. But in
>> case I do this, quit the IDE and don't have my file versioned - I'd be
>> annoyed if anything bad were to happen to it.
>>
>> Or maybe you can make a new keystroke for "auto-format and save" that
>> could be used for this usecase.
>
> But that's a separate bug. If the formatter didn't have the bug then
> it'd be safe to format on save. I don't want to have to "format and
> save" each time, I want to save and know that my code is correctly
> formatted. If you want to control when you format then the option can be
> disabled, but I'd rather the computer did what it does best and does the
> mundane tasks so that I don't have to remember them :)

Another way to handle this would be to have a pre-commit policy or
pre-save warning if changed files don't match the formatter output,
i.e. using the formatter to check and ask.

Another neat feature would be to reformat only the changed regions of
the file, avoiding VCS history noise on existing codebases.

-- 
Michael Hutchinson
http://mjhutchinson.com


More information about the Monodevelop-list mailing list