Hash: SHA512

Hi Omari,

Am Fr den 23. Dez 2016 um 19:09 schrieb Omari Stephens:
> In #2, I had created a one-liner to compute a line-length histogram our
> codebase.  I've rerun it and included the results below as [1].  If also
> attached a list of max-line-length by source file.  As of my git clone from
> earlier this week, Geeqie has 106k lines.  227 of those lines are over 160
> characters.  That's 0.2%

I personally doesn't care about long lines if they make stuff more logic
than a hell of linebreaks with indentations.

Longer lines are also better sometimes for merging purpose.

Moreover, most editors shows long lines in a better way as short ones
with indentations. Especially if you resize the window. I do many perl
coding and what I hate most is that limitation to 80 chars. When I use a
windows that is smaller, the code gets unreadable as the linebreaks from
the editor interfere with the artificial linebreaks.

> But beyond that, ClangFormat exists now.  Because it's part of Clang, and
> actually lexes/parses the C language, it can make actual semantically-driven
> decisions about how a piece of source code should look.  This means that
> _if_ we decide on some style, ClangFormat should make it relatively
> straightforward to update the codebase in one fell swoop.  (And FYI, the C++
> standard at Google, where I work, is to run all code through ClangFormat,
> with exceptions specified as per [2])

I didn't know that tool. But if there is something that works well, why
not adapt it...

I just want to have some thinking about one or the other style. Some
"common" styles are not really helpful.

Other think I do prefer is the K&R style instead of the unbalanced
braces GNU style.

Maybe we can have a style config like perltidy config.

> With that said, I would love for us to get away from a style that encourages
> us to mix tabs and spaces.  See, for instance, [3].  There is no way to
> match an arbitrary paren on the prior line without using spaces for some
> indentation.  But if our style is to use tabs for most indentation, it
> either means that you can't match the exact paren offset from the previous
> line, or you have to mix tabs and spaces.

Yes. That I also swear sometimes about.

Usually I have my vim to use smart tabs what is okish for most cases.
They replace all 8 spaces on the begin of the line with one tab and
handles the rest transparent.

However, it might be better to switch to a expand tab setting. At least
for the line begin.

> My personal preference would be to switch to using spaces for all
> indentation, but I would be okay with using tabs for all indentation as
> well, so long as we avoid situations where the tabs need to be padded with
> spaces.


In any case. If we agree about a specific style, it should be configured
via vim modeline in all files. Currently we have the following:
   set shiftwidth=8 softtabstop=0 cindent cinoptions={1s:

It is nothing more wrong than a mismatch of that options with the
current used style. (Does someone here use different editor than vim
that does not respect such a setting?)

- -- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <kl...@ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
Comment: Charset: ISO-8859-1


Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
Geeqie-devel mailing list

Reply via email to