Re: [Geeqie-devel] Geeqie coding standards? Third edition :o)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Folks,
Am Sa den 24. Dez 2016 um 15:43 schrieb Ian Zimmerman:
> I use Emacs.
I do not know any of emacs and how to customize it depending on the
file/projects.
I would even not voluntary start emacs. ;-)
> - I strongly prefer spaces only indentation
That could be agreed with, I think.
> - I too prefer K ish style (opening brace after keyword on the same
> line)
See my follow up mail. I muddled the two.
> - I think it's helpful to code function declarations and calls like this:
>
> int
> foo_func (long arg)
> {
> call_to_bar(arg);
> }
That's what I meat. Most often it is really important to have the
opening and closing braced on the same column.
> I mean in particular the hoisting of the return type on its own line,
That I don't need but have no oportunity against.
> - I am actually pretty religious about keeping to 80 chars per line.
When it comes to religious matter with styles I learned from many
projects that this is mostly wrong and could even kill projects.
As I said, I do not like this 80 column limit. It makes no sense anymore
and I had troubles several times with intermixing with editor line
breaks.
So better let the editor do the (virtual) breaks/wraps.
Am Sa den 24. Dez 2016 um 19:53 schrieb Omari Stephens:
> I agree with everything you just said. But my terminal is 190 columns
> wide, and when I see lines wrapping just because the author didn't
> bother to put a single newline in there, it's a problem.
That could be..
> I think we could easily say "no lines longer than 160 chars" without
> incurring most of the downsides that you're bringing up.
That might be a good compromise. However, I would rather see that as
"soft" limit.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1
iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhf8GUACgkQpnwKsYAZ
9qwIcwv+JB9gMyyqcid06j1NiLrsPzDeKoe0lbaE0awh1iL7PYv8hTM9kl0i98gR
8t7J0da4c9G4t6NUqyI5ryeZ9HkJHOVmCqBP1vLzrm6ZJHafQn+VqETcVU80MCxO
vDQi2I7lG22G3MRaLwyGDHUT1uE8df7v/7E1zNrJvRMaZKV56ImNq8dBzukIHPCL
EPTvjToAPKuuRlLvbsS7ayhnG6jeRJZDknJue/GR6qRmqNDY4q1gXLOmGzXf42Q1
5MQdLGTe0sWWGBU3XAqXesNBRAggvFtcFtJ3XPb5Nj7b46z/3rshb5wqrckT6peL
pwv5xa0YB6ExsUM6KyTyVFo+2nj4gRjHUoP+JeaqciTaxM9cKl1PSCJPcSn86iyP
PdzkK/AnrsSRRCLuPnSxR601sSXmXT5GsUzEsUduxvi5UntgbYugm9Dp6WOrpCTC
Q4z4QQ+psrbx887hmWI3f8gvrsqFGFudjNXN/00Au0cX/Mi9ZQrxULsk5i33ADTG
t00LkxIk
=ctza
-END PGP SIGNATURE-
--
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
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie coding standards? Third edition :o)
On 2016-12-24 15:00, Klaus Ethgen wrote:
> 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?)
I use Emacs. The C style in Emacs is extremely customizable, but still
I can't say for sure there is a 1-1 mapping of the settings with the vim
style settings.
Other points:
- I strongly prefer spaces only indentation
- I too prefer K ish style (opening brace after keyword on the same
line)
- I think it's helpful to code function declarations and calls like this:
int
foo_func (long arg)
{
call_to_bar(arg);
}
I mean in particular the hoisting of the return type on its own line,
the space before the opening paren of the arg list declaration, and
OTOH no space before the opening paren of the call.
- I am actually pretty religious about keeping to 80 chars per line.
IMO if an expression is longer than that it needs to be factored
anyway to be readable. Of course some cultures (cough..Java) make
this hard by adopting reallyInsaneLongDescriptiveNames, and then the
people from such cultures move into your project ... ARRRGH!
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
--
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
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie coding standards? Third edition :o)
-BEGIN PGP SIGNED MESSAGE-
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 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?)
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1
iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhef4IACgkQpnwKsYAZ
9qxUkgwAqO8UxIEqpwlXWCwjo7Rgn7AEpg0qkWbbzBSO5sl/W3sSVin2dByaHDGR
pI075ZWwo5+h/rZM9D68NGNhpEngxcRdxNqBE9Ed4y0vMx2DyOvwJDkAEDYDrDzs
QuWaXa9Jr4fpWyItKMRjV8Fn1SnciJuGmLrhecqaJcKNGKb0TK+miKTtNvFjT6XC
PRtLyCLZox7hsu2V2nm6yyFUuHCodbJR2ANT0scUuXjGLqEmj4PD0sklW9KcyAeJ
jqco08LcH6LLQ+PVAxCOT/yg42rGS94c3tTq3S+eWze4wAwYfI6cD20TIesgUTCj
zlpGCeuILaEVcPpIcrIShekitSRT3nM3niqmL1Ay28mWx0W1KCB080QJZiWeDbU2
zdy4s9r20e7iarYRgK7VX2S3Stssoi7YepmTeqtZtIlWhmHrdnJk/2WaviLynRXp
VXC82TkXcQl2M6jN37ubTMgPQ6zWrwnfUzKeO1GnMI3xIAMsfjRQHm5b7oNN1zt5
YUhSO2fj
=7nDq
-END PGP SIGNATURE-
--
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
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie coding standards? Third edition :o)
Omari> It appears that each time I come back to working on Geeqie, I send one Omari> of these emails ;o) LOL! Omari> Here are threads #1 and #2: Omari> #1: https://sourceforge.net/p/geeqie/mailman/message/22531197/ Omari> #2: https://sourceforge.net/p/geeqie/mailman/message/27441283/ Omari> In #2, I had created a one-liner to compute a line-length Omari> histogram our codebase. I've rerun it and included the results Omari> below as [1]. If also attached a list of max-line-length by Omari> source file. As of my git clone from earlier this week, Geeqie Omari> has 106k lines. 227 of those lines are over 160 characters. Omari> That's 0.2% Omari> I am willing to change those 227 lines by hand if it means we can commit Omari> to a line length limit of 160 characters. Why don't you setup a test branch on github and show what you propose? Heck, I'd be happy to limit lines to 100 columns unless absoltely required. Omari> But beyond that, ClangFormat exists now. Because it's part of Omari> Clang, and actually lexes/parses the C language, it can make Omari> actual semantically-driven decisions about how a piece of Omari> source code should look. This means that _if_ we decide on Omari> some style, ClangFormat should make it relatively Omari> straightforward to update the codebase in one fell swoop. (And Omari> FYI, the C++ standard at Google, where I work, is to run all Omari> code through ClangFormat, with exceptions specified as per [2]) Again, run the codebase through and send out a link to a sample branch so we can look it over. Omari> With that said, I would love for us to get away from a style Omari> that encourages us to mix tabs and spaces. See, for instance, Omari> [3]. There is no way to match an arbitrary paren on the prior Omari> line without using spaces for some indentation. But if our Omari> style is to use tabs for most indentation, it either means that Omari> you can't match the exact paren offset from the previous line, Omari> or you have to mix tabs and spaces. Samples? Omari> My personal preference would be to switch to using spaces for Omari> all indentation, but I would be okay with using tabs for all Omari> indentation as well, so long as we avoid situations where the Omari> tabs need to be padded with spaces. Something consistent that vim/emacs/joe/eclipse/your favorite IDE can all agree on is fine with me. John -- 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 Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] Geeqie coding standards? Third edition :o)
It appears that each time I come back to working on Geeqie, I send one
of these emails ;o)
Here are threads #1 and #2:
#1: https://sourceforge.net/p/geeqie/mailman/message/22531197/
#2: https://sourceforge.net/p/geeqie/mailman/message/27441283/
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 am willing to change those 227 lines by hand if it means we can commit
to a line length limit of 160 characters.
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])
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.
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.
--xsdg
[1] Note that keymap_template.c is a C-wrapped XML file, which is why I
exclude it.
$ruby -e 'lc = Hash.new{|h,k| h[k] = 0}; ARGV.each{|f|
File.new(f).each_line{|l| l.gsub!(/\t/, " "*8); lc[l.length/10] += 1}};
csum = 0; lc.sort.each{|(x,y)| csum += y; printf "%3d-%3d: %s %d\n",
10*x, 10*(x+1)-1, y.to_s.ljust(5), csum}' $(\ls *.c *.h *.cc | grep -v
keymap_template.c)
0- 9: 30198 30198
10- 19: 9074 39272
20- 29: 14334 53606
30- 39: 13148 66754
40- 49: 9292 76046
50- 59: 7223 83269
60- 69: 7534 90803
70- 79: 6587 97390
80- 89: 3974 101364
90- 99: 2194 103558
100-109: 1254 104812
110-119: 681 105493
120-129: 355 105848
130-139: 143 105991
140-149: 64106055
150-159: 39106094
160-169: 28106122
170-179: 22106144
180-189: 32106176
190-199: 38106214
200-209: 64106278
210-219: 36106314
220-229: 7 106321
[2]
http://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code
[3]
http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=blob;f=src/pan-types.h;h=de114bf5111ff7d676ac3fad8c70d630f5f10ccb;hb=HEAD#l274
["keymap_template.c", 404]
["rcfile.c", 226]
["rcfile.h", 214]
["ui_tree_edit.c", 201]
["filefilter.c", 192]
["utilops.c", 188]
["image_load_tiff.c", 187]
["image_load_jpeg.c", 187]
["image_load_gdk.c", 186]
["preferences.c", 175]
["filefilter.h", 175]
["editors.c", 171]
["layout_util.c", 167]
["metadata.h", 166]
["metadata.c", 165]
["utilops.h", 162]
["image-load.h", 161]
["bar_histogram.c", 161]
["renderer-tiles.c", 160]
["bar_keywords.c", 160]
["jpeg_parser.c", 157]
["bar_comment.c", 156]
["filedata.h", 155]
["filedata.c", 154]
["main.c", 153]
["image-load.c", 149]
["view_file_list.c", 148]
["compat.h", 147]
["secure_save.c", 146]
["ui_fileops.c", 145]
["main.h", 143]
["print.c", 142]
["editors.h", 142]
["dupe.c", 142]
["pixbuf-renderer.h", 141]
["debug.c", 140]
["cellrenderericon.h", 139]
["view_file.c", 138]
["pixbuf-renderer.c", 138]
["image.c", 138]
["bar_exif.c", 137]
["image-overlay.c", 136]
["view_file.h", 135]
["remote.c", 135]
["layout.c", 134]
["view_dir.h", 133]
["typedefs.h", 133]
["histogram.h", 131]
["exiv2.cc", 131]
["histogram.c", 130]
["view_file_icon.c", 128]
["compat.c", 128]
["collect-table.c", 128]
["bar.c", 128]
["layout.h", 127]
["ui_tabcomp.h", 126]
["exif.c", 126]
["ui_tabcomp.c", 125]
["collect-io.c", 124]
["bar_histogram.h", 124]
["bar_keywords.h", 123]
["search.c", 122]
["layout_image.c", 122]
["bar_exif.h", 122]
["bar_comment.h", 122]
["ui_menu.h", 121]
["ui_menu.c", 121]
["cellrenderericon.c", 121]
["trash.c", 120]
["bar_gps.c", 120]
["cache.c", 119]
["bar_sort.h", 118]
["bar_gps.h", 118]
["pixbuf_util.c", 117]
["bar_sort.c", 117]
["menu.h", 116]
["layout_image.h", 116]
["thumb_standard.h", 115]
["similar.c", 115]
["menu.c", 115]
["view_dir_tree.c", 114]
["ui_tree_edit.h", 114]
["thumb_standard.c", 114]
["bar.h", 114]
["ui_pathsel.c", 112]
["renderer-clutter.c", 112]
["fullscreen.h", 112]
["fullscreen.c", 112]
["view_dir_list.c", 111]
["ui_misc.c", 111]
["thumb.c", 111]
["img-view.c", 111]
["collect.c", 111]
["slideshow.h", 110]
["slideshow.c", 110]
["format_nikon.h", 110]
