Michael Schwingen a écrit :
> Zach Welch wrote:
>
>> Sheesh. One religious war per week isn't enough? ;) We made it past
>> the C vs C++ language war only to be caught up in whitespace wars? :)
>>
>>
> Just my thought. We have had this discussions - what, half a year ago?
>
> I do not understand why such taste discussions have to pop up every time
> a new developer joins a project. It is simply not possible to satisfy
> everyone's taste, so IMHO a project should stick to the project's
> styleguides until there is *very good* reason to throw them out.
>
>
>> I have been a tabstop=8 guy for 10 years, and tabstop=4 prior to that.
>> 8 spaces is much easier on the eyes; blocks are more clearly visible.
>> Work on the Linux kernel finally made me switch for good.
>>
>>
> I tend to prefer 2 spaces, but I don't really care since emacs does the
> indenting for me most of the time - I just need to know the preferred
> style for a project directory.
>
>> However, even that project helps make the point that most style rules in
>> a project can be traced back to one or more initial contributors, and
>> inertia keeps the project on that track. In this respect, OpenOCD has
>> been using tabs and should continue to use tabs; tabstop=4 was its
>> original standard and should continue to be. Any gradual change at this
>> point would result in a mixed soup, and total conversion offers dubious
>> value at the cost of completely disrupting everybody's working copies.
>>
>>
I agree entirely with Michael on the subject. I get annoyed everytime
someone
bring up the subject which I think is a non issue.
Here is my take on this. I think the whole discussion is nonsense. So
far I haven't
seen any formatting that actually suits me but I couldn't care less. If
I play with the
source file and I have a hard time with reading it I load it in
slickedit and give it a
beautify command to line up the code to my liking.
A solution would be for most editor to do that. You tell it how you like
the identation.
There are different tastes and there is also no point to go back to the
old teletype
mode (Vi or otherwise) for those of us who hate that mode (80 lines
limitation or such limitation).
Nowadays if you cannot afford a monitor that is 19 inches or larger or
are stuck with
a laptop you should not try to impose your own limitations to everybody.
One quick comment on indentation which annoys me in OpenOCD and other
open source code.
This is a personal taste and should not be seen as a start on some
coding war.
exemple
if (z == 3) {
----
---
}
The correct way should be
if (z == 3)
{
-------
-------
}
It makes the code easier to read. I write my code this way but would not
try this to impose to anyone.
As for imposing some coding rule as some seem to bring up at times. It
may appear as good idea
but it would piss off a lot of developpers as it would remove the
freedom to code the way you want.
The way I see it, you write code in such a way that you can understand
it and that it works and
add comments to explain what you do.
where I work for instance you are not allowed to have something like this
if (z == 3) x = 5;
It must be
if (z == 3)
{
x = 5;
}
Global variables must be this way, the filename is App.c
unsigned long ulApp_eOdometerValue;
unsigned char ucApp_eFuelLevel;
unsigned int iApp_eCoolantTemp;
_e is replaced with _i when it is a static value or only used by the
files closely associated the module (this application level)
There is a lot of value to these rules but for free software where you
want volunteers to work on code
lay off the coding rules which often turn off a lot of people.
If some people want to adhere to some coding rules I have no problem but
they should not be imposed
and code should not be refused because it doesn't follow some rigid
coding rules.
The whitespace issues brought up can be easily taken care of in compare
by ignoring whitespaces.
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
