tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] code indenting?


From: Thomas Beierlein
Subject: Re: [Tlf-devel] code indenting?
Date: Thu, 25 Jan 2018 06:32:02 +0100

Hi Zoli and others,

Am Wed, 24 Jan 2018 21:33:43 +0100
schrieb Csahok Zoltan <address@hidden>:

> Hi,
> 
> Another topic: as the code has grown over the time and many authors
> contributed to it the formatting is inherently not consistent.
> 
The most inconsistencies are not from contributions in last years but
left over from former code in sections we did not change (e.g. audio.c).

I put quite some work to bring it at least to a mimimum level of
quality and to keep it there (for comparison you may have a look at
the old 0.9.34).

But anyway I find it a good idea to automate it as much as possible. I
used mostly universalindentgui for that, but with the switch to QT5 it
no longer compiles. So 'indent', 'astyle', 'bcpp' or similar may be
best.

> GNU indent is a powerful tool for C source formatting and present in
> any modern Linux distro. We could define a common style simply by
> setting up an .indent.pro file.
> see http://www.gnu.org/software/indent/manual/indent.html#SEC4
> 
For a similar way you can look up the hamlib mailing list. They use
astyle now.

> I have no particular formatting preferences provided that tab size is
> 4. Any suggestions?

I would recommend to choose the settings so, that it reflects the
actual code base best and needs no big reformatting session over the
whole project. I will look for my setting for the universalindentgui
and post it here.

By 'tab size' do you mean the size of a tab character or the
indentation size normally inserted by tab.

For tab characters I am strongly against a size of 4 as it is not the
default setting in ALL editors and/or viewers. Tab was and is always 8.
Then it would be better to deny tabs at all and replace it by spaces.

4 as indentation size is what we used mostly in the code. That is a
good compromise between line size and nesting depth.


There are two other points I would suggest:

- We should not only look for common formatting rules but additionally
  define some naming schemes for variables, typedefs and functions.
  We already have quite a mix in the code, but should use a common
  scheme for new code and migrate the old one step by step.

- I further had a look into the Travis CI which integrates neatly with
  the github working flow. Maybe we should use it to do common checks
  on the code automatically.

What do you think?

73, Tom DL1JBE




-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--




reply via email to

[Prev in Thread] Current Thread [Next in Thread]