Hi List, I would like to try to revive this idea, there have been some recent commits and a discussion on irc today that have convinced me that using a tool like this would have some value. [1][2][3][4]
The irc discussion involved issues like, should we assume a tab-width of 8 when editing the C++? When formatting code as a table should we use tabs to line up the columns at a fixed tabstop or always use spaces for this? My point of view is that I don't feel strongly about formatting conventions, I just want to do things in the way that is the least amount of work for me. If there is a tool to fix up the formatting so that everyone is happy and I can myself avoid arguments, that is perfect. Here are my thoughts on what has already been said in the thread: 1. It seems that we already have a tool called "wmlindent" which is run regularly on all core wml. So I think we already agree that there is some value in having a uniform formatting convention enforced by a tool. Can someone explain why this is a good thing for WML but a bad thing for C++? (if anyone takes this viewpoint?) Is there anyone who thinks that wmlindent is bad and we shouldn't use it? 2. It looks like clang-format now has a fancy web 2.0 documentation page [5] which supplements the textual descriptions of the options with examples. For instance the options "AllowShortIfStatementsOnASingleLine" and "BreakBeforeBinaryOperators" have nice code examples for the possible settings that illustrate the pros and cons. I find this page very easy to read. For instance now I can say that the question about when to use tabs can be phrased as `UseTab: Always` vs `UseTab: ForIndentation`. 3. I agree with `Enforcing a line length of 80 characters seems strange and evil`, it seems that our current coding standard allows long lines. My point of view is that the benefits of a tool like this should be clear; it avoids future arguments by establishing a standard and a way to enforce it, it makes it easy for people to get it right by providing a tool, it makes it easy to change the formatting convention if in the future the majority decides they want a different convention. Are there actually philosophical objections to a tool like this? In the year since this topic was raised I would guess that clang-format has become more mature. Maybe we can take another look at it? Best Regards, Chris Beck [1] https://github.com/wesnoth/wesnoth/commit/8c7d6fecb7ed79820085143742d954d849051f7f [2] http://www.wesnoth.org/irclogs/2015/01/%23wesnoth-dev.2015-01-04.log [3] https://github.com/wesnoth/wesnoth/commit/6ac21df1a8a09f16768c595f57aef91455e4af35 [4] https://github.com/wesnoth/wesnoth/commit/7aea1c732a66e237eecfc5fd37665b760d8f0daf [5] http://clangformat.com/ On Sun, Feb 9, 2014 at 6:30 PM, Ignacio R. Morelle <shadowm2...@gmail.com> wrote: > On Sunday 09 February 2014 17:11:18 Mark de Wever wrote: > > If there are no objections I also like to format the rest of the source > > tree with clang-format. After the initial run some manual formatting > > needs to be done. Especially for comment, that is wrapped so it's more > > than just running the tool. Once done I can run it on a regular basis to > > keep the code uniformly formatted. > > To add to what Jamit said, I'd prefer to see actual formatting rules in > plain > language we can enforce on current and future C++ patches and commits to > save > everyone some time and effort. > > I took a quick look at the new formatting applied on my GUI2 dialogs' > source > code and I can't say agree with all of them: > > * Enforcing a line length of 80 characters seems strange and evil in an > age > where screens of horizontal resolution >= 1280 pixels and text editors > that > can automatically wrap longer lines (some of them with nice indications > to > tell the difference between automatic and manual line-wrapping) are the > norm. Personally, I'm not too bothered by this, though, since I tend to > limit my line length in many cases to avoid situations where to read a > block I must keep moving my eyes horizontally to cover a wide range. Of > course. > > * No namespace indentation would make it harder to tell anonymous > functions > apart from public functions in code units that aren't dedicated to > implementing just a single class and its methods. Again, this is just a > matter of personal preference, and this was actually existing practice > already in many existing units outside of GUI2. > > * Some of the style changes seem non-obvious (hence documentation is > needed). > For example, from src/gui/dialogs/game_paths.cpp:98 (in > gui2::tgame_paths::pre_show()): > > > connect_signal_mouse_left_click( > > copy_w, > > > boost::bind(&tgame_paths::copy_to_clipboard_callback, > > this, > > path_path)); > > In this case, the second and third lines are continuations of the first > line, and as such are indented with two indentation units (tabs) rather > than one. Okay, but then the continuation of the third line is indented > with three units over the previous level rather than two. If the last > line contained a statement that needs to continue over more lines, would > it be indented with four units over the previous levels for a total of > nine units over the first line's indentation level (thus 11 units)? > > Changing code formatting behind people's backs is a recipe for frustration > in > all directions, so ideally this wouldn't be done each time without prior > notice. The thing is, even if developers are made aware of the upcoming > changes in the mailing list (assuming they are even available to see the > post!), fixing conflicts in private branches, external pull requests, or > patches, isn't the most fun thing to do. > > I personally think that unless we'll all be required to use this > clang-format > tool ourselves, fixing other people's code formatting with a tool and > _then_ > fixing anything the tool got wrong (which requires reading and > understanding > the affected code!) is valuable time and energy that could be better spent > in > other more worthwhile activities, such as writing code or playing games > (such > as Wesnoth!). > > Also, so far we haven't particularly frowned upon developers having > completely > different coding styles as long as the difference isn't too great (such as > using hungarian notation). As you know, I *love* consistency and could > support > any change that standarizes any aspect that is relevant to the development > or > usage of Wesnoth, but I still must ask: What is the full rationale for this > sudden departure from a direction that some people may have preferred? > > -- > Regards > Ignacio R. Morelle <shadowm> > > _______________________________________________ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev >
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
