On Mittwoch, 28. Februar 2018 10:57:30 CET Michael Heidelbach wrote: > Hi! > > Now that I saw https://phabricator.kde.org/D10905, I want to do > something similar for baloo and baloo-widgets. > > I'd really like to that once and for all. Because applying coding style > on-the-fly obscures real changes introduced. > > 1. Would it be reasonable? > 2. Who would be willing to review such a huge diff? > 3. How to apply KDE coding style most effectively? > > (The astyle command given in Kdelibs Coding Style > <https://community.kde.org/Policies/Kdelibs_Coding_Style> does not > produce completely correct results: > [this](const QUrl &url) => [this](const QUrl & url) instead > of [this](const QUrl& url) > Also the operators-at-beginning-of-line rule is not respected ) > > 4. What about arcanist: any ready-made .arclint available?
I would personally suggest someone steps up and ensures that clang-format can be used for the KDE coding style. Last time I tried (a couple years ago by now), there where some deficiencies still - mostly with Qt-isms. So going upstream into clang-format and ensuring it can cope well with these constructs would be beneficial to both, KDE and the Qt ecosystem at large. Once clang-format can be used, it can easily be integrated into most IDEs and workflows. At work, we are regularly use it with a coding style checker similar to that applied by the Qt project. I additionally setup my Git pre- commit hooks via [1] and use git-clang-format a lot. [1]: https://github.com/BelledonneCommunications/ortp/blob/master/.git-pre-commit Bye -- Milian Wolff m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
