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...
