Re: [Openocd-development] Coding style
On Tue, Aug 30, 2011 at 6:53 AM, Øyvind Harboe wrote: If Kernel programming guidelines requires variable names like that, then I don't want to see it for OpenOCD. Do not fear :) This is what the Linux Documentation/CodingStyle says: Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs. LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called i. Calling it loop_counter is non-productive, if there is no chance of it being mis-understood. Similarly, tmp can be just about any type of variable that is used to hold a temporary value. If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. Tormod ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
Do not fear :) This is what the Linux Documentation/CodingStyle says: Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs. I like. :-) I'd toss in a word about IDE's there as well. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style plan
On Tue, Aug 30, 2011 at 5:26 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Goal: switch OpenOCD to use the Kernel coding style Plan: a) get all outstanding patches merged b) do wholesale automated(hopefully) code style fix d) patch w/documentation and scripts to enforce the new coding style. Resources: Does anyone want to do this? I think first is to set a date for the conversion so everyone can prepare for this conversion. Item a is everyone's job. If he/she does not want to reformat all his/her patches after conversion, he/she should push out the patches to be merged before the conversion date. I can do Item b and c if we set the conversion date to the end of this year. I think I should have some spare time at that time. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style plan
On Wed, Aug 31, 2011 at 12:21 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 11:26 Tue 30 Aug , Øyvind Harboe wrote: Goal: switch OpenOCD to use the Kernel coding style Plan: a) get all outstanding patches merged b) do wholesale automated(hopefully) code style fix d) patch w/documentation and scripts to enforce the new coding style. Resources: Does anyone want to do this? I'll do the generall switch at the end of the merge window I'll use Lindent from the kernel for the rest if I've time I'll send the patch to add the checkpatch and co Great! -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Mon, Aug 29, 2011 at 1:07 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: Hi, personnally I'd like we use the same coding style as the kernel in the kernel anre barebox we use checkpatch to check the patch coding style I don't mind picking the kernel style, if nothing else because we then can get scripts to check for the style. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Mon, Aug 29, 2011 at 7:35 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, Aug 29, 2011 at 1:07 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: Hi, personnally I'd like we use the same coding style as the kernel in the kernel anre barebox we use checkpatch to check the patch coding style I don't mind picking the kernel style, if nothing else because we then can get scripts to check for the style. The kernel script scripts/checkpatch.pl can be used both for a patch and for the whole file (with flag -f). This is for sure good. Don't know if can be used on TCL files too. Whatever coding stile or script we use, sooner or later we need to apply it to whole files. Using it only to check patches will mess-up the files by mixing new coding stile in the new parts and legacy style in the rest of file. Changing stile (indentation, spaces here and there, tabs, ...) can be very invasive. In this case adding flag --word-diff to git format-patch will create patches that are shorter and much more easy to review. Best Regards, Antonio Borneo ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Mon, Aug 29, 2011 at 7:35 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I don't mind picking the kernel style, if nothing else because we then can get scripts to check for the style. It seems people like Linux kernel coding style. It's widely used and well documented. So I think it will be good. How about make a plan to do the coding style switch? We cannot do now immediately since it will break all patches in people's local trees. We need to set a roughly date so people can prepare for it. The end of this year or the beginning of the next year will be a good point time for me. I think I will have already pushed out all my patches at that time. And at that time, people will be in Christmas and New year holidays. There might be less development activities. So the impact will be likely less than other times of a year. What's your thought? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
Hi, personnally I'd like we use the same coding style as the kernel in the kernel anre barebox we use checkpatch to check the patch coding style Best Regards, J. On 19:40 Sat 27 Aug , Øyvind Harboe wrote: As a maintainer I'm interested in this subject from the point of view of how it can be used to *save* time of the maintainers. E.g. if we had a script committed that checked that a patch sequence was acceptable, then that report could be amended to the patch sequence. Thus maintainers would not have to check the patches and give feedback, this would happen before the patches were posted. This should include documentation and guidance on how to do an interactive rebase to fix the formatting issues. W.r.t. fixing formatting, my main concern is about patches, not existing code, though a cleanup timed so that it would not cause to much constipation would be good. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Mon, Aug 29, 2011 at 9:11 AM, Jie Zhang jzhang...@gmail.com wrote: On Mon, Aug 29, 2011 at 7:35 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I don't mind picking the kernel style, if nothing else because we then can get scripts to check for the style. It seems people like Linux kernel coding style. It's widely used and well documented. So I think it will be good. How about make a plan to do the coding style switch? We cannot do now immediately since it will break all patches in people's local trees. We need to set a roughly date so people can prepare for it. The end of this year or the beginning of the next year will be a good point time for me. I think I will have already pushed out all my patches at that time. And at that time, people will be in Christmas and New year holidays. There might be less development activities. So the impact will be likely less than other times of a year. What's your thought? I am interested in this conversation, and I'm surprised it wasn't squashed right away as inciting a holy war. So far, everybody's been very civil, though I suspect that's because there hasn't been a great deal of dissent. I have no strong feelings as to which style should be used, but a quick blanket application of indent's default styles of -gnu, -kr, and -linux shows this: indent-gnu: 340 files changed, 117612 insertions(+), 108216 deletions(-) indent-kr: 341 files changed, 103813 insertions(+), 105417 deletions(-) indent-linux: 341 files changed, 42192 insertions(+), 43373 deletions(-) From that cursory glance, we are most like the Linux style. For the record, here are the relevant standards: GNU: http://www.gnu.org/prep/standards/standards.html#Writing-C Kernighan Ritchie: http://en.wikipedia.org/wiki/Indent_style#K.26R_style (sorry, didn't try very hard on this one) Linux: http://www.kernel.org/doc/Documentation/CodingStyle Each run issued some warnings: Warning:old style assignment ambiguity in =. Assuming = Warning:old style assignment ambiguity in =*. Assuming = * (Which I assume are because if you accidentally switch those operators, it means something different) And a cluster of errors/warnings about the comment style in src/xsvf/xsvf.c, using #if 0 to keep uncrustify from adding asterisks at the beginning of every line. I did not use the -T option to add OpenOCD's custom types to Indent's syntax recognition, so custom-type casts aren't considered such and where we declare pointers to custom types, Indent maybe thinks we're multiplying, so the * isn't snuggled to the variable name. +static int jim_version_command(Jim_Interp * interp, int argc, + Jim_Obj * const *argv) Also, Linus doesn't like typedefs (Chapter 5 of the Linux style), and Indent handles struct structname *x correctly with being told about custom names. Best regards, ~Eric ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
Le 29/08/2011 12:28, Eric Wetzel a écrit :
For the record, here are the relevant standards:
GNU: http://www.gnu.org/prep/standards/standards.html#Writing-C
Kernighan Ritchie:
http://en.wikipedia.org/wiki/Indent_style#K.26R_style (sorry, didn't
try very hard on this one)
Linux: http://www.kernel.org/doc/Documentation/CodingStyle
I strongly disagree on using anything that resembles KR.
Where I work you could get reprimanded and maybe even fired if you did use it.
for example something like this is not only unacceptable, you will get a
reprimand.
if (x == y)
x++;
else
x--;
this is also unacceptable
if (x == y) {
x++;
}
else {
x--;
}
This must be used even if there is only one line of code. Unless you're
compiling with a TRS-80 you shouldn't be concerned about the added time for
compiling.
if (x == y)
{
x++;
}
else
{
x--;
}
The reason is for clarity. It is true that the code is easier to follow this
way.
When I take code from open source and want to go thru to understand it, I often
have to load the file in slickedit and do a beautify to make the code more readable
as it is often stuck in that old KR coding style which I cannot stand.
Since we have bigger monitor than in the 70s and 80s why make the code
unreadable?
The only valid reason for using KR would be
1- You still expect to be stuck with a teletype at times and want to make sure
you can see many lines of code at once
2- You can't get yourself to replace your VIC-20 or TRS-80.
3- You are still stuck with a tiny 13 inches or smaller screen.
Michel
--
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
I strongly disagree on using anything that resembles KR.
Where I work you could get reprimanded and maybe even fired if you did
use it.
So are you saying that
if (x == y) {
x++;
} else {
x--;
}
is a serious offence where you work? If it is, I'd love to know the
logic behind the argument.
Where I work, we support several styles, so long as only one style is
used in any particular file. I have my favourite, others have theirs. We
respect our differences. It doesn't negatively affect productivity.
On Mon, 2011-08-29 at 19:45 -0400, Michel Catudal wrote:
Le 29/08/2011 12:28, Eric Wetzel a écrit :
For the record, here are the relevant standards:
GNU: http://www.gnu.org/prep/standards/standards.html#Writing-C
Kernighan Ritchie:
http://en.wikipedia.org/wiki/Indent_style#K.26R_style (sorry, didn't
try very hard on this one)
Linux: http://www.kernel.org/doc/Documentation/CodingStyle
I strongly disagree on using anything that resembles KR.
Where I work you could get reprimanded and maybe even fired if you did use it.
for example something like this is not only unacceptable, you will get a
reprimand.
if (x == y)
x++;
else
x--;
this is also unacceptable
if (x == y) {
x++;
}
else {
x--;
}
This must be used even if there is only one line of code. Unless you're
compiling with a TRS-80 you shouldn't be concerned about the added time for
compiling.
if (x == y)
{
x++;
}
else
{
x--;
}
The reason is for clarity. It is true that the code is easier to follow this
way.
When I take code from open source and want to go thru to understand it, I
often have to load the file in slickedit and do a beautify to make the code
more readable as it is often stuck in that old KR coding style which I
cannot stand.
Since we have bigger monitor than in the 70s and 80s why make the code
unreadable?
The only valid reason for using KR would be
1- You still expect to be stuck with a teletype at times and want to make
sure you can see many lines of code at once
2- You can't get yourself to replace your VIC-20 or TRS-80.
3- You are still stuck with a tiny 13 inches or smaller screen.
Michel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
2011/8/29 Michel Catudal michelcatu...@gmail.com: Since we have bigger monitor than in the 70s and 80s why make the code unreadable? The only valid reason for using KR would be 1- You still expect to be stuck with a teletype at times and want to make sure you can see many lines of code at once 2- You can't get yourself to replace your VIC-20 or TRS-80. 3- You are still stuck with a tiny 13 inches or smaller screen. I like multiple commands per line and its not true that it always decrease code readability, sometimes it can allow to write one coherent piece of code in one line (less than 80 characters). This makes code more coherent and easy to edit with my favorite VIM :-) What I dont like about Python for instance is the one-command-per-line and the division code block with tabs - this is why I have started to indent code with one space, no matter what language (some editors can replace tab with multiple spaces and whole program structure is gone, who invented this sh$(# anyway). Just my sixteen in this interesting topic :-) Best regards :-) Tomek Btw. my 8-bit Atari has now 37' LCD HD 100Hz display and its not a teletype haha ;-P :-) :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
Le 29/08/2011 20:03, mike a écrit :
I strongly disagree on using anything that resembles KR.
Where I work you could get reprimanded and maybe even fired if you did
use it.
So are you saying that
if (x == y) {
x++;
} else {
x--;
}
is a serious offence where you work? If it is, I'd love to know the
logic behind the argument.
We have very strict coding rules, that is just part of it.
This part is for clarity. Code written like this is very hard to follow and we
are not allowed to code like that.
You don't get fired for 1st offence, just if you insist on not following coding
rules, after a while the boss and other programmers will get pissed off.
The other part is the naming
exemple with a file named App.c a variable for odometer would look like this
unsigned long ulApp_eOdometer_E2p;
or
U32 ulApp_eOdometer_E2p;
Since it is to be saved in EEPROM it ends with _E2p
Some constant in Flash would end with _Fls
I agree with the first part, my opinion on naming of variables isn't much
different of that of Linus on the subject.
Linus has some amusing comments on this naming of variables
Michel
--
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux or eComStation.
http://home.comcast.net/~mcatudal
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
unsigned long ulApp_eOdometer_E2p; or U32 ulApp_eOdometer_E2p; Now there are identifiers from hell. - Since the invention of IDE's that can present type information, we don't need to encode type info into the name. - After the invention of namespaces, the world stopped embedding scoping into the identifier name. In C scoping is reduced by having short functions, using static, for instance. In a pinch using prefixes, like foo_yyy for global variables can get you by. Encoding even more information into variable names just makes it worse. Linus has some amusing comments on this naming of variables I'm suuure he does :-) He's a smart guy and most of the time he's right. If Kernel programming guidelines requires variable names like that, then I don't want to see it for OpenOCD. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On 27.08.2011 19:40, Øyvind Harboe wrote: As a maintainer I'm interested in this subject from the point of view of how it can be used to *save* time of the maintainers. E.g. if we had a script committed that checked that a patch sequence was acceptable, then that report could be amended to the patch sequence. Linux has checkpatch.pl (which is also used by uboot), which performs such checks. However, that would probably require us to switch to Linux coding style - maintaining a modified version of checkpatch is probably not worth the effort for a small project like OpenOCD. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Sun, Aug 28, 2011 at 9:29 AM, Michael Schwingen rincew...@discworld.dascon.de wrote: On 27.08.2011 19:40, Øyvind Harboe wrote: As a maintainer I'm interested in this subject from the point of view of how it can be used to *save* time of the maintainers. E.g. if we had a script committed that checked that a patch sequence was acceptable, then that report could be amended to the patch sequence. Linux has checkpatch.pl (which is also used by uboot), which performs such checks. However, that would probably require us to switch to Linux coding style - maintaining a modified version of checkpatch is probably not worth the effort for a small project like OpenOCD. Also, I'd be happy to let someone else define what the correct coding style is. I don't particularly care as long as the check can be automated and the style is consistent. Are there scripts to fix coding style too? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On 28.08.2011 10:04, Øyvind Harboe wrote: Also, I'd be happy to let someone else define what the correct coding style is. I don't particularly care as long as the check can be automated and the style is consistent. Are there scripts to fix coding style too? at least indent and the C-Mode in emacs can do automatic re-formatting according to a configurable style. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
Hello, eclipse are also able to format to a desired coding style. I think we should define an indent rule and use it as base. Personally i use the Allman-Style. Openocd mix more then two styles, i have seen Allman, KR and GNU. Regards, Mathias Am 28.08.2011 13:50, schrieb Michael Schwingen: On 28.08.2011 10:04, Øyvind Harboe wrote: Also, I'd be happy to let someone else define what the correct coding style is. I don't particularly care as long as the check can be automated and the style is consistent. Are there scripts to fix coding style too? at least indent and the C-Mode in emacs can do automatic re-formatting according to a configurable style. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
2011/8/26 Michel Catudal michelcatu...@gmail.com:
Le 25/08/2011 15:18, Jie Zhang a écrit :
Hi,
There are a lot of coding style mismatch in the current OpenOCD code.
I'd like suggest setting a rule that asks fixing all coding style
issues before a patch is merged.
And there are still something missing on
http://openocd.berlios.de/doc/doxygen/html/stylec.html , like
* how to deal with long list of arguments, which cannot fix in one line?
* how to place { }? I saw
if (...) {
} else {
}
if (...)
{
}
else
{
}
* should there be a white space after ( and before )? I saw code both.
If you change to much the diff files can get big.
I don't propose to fix all coding style issue right now. I propose to
do coding style check when reviewing patch from now. At some
appropriate point in future, we can fix coding style issues at once.
I do agree with you that your suggestion is more appropriate but you will
find people who prefer the other approach.
Personnally I just use the beautify in slickedit to fix that.
I'm not used to the current coding style of OpenOCD. I'm more used to
GNU coding style. But I can use the established coding style in
OpenOCD without a problem. A consistent coding style is important for
the readability and maintenance of software.
Regards,
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
As a maintainer I'm interested in this subject from the point of view of how it can be used to *save* time of the maintainers. E.g. if we had a script committed that checked that a patch sequence was acceptable, then that report could be amended to the patch sequence. Thus maintainers would not have to check the patches and give feedback, this would happen before the patches were posted. This should include documentation and guidance on how to do an interactive rebase to fix the formatting issues. W.r.t. fixing formatting, my main concern is about patches, not existing code, though a cleanup timed so that it would not cause to much constipation would be good. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
There is a tool that has been around for a long time that can address this issue. It's called indent. It has numerous options that can generate just about any type of coding style. Jim ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Sat, Aug 27, 2011 at 1:40 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: As a maintainer I'm interested in this subject from the point of view of how it can be used to *save* time of the maintainers. E.g. if we had a script committed that checked that a patch sequence was acceptable, then that report could be amended to the patch sequence. Thus maintainers would not have to check the patches and give feedback, this would happen before the patches were posted. My experience is such a script is better than nothing, but it cannot check everything in coding style and developer ofter forget to check the patch with it. I can volunteer to review patch for coding style. But before that we need to set the rule about those issues I raised, since current documentation does not say anything about them. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Sat, Aug 27, 2011 at 5:49 PM, j. m. norris u17...@att.net wrote: There is a tool that has been around for a long time that can address this issue. It's called indent. It has numerous options that can generate just about any type of coding style. I don't know if indent can check in-line coding style. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
Le 25/08/2011 15:18, Jie Zhang a écrit :
Hi,
There are a lot of coding style mismatch in the current OpenOCD code.
I'd like suggest setting a rule that asks fixing all coding style
issues before a patch is merged.
And there are still something missing on
http://openocd.berlios.de/doc/doxygen/html/stylec.html , like
* how to deal with long list of arguments, which cannot fix in one line?
* how to place { }? I saw
if (...) {
} else {
}
if (...)
{
}
else
{
}
* should there be a white space after ( and before )? I saw code both.
If you change to much the diff files can get big.
I do agree with you that your suggestion is more appropriate but you will find
people who prefer the other approach.
Personnally I just use the beautify in slickedit to fix that.
Michel
--
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
