From: elfring@users.sourceforge.net (SF Markus Elfring)
To: cocci@systeme.lip6.fr
Subject: [Cocci] Clarification for source code style reformatting
Date: Wed, 02 Apr 2014 09:19:46 +0200 [thread overview]
Message-ID: <533BBA12.1040105@users.sourceforge.net> (raw)
In-Reply-To: <1396374174.21529.93.camel@joe-AO722>
> The output is apparently correct and compilable.
> It is just not kernel style. I'm not sure there
> is a defect really, just wanted to bring it up.
>
> Maybe the first transform could be better written.
It seems that the shown differences in source code formatting come from your
first semantic patch rule.
Does your update suggestion fit to implementations of functions which had a
non-void return type before?
> $ cat void_return.cocci
> @@
> identifier func;
> expression S;
> @@
> void func(...) {
> ...
> if (...)
> - return S;
> + { S; return; }
> ...
> }
I have got another view for further consideration around similar SmPL approaches.
You expect that the adjusted source code should fit to the Linux coding guidelines.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/CodingStyle?id=b57a0505e750b3d7b2d39e9823b276d8ca1a08fe
I guess that would mean here that the opening curly brace should be placed at
the end of the "if line".
But: Does your SmPL approach express a desire to leave this source code line
unchanged?
Does the behaviour from the tool "spatch 1.0.0-rc14" come closer to your
expectations for this use case?
Does your example show an interesting target conflict?
Various software developers have got strong opinions about the recommended
source code formatting.
http://en.wikipedia.org/wiki/Programming_style
Is there a need to make the "pretty-printing strategy" configurable for the
Coccinelle software?
http://en.wikipedia.org/wiki/Prettyprint#Programming_code_formatting_and_beautification
Regards,
Markus
next prev parent reply other threads:[~2014-04-02 7:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-01 17:42 [Cocci] coccinelle: trivial linux code style reformatting Joe Perches
2014-04-01 18:29 ` Peter Senna Tschudin
2014-04-01 23:11 ` Joe Perches
2014-04-02 5:53 ` Julia Lawall
2014-04-02 5:57 ` Joe Perches
2014-04-02 8:30 ` [Cocci] "trivial" " SF Markus Elfring
2014-04-02 8:35 ` Julia Lawall
2014-04-02 9:00 ` [Cocci] " SF Markus Elfring
2014-04-02 10:55 ` [Cocci] Restore source code from matched expressions? SF Markus Elfring
2014-04-01 20:02 ` [Cocci] "trivial" linux code style reformatting SF Markus Elfring
2014-04-01 23:26 ` Joe Perches
2014-04-02 7:19 ` SF Markus Elfring [this message]
2014-04-02 7:43 ` [Cocci] Clarification for source " Julia Lawall
2014-04-02 7:53 ` SF Markus Elfring
2014-04-02 8:33 ` Julia Lawall
2014-04-02 7:56 ` Joe Perches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533BBA12.1040105@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=cocci@systeme.lip6.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox