dfmt options

[Idan Arye via Digitalmars-d]

On Monday, 16 March 2015 at 02:16:18 UTC, Brad Anderson wrote:
> On Saturday, 14 March 2015 at 23:15:35 UTC, Brian Schott wrote:
>> First, a disclaimer: I am an idiot for starting this thread.
>>
>> Moving on...
>>
>> I'm working on a list of configuration options for dfmt - a 
>> formatter for D source code.
>>
>> So far I have the following:
>>
>> * Insert spaces between if, while, for, foreach, etc loops and 
>> the "("
>> * Allman vs One True Brace Style (Already supported by 
>> commant-line switch)
>> * Operators at the end of the old line vs beginning of the new 
>> line when wrapping long expressions.
>> * Insert space after the ")" of a cast expression
>> * Make "case" and "default" match the indent level of the 
>> enclosing "switch"
>> * Labels for loops always on their own line vs the same line 
>> as the loop
>> * Labels outdented one level
>> * Label indentation matches the most recent "switch"
>> * Hard limit for line length
>> * Soft limit for line length
>>
>> What am I missing?
>
> clang-format has a pretty extensive set: 
> http://clang.llvm.org/docs/ClangFormatStyleOptions.html
>
> I don't think all of that is necessary however. When I started 
> using clang-format I just looked at the predefined styles 
> (LLVM, Google, Chromium, Mozilla, Webkit) and picked the one I 
> liked the most and didn't stress the details. I guess what I'm 
> saying is I'd like a bunch of predefined styles. I don't want 
> to wade through 50 options to make my own style.
>
> dfmt would, of course, need to support expressing all the 
> predefined styles and all of those differences should have 
> options.

That's why dfmt should be able to read the configuration from a 
file(clang-format has that option). That way, all these 
predefined styles can simply be style files you can download - no 
need to make separate paths for predefined styles and custom 
styles.

That being said - I'm against having predefined styles bundled 
with dfmt(either as separate style files or embedded into the 
executable). The only build-in style should be the one true 
style. While there are enough D projects out there to require 
dfmt to be configurable, we don't have multiple commonly accepted 
styles like C or C++, and I see no point in encouraging such a 
thing...