[Openvas-devel] Change Request #19: discussion open

Stjepan Gros sgros.ml at gmail.com
Thu Nov 20 13:08:33 CET 2008

On Thu, Nov 20, 2008 at 12:55 PM, Stjepan Gros <sgros.ml at gmail.com> wrote:
> On Thu, Nov 20, 2008 at 12:47 PM, Felix Wolfsteller
> <felix.wolfsteller at intevation.de> wrote:
>> Hi
>> On Thursday 20 November 2008 12:23:33 you wrote:
>>> What I wanted to suggest is that proposed code formatting should be
>>> based on some other popular open source project. That way it will be
>>> easier for newcomers to use it, especially if the given style is
>>> accepted in a large number of projects. For that matter I would
>>> propose using Linux Kernel guidelines. There is CodingStyle document
>>> that can be transfferend to OpenVAS.
>> Do you have a nice reference document for that? A quick search resulted in too
>> many documents, each trying to summarize (their own) coding style.
> It's included in each kernel release, but here is a link on a version
> available on the Internet:
> http://lxr.linux.no/linux+v2.6.27.6/Documentation/CodingStyle
> And, while I'm at that, LXR is a great tool for cross referencing
> source so it might be a good idea to use it on OpenVAS sometime in a
> future.
>>> The second suggestion is that it should be (relatively) easy to do
>>> automatic reformatting using indent tool. The reason is that it's hard
>>> to expect that newcomers, but even experienced users, will follow
>>> closely formatting rules. Using indent the burden of style
>>> checking/correcting could be automated.
>> Tim and me had a tiny conversation about that (
>> http://www.linux.hr/openvas/archive/index.php?d=2008-11-19#msg4375 ).
>> Reformatting all the old code seems to be a bit destructive to me at the
>> moment (should have been done directly at fork times). And for new files I
>> would suggest that its up to the devoloper to use one or not. However, we
>> could encourage the usage of one or another tool.
>> But at the end, that is another discussion - whoever wants to summarize and
>> give an opinion could open another thread. If the majority opts for
>> automation and a specific tool here, I will of course include that in the
>> compendium chapter.
> Yes, it's definitely destructive to change existing code, especially
> in a short time period. It will probably take some time unit majority
> of the existing code is adjusted.
> What I meant is for the new code submissions. Formatting can be
> checked using something as:
> 1. patch source
> 2. do the copy
> 3. apply diff
> 4. see if a diff is too big and/or complex

Oops, I have a bug here... The correct steps are:

1. patch source
2. do the copy
3. use ident on one copy
4. do the diff
5. see if a diff is to big and/or complex

> Now, I know the things don't go so easy in practice, but at least
> there is way to try to do it.
> And BTW, my experience is that when I was reviewing patches, I was
> losing too much time trying to align them to coding guidelines. That's
> why I'm suggesting this approach. But them, some are more strict some
> less, so it's only my opinion.


More information about the Openvas-devel mailing list