Re: [sr-dev] rfc: clang format the code
On 24.11.17 09:12, Juha Heinanen wrote: > Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin > Mierla: > >> it was discussed during the last irc devel meeting and everyone there >> agreed to use clang-format to format the source code: >> >> - https://clang.llvm.org/docs/ClangFormat.html > Does anyone have emacs c-mode-hook for this or am I too old school when > I still use emacs? > > Not using clang myself, but found: - https://github.com/sonatard/clang-format Then this blog looks to be recent enough: - https://eklitzke.org/smarter-emacs-clang-format Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] rfc: clang format the code
Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin Mierla: > it was discussed during the last irc devel meeting and everyone there > agreed to use clang-format to format the source code: > > - https://clang.llvm.org/docs/ClangFormat.html Does anyone have emacs c-mode-hook for this or am I too old school when I still use emacs? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] rfc: clang format the code
Hello Henning, indeed, git blame is not going to show directly the original author... as I wanted to see if there is a solution for this, I found: - https://blog.andrewray.me/a-better-git-blame/ and actually a comment there seems to be a decent solution to go back in the history of the commits to find the author, pasting it here: > Just use `git gui blame -- path/to/file.ext` followed by right click and `Do full copy detection`. > Scroll to line you want to investigate and see the commit message. If it looks like it's not the commit > you're interested in, right click the line you're really interested in and select `Blame parent commit`. > Doing it this way allows you to find the whole history of that line even if it came from another file. Also, we lost the direct seeing of the commit log for some files when we relocated code for 5.0 release, therefore now git log needs to be used --follow flag if one wants to track back to the origin. I added aliases in my gitconfig to make it shorted to work with: logf = log --follow logfp = log -p --follow logpf = log -p --follow Cheers, Daniel On 24.11.17 08:39, Henning Westerholt wrote: > Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin > Mierla: >> it was discussed during the last irc devel meeting and everyone there >> agreed to use clang-format to format the source code: >> >> - https://clang.llvm.org/docs/ClangFormat.html >> >> Is any developer (maybe not present during the irc devel meeting) >> opposing this? >> [explanation of motivation] > Hello Daniel, > > I think there is only (small) downside of a thorough re-formatting of the > code > like this: It makes manual bug triage with git blame more difficult, as git > blame shows only the last commit in a line. > > Therefore its important that this changes are applied as one dedicated commit > per module, not mixed with other functional changes (exactly as you proposed). > > The advantages of a consistent style in all modules are much greater than > this > downside, I have nothing against this change. > >> If no one shows anything against in a matter of few days, it will be >> considered accepted (after all, one can re-indent on own style if the >> rule is not accepted or overturned). > Best regards, > > Henning -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] rfc: clang format the code
Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin Mierla: > it was discussed during the last irc devel meeting and everyone there > agreed to use clang-format to format the source code: > > - https://clang.llvm.org/docs/ClangFormat.html > > Is any developer (maybe not present during the irc devel meeting) > opposing this? > [explanation of motivation] Hello Daniel, I think there is only (small) downside of a thorough re-formatting of the code like this: It makes manual bug triage with git blame more difficult, as git blame shows only the last commit in a line. Therefore its important that this changes are applied as one dedicated commit per module, not mixed with other functional changes (exactly as you proposed). The advantages of a consistent style in all modules are much greater than this downside, I have nothing against this change. > If no one shows anything against in a matter of few days, it will be > considered accepted (after all, one can re-indent on own style if the > rule is not accepted or overturned). Best regards, Henning ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] rfc: clang format the code
Hello,
it was discussed during the last irc devel meeting and everyone there
agreed to use clang-format to format the source code:
- https://clang.llvm.org/docs/ClangFormat.html
Is any developer (maybe not present during the irc devel meeting)
opposing this?
It is not going to be all at once, because some of the structures and
initialization of them may be preferred to be kept with a custom format
for being easier to read -- to have a section in the file not formatted,
it has to be enclosed in between comments:
/* clang-format off */
...
/* clang-format o. */
But for the rest of the code (i.e., functions) I think it will be better
to agree on a format and try to use it. The clang-formatting should be
done when one needs to update code in some files.
Over the years, developers come and go, having each one with a custom
formatting style is hard to maintain properly in long term. There are
modules that do not indent coherently code inside blocks, using a
mixture, more or less no style. This makes it hard for other developers
to review in case of reported issues, but also for new comers to get
familiar with the code.
In the source tree there is already a .clang-format file which defines
the options for formatting.
It was used by me and other developers already -- I did it mainly in my
modules or those components that do not have an active maintainer. But I
plan to do it also on the components that have currently a maintainer at
the moment I need to work on that code (e.g., fix some issue or export
functions to kemi framework).
My process of clang-formatting a module is like:
- edit the files to add clang-format off/on comments around the parts
I want to preserve as they are (typically mod exports -- params,
functions, kemi -- and intialization of structures that are aligned to a
specific indentation that makes it easier to read).
- run: clang-format -i src/modules/modname/*.{c,h}
- commit with these changes, no new feature or bug fix must be done in
the same commit (can be combined with removing the history comments)
If one wants different options inside .clang-format, please propose and
let's discuss which one is preferred by the majority of the current
developers.
If no one shows anything against in a matter of few days, it will be
considered accepted (after all, one can re-indent on own style if the
rule is not accepted or overturned).
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
