[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55266A06.1000906@openwall.com>
Date: Thu, 09 Apr 2015 15:01:10 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Coding Style
On 2015-04-08 12:29, Kai Zhao wrote:
>> 1) it should be possible to convert code to it automatically,
>> a) to convert existing code (e.g. all jumbo);
>> b) to convert new code before committing it to the repo;
>
> I have done some research and experiment on the automatic tools. Here are
> the tools:
>
> 1. Commercial
Unless there are grave reasons, please don't waste your time on non-free
tools.
> 2. Free
>
> - GNU Indent
> - Artistic Style
> - UniversalIndentGUI
> - Uncrustify
> - GreatCode
>
> However, I think we'd better not use these tools. There are two reasons.
> Firstly, linux kernel which our coding style very similar to does not use
> it.
> Secondly, the tools is arbitrary. E.g., if we set the max column 80, but
> there are some cases which we may exceed column 80.
>
> I think kernel does very well on the coding style. They use the script
> checkpatch.pl to check the coding style, and add it to the git pre-commit
> hooks, so each patch will be checked before commit.
>
> The script generates errors and warnings. It depends on the committers to
> judge whether change their code.
There are some differences between john and the kernel. We want
contributing to john to be much easier. This means that we have to do
some technical work ourselves. The quality of contributed code is lower,
hence there are less cases when coding style is violated consciously.
And we have a lot of existing code which we have to fix.
Conclusion: having a tool to check coding style is good but we need a
robust tool to reformat code too.
--
Alexander Cherepanov
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
