Comments... Umm.... That's is a holy war with no right or wrong answers.....
Personally, I think the biggest thing is to not just go make wholesale changes - it makes it harder to be clear on what the meaningful changes are. Basically, for any files that have been released, try to keep any changes to match the style of the rest of that file. That way if someone comes along later and tries to see what has changed since the version they had earlier fetched, it is as easy as possible for them.
If something is totally new, or being massively changed, then it's more open.
Are major changes expected?
dgc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree your comments, there's no right or wrong way.
I think the best way is analyze code and preserve existing style.
(but we need make a big change at least one time)
so I analyze as a whole sources roughly
and found appropriate GNU indent option is "-kr -ts4"( K&R style, tab size is 4).
Are you agree this?
If you have any opinion, let us know.
I'll update sources after a week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would only change what needed changing. Just to change to a specific set of indents would probably confuse a lot of people for very little gain. If you are doing this to make the code work with a tool, then we should discuss this prior to making changes.
There is a possibility that we will have to make some changes to the toolkit to match the 1.2 DS changes. I need to look through the new specs some more to see what is required. I'll try to do that this week.
Cheers,
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We seems to need arrange coding style with GNU indent.
Is there any coding standard to be referenced until now?
And do you have any comments?
Comments... Umm.... That's is a holy war with no right or wrong answers.....
Personally, I think the biggest thing is to not just go make wholesale changes - it makes it harder to be clear on what the meaningful changes are. Basically, for any files that have been released, try to keep any changes to match the style of the rest of that file. That way if someone comes along later and tries to see what has changed since the version they had earlier fetched, it is as easy as possible for them.
If something is totally new, or being massively changed, then it's more open.
Are major changes expected?
dgc
I agree your comments, there's no right or wrong way.
I think the best way is analyze code and preserve existing style.
(but we need make a big change at least one time)
so I analyze as a whole sources roughly
and found appropriate GNU indent option is "-kr -ts4"( K&R style, tab size is 4).
Are you agree this?
If you have any opinion, let us know.
I'll update sources after a week.
Hi Kidong,
I would only change what needed changing. Just to change to a specific set of indents would probably confuse a lot of people for very little gain. If you are doing this to make the code work with a tool, then we should discuss this prior to making changes.
There is a possibility that we will have to make some changes to the toolkit to match the 1.2 DS changes. I need to look through the new specs some more to see what is required. I'll try to do that this week.
Cheers,
Peter