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&R 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 12/24/2016 02:43 PM, Ian Zimmerman wrote:
> On 2016-12-24 15:00, Klaus Ethgen wrote:
::snip::
>> 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.
Emacs here also. I don't know a ton about configuring it, but I know
enough to make it do 3-space indentation :o)
> Other points:
>
> - I strongly prefer spaces only indentation
Agreed.
::snip::
> - 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!
I would generally agree with you, but large C projects fall into the
same bucket as Java, specifically because C doesn't have any real
concept of namespaces. Consequently, I think 80 chars is a bad idea for
Geeqie.
So when your line starts off like this:
"combo = tab_completion_new_with_history("
You're gonna have a bad time. Especially if it's inside of a loop or
conditional or something like that. Constants are even worse, the
constant "PAN_IMAGE_SIZE_THUMB_LARGE" is already 33% of an 80-character
budget. That's the kind of thing that causes statements to start
consuming extra lines without actually improving readability at all.
(As an aside, C++ namespaces and enum classes would help dramatically in
conserving readability while reducing statement length. But when C is
what you've got, the namespace info has to go in the method and constant
names, and you've got to set line lengths to accommodate.)
--xsdg
--
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 12/24/2016 02:00 PM, Klaus Ethgen wrote: > -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. 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. I think we could easily say "no lines longer than 160 chars" without incurring most of the downsides that you're bringing up. [snip] --xsdg -- 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&R 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 Am Sa den 24. Dez 2016 um 15:00 schrieb Klaus Ethgen: > Other think I do prefer is the K&R style instead of the unbalanced > braces GNU style. Well, way around. :-D I could live with "BreakBeforeBraces: Allman" or "BreakBeforeBraces: GNU". (GNU is the current style.) So, a minimal .clang-format would be: BreakBeforeBraces: GNU ColumnLimit: 0 IndentWidth: 3 # vim: ft=yaml Indent should be 3 or 4. 8 is far to much while the default 2 is a bit to less for my taste. 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/UMJJLQEpnwKsYAZ9qwFAlhehI8ACgkQpnwKsYAZ 9qxdSQv+K+kd7Exlk6AQCxYy6Ty4lELZbkvuf3qMDYY7LAU7X24Den+y0oz6K3Jh LT5wojJL/TOHZGyHYjKZbuDw8Ms/d//PLdR4PbI1KydlNTstZj6l8+JtTFgVuhdO x7Q7h0tg+amsqPd+CRoF9pcikH9L+GuBMHufOlyMolwlH8mP84OzXbxoYnwMvufV LtkDXb9jabsevmKIEYUlOas4QeAu9/YEt9WhXC9ASL3f/25feDDqCkFKUNTLoCUi YDrnZTBc7qkUsxvQSoW7yIpcaF6niwDEMgec4cUpqwUbOjnLO20siYRz98yBM8V2 5ApzjGlf+WonjHVHCoXcEYXOKmWL9lS5r4jdQRId0Jv/sIgwP4ncao6ZrwxuBAvx 1oNjJdiH0qwocdq19VP7cxULR6FXqNcF+EtDh4WSGP96TAyWVmON4UQEk9b11tTk P1jlO7cUSBmf9ovml3h6S8O9aRwjzU/Jz75+h942mt27DRDdgSsp+RzZ4tzetHCF reLlLQMR =jF9q -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)
-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&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?)
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
Re: [Geeqie-devel] Geeqie coding standards
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Am Di den 26. Mai 2009 um 13:30 schrieb Greg Troxel:
> I hesitate to post on this, but I will anyway:
:-)
> There are existing coding standards out there, and I think it makes
> sense to adopt one or the other rather than creating a new one. The
> basic choices seem to be GNU and the BSD KNF, which is perhaps most
> refined in NetBSD. I would expect gnome to have standards, and adopting
> those would be a reasonable choice. Unfortunately the GNU one is
> underspecified.
I like the GNU style. I dislike any style which has a strange
brace-Style:
bla
{
...;
}
is ok.
bla {
...;
}
is bad as it makes code horrible to read. The style in the geeqie coding
style is acceptable. :-)
I do not like if somethink is overspecified. But that is not the reason
for liking the GNU style.
> 100 characters is a surprising limit. Real terminal had 80 columns, and
> BSD KNF says 80.
Comeon. Which terminal is just 80 chars wide? The most are 130 or more
and it normally doesn't matter at all.
> Tabs are a rathole, but tabs simply *are* every 8, and people who try
> to change code formatting by telling their editor/display program to
> put tab stops elsewhere are confused and need to stop. The
> traditionalist in me is offended by giving up on tabs because of
> confusion and lame editors, preferring instead to ban the use of
> editors which don't work right (which is what I do at work), but the
> realist sees your point.
I'd like to be the traditionalist and I like to bann bad editors. ;-)
But there is another point I want to show. All coding styles are nice
but changing the coding style of existing source is bad as it breaks all
revision controll tracking. So as much as I whould see a consistent
coding style I dislike to change major parts of existing code.
Regards
Klaus
- --
Klaus Ethgenhttp://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQEVAwUBShv+dZ+OKpjRpO3lAQqt4AgAorXxabmO7bQJiHdw8kjQJxpfl/7Yrj4i
MwPSZuUKyltdujo/SHmk49Z2FLsEMbOjO2Lj+Qzoeee2Kkj79hX/j/N3IYGMNnj1
SkkcqQruvBBLhXh6lZSEln8VviSBcaHHFyrDfhDAn/Fwa6wo/M2cpT01QRHftX/d
im3BdwMXRtNa2Uw7qH/rMF51w1YD5XC7nHtvveZiIU+acdA4cfx9Jlrhh1W8I9Qw
zRwg4kZXiqKqbYf+oJniIXr8sC7SmvdG3aOgHwwjj+tNzBog+CmfyUNMzEEpxN2f
ivB2gTUHuBC/99DNXsyeolQl+HCf3D7WiVqrik2JdrVETkXubaHm4g==
=TBKI
-END PGP SIGNATURE-
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie coding standards
I hesitate to post on this, but I will anyway:
There are existing coding standards out there, and I think it makes
sense to adopt one or the other rather than creating a new one. The
basic choices seem to be GNU and the BSD KNF, which is perhaps most
refined in NetBSD. I would expect gnome to have standards, and adopting
those would be a reasonable choice. Unfortunately the GNU one is
underspecified.
Beyond that:
100 characters is a surprising limit. Real terminal had 80 columns, and
BSD KNF says 80.
Tabs are a rathole, but tabs simply *are* every 8, and people who try
to change code formatting by telling their editor/display program to
put tab stops elsewhere are confused and need to stop. The
traditionalist in me is offended by giving up on tabs because of
confusion and lame editors, preferring instead to ban the use of
editors which don't work right (which is what I do at work), but the
realist sees your point.
I think C99 allows //, but I don't like them in C code.
The most important thing would be review of most checkins, and asking
people to fix whitespace issues could help create a sense that review
is normal.
Definitely have a rule that checkins either solely change formatting
and the commit message says that, or that they make no formatting
changes to lines other than the ones changed.
Here's NetBSD's style rules, for what they're worth. Indent is 8
columns, and tabs are used whenever possible. This is emacs's default
behavior with M-x c-set-style bsd. Probably geeqie should go with
emacs's "gnu" style being a gnome-aligned program.
/* $NetBSD: style,v 1.44 2008/09/09 19:18:41 jschauma Exp $ */
/*
* The revision control tag appears first, with a blank line after it.
* Copyright text appears after the revision control tag.
*/
/*
* The NetBSD source code style guide.
* (Previously known as KNF - Kernel Normal Form).
*
* from: @(#)style 1.12 (Berkeley) 3/18/94
*/
/*
* An indent(1) profile approximating the style outlined in
* this document lives in /usr/share/misc/indent.pro. It is a
* useful tool to assist in converting code to KNF, but indent(1)
* output generated using this profile must not be considered to
* be an authoritative reference.
*/
/*
* Source code revision control identifiers appear after any copyright
* text. Use the appropriate macros from . Usually only one
* source file per program contains a __COPYRIGHT() section.
* Historic Berkeley code may also have an __SCCSID() section.
* Only one instance of each of these macros can occur in each file.
* Don't use newlines in the identifiers.
*/
#include
__COPYRIGHT("@(#) Copyright (c) 2008\
The NetBSD Foundation, inc. All rights reserved.");
__RCSID("$NetBSD: style,v 1.44 2008/09/09 19:18:41 jschauma Exp $");
/*
* VERY important single-line comments look like this.
*/
/* Most single-line comments look like this. */
/*
* Multi-line comments look like this. Make them real sentences. Fill
* them so they look like real paragraphs.
*/
/*
* Attempt to wrap lines longer than 80 characters appropriately.
* Refer to the examples below for more information.
*/
/*
* EXAMPLE HEADER FILE:
*
* A header file should protect itself against multiple inclusion.
* E.g, would contain something like:
*/
#ifndef _SYS_SOCKET_H_
#define _SYS_SOCKET_H_
/*
* Contents of #include file go between the #ifndef and the #endif at the end.
*/
#endif /* !_SYS_SOCKET_H_ */
/*
* END OF EXAMPLE HEADER FILE.
*/
/*
* If a header file requires structures, defines, typedefs, etc. from
* another header file it should include that header file and not depend
* on the including file for that header including both. If there are
* exceptions to this for specific headers it should be clearly documented
* in the headers and, if appropriate, the documentation. Nothing in this
* rule should suggest relaxation of the multiple inclusion rule and the
* application programmer should be free to include both regardless.
*/
/*
* Kernel include files come first.
*/
#include /* Non-local includes in brackets. */
/*
* If it's a network program, put the network include files next.
* Group the includes files by subdirectory.
*/
#include
#include
#include
#include
#include
/*
* Then there's a blank line, followed by the /usr include files.
* The /usr include files should be sorted!
*/
#include
#include
#include
#include
#include
/*
* Global pathnames are defined in /usr/include/paths.h. Pathnames local
* to the program go in pathnames.h in the local directory.
*/
#include
/* Then, there's a blank line, and the user include files. */
#include "pathnames.h" /* Local includes in double quotes. */
/*
* ANSI function declarations for private functions (i.e. functions not used
* elsewhere) and the main() function go at the top of the source module.
* Don't associate a name with the types. I.e. use:
* void function(int);
* Use your d
Re: [Geeqie-devel] Geeqie coding standards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Mo den 25. Mai 2009 um 19:13 schrieb Omari Stephens: > > At least for the editor Vim there should be a modeline in every source > > file which forces the coding style to the correct one. The same feature > > might be available for other editors too. > I hadn't noticed that the VIM modelines were present. They seem to dictate > 8-space tabstops (which is how my editor is set), which simply goes to > demonstrate that the problem is worse than I originally thought. Hmm... What is worse with forcing a unify coding style? Without the modelines every one has to set his own settings and the code get very different style. > No, my point wasn't that we should change the definition of a tab stop. Ah, sorry, I didn't understand correct. > The point was that our codebase should not contain tab characters at > all. Hmmm... With that I have no problem. I absolutely don't care if there are spaces or tabs. Vim is handling that stuff completely transparent for me. > At the very least, though, I think that trying to indent comments (that occur > on > the same line as some code) with tabs is a losing proposition ??? adding or > removing a single character can (and often does) throw the alignment way out > of > whack. Ehem, Adding or removing a single character if the code is indented with spaces _always_ change the alignment. > Also, spaces provide sufficient granularity to move the comment away > from the code without forcing the comment to be broken over two lines. If the line is long then also space indented comments are broken to new line. > > It would be nice to have beautified code. But that doesn't happens > > unless we prove that as a checkin filter. However. I prefer to _have_ > > comments than that they are left out cause of lazy to format them > > proper. (And programmers _are_ lazy. ;-) > True. However, consistently-formatted and -commented code is a _huge_ help > as > far as getting acquainted with a codebase; it can easily make the difference > between gaining new contributors and stumping people who move on because they > can't figure it out. > > To put that point clearly, yes, comments are good. The codebase doesn't have > nearly enough comments for me to suggest that their value outweighs the value > of > having them formatted consistently. Also, don't tell me it's a pain to add > or > remove some whitespace so that the comments line up; come on. Well, I just learned from the real world. If you force programmers to much then the result is less then other way around. > By contrast, working through geeqie's new-window creation process, I saw a > bunch > of different ways I could try to fix the color-management thing. The problem > was that it was practically impossible to tell which was correct or not ??? I > had > no way to figure out what a function was _intended_ to do, and the code was > often convoluted enough that I had to run it through gdb to figure out what > it > actually did. In many cases, there were different codepaths that appeared to > do > pretty much the same thing, and it was practically impossible to figure out > why > the codepaths were different, or what I might break if I tried to merge them. That is a point. The code was grown over long time. So that ends in the different solutions for the same think. However, Vlad did some unifying in the past (as I remember) and so it have to go on. I did also find some functions which are never ever called. (However, I just removed them in my local git repository.) > So, this leads to another thing: we need tests. We absolutely need tests. > Note > that what "test" actually means is "a specification of behavior." Otherwise, > it's difficult or impossible to know whether a potential change will break > some > other behavior, or modularity, or abstraction barrier. And what better type > of > specification than one that can also check and enforce that the code is still > in-spec? So, geeqie is a GUI application. How should every aspect of a GUI be tested automatically? Tests might be good for command line applications or for APIs but for GUIs tests are (in my opinion) meaningless. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBShu4wJ+OKpjRpO3lAQr1Rgf8CV7ng6GDyk0JpgXsPTzTx2yIjLd7jujz Uz5YmITcuWwz3qloWP4o8SAagXQVKaZ138GQndFD2W85LAkYW+YQvsqkSP5ic/Ep xUnxinZ0N6lzo4xmDHFgOJhlEjooyULHwbK4kKNYq44KvN438nTCM0uieVIV+cpV 3SFh1cjTzM/r1mclW6OaDIv62AxyDTERZOqNebldiQIx7Xf+bFfkqW/a3XJF85mm vvInxhX/9EviPPkqbxXKE8WA3ANPB5KHZN9efbL8B3S6/gM81BlP8FlMPQYNfLKt RdP0E9VQ//ykzTzEj184ajt5F+zbv9+nO/uHF3yDGkX3CZe+B6mm0w== =1Dpi -END PGP SIGNATURE- -- Register Now for
Re: [Geeqie-devel] Geeqie coding standards
Hi, On po 25. května 2009, Omari Stephens wrote: > Hi, all > > I found myself with some free time this weekend, so I'm trying to do some > more hacking. In particular, I'm again trying to get images in the "View > in new window" window to be color-managed. The plan is to drop img-view.c completely and use layout* for everything. It will be done after 1.0. It probably does not make sense to touch the img-view code now. > While doing some preliminary > reading, it suddenly dawned on me that some of the lines in geeqie are > _really long_. I mean, unmanageably so. > > Geeqie already has the beginnings of a set of coding standards, that being > CODING in the root of the source tree, but I think we need to extend it > some > Maybe it would be easier to agree on some automatic formatting style and run indent on every check-in. Vladimir -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie coding standards
Klaus Ethgen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > Am Mo den 25. Mai 2009 um 0:25 schrieb Omari Stephens: >> I found myself with some free time this weekend, > > Lucky dear. ;-) > >> #2) We need to get rid of tabs as an acceptable form of whitespace >> Yes, switching will be painful. But ever since people started telling their >> editors to use 4-character or 2-character tabstops, tabs have become more >> pain >> than they're worth. This is especially evident when people try to align >> code or >> comments written with one setting, and other people try to view them with an >> editor set to some different setting. This is clearly visible in [1], and >> it's >> ugly and hard to read (see lines 369, 375, and 380 for one example; >> 383???387 for >> another). > > I don't see the point. I myself prefer 3 spaces indenting. But I leave > the tap stops at 8 tabs which gets replaced automatically by my $EDITOR. > > At least for the editor Vim there should be a modeline in every source > file which forces the coding style to the correct one. The same feature > might be available for other editors too. I hadn't noticed that the VIM modelines were present. They seem to dictate 8-space tabstops (which is how my editor is set), which simply goes to demonstrate that the problem is worse than I originally thought. >> As a replacement, I would suggest using 4 spaces per level of indentation. >> I >> find that 4 spaces is wide enough that it's easy to visually track over long >> vertical distances (2 spaces is not), but is also not so wide so as to make >> it >> painful to write code 4-levels-deep (which is one problem with 8-space tabs). > > As I mention above I like to have 3 space indenting. That is enough but > not to much. But even with 3 space indent I always have 8 space tab > stop. I do not think that we should force to change this 8 space tabs. > That would be difficult viewing the source by less or printing it. No, my point wasn't that we should change the definition of a tab stop. The point was that our codebase should not contain tab characters at all. At the very least, though, I think that trying to indent comments (that occur on the same line as some code) with tabs is a losing proposition — adding or removing a single character can (and often does) throw the alignment way out of whack. Also, spaces provide sufficient granularity to move the comment away from the code without forcing the comment to be broken over two lines. ::snip? SNIP!:: >> There are clearly tons of options here, and I think "use your judgment" will >> have to be a big part of it. However, we still need some ground rules. >> Look at >> [1] again. The comments are _all over the place_. Switching to spaces (see >> #2 >> above) will make this much more readable, but having some sort of concrete >> suggestion would be a good thing. > > It would be nice to have beautified code. But that doesn't happens > unless we prove that as a checkin filter. However. I prefer to _have_ > comments than that they are left out cause of lazy to format them > proper. (And programmers _are_ lazy. ;-) True. However, consistently-formatted and -commented code is a _huge_ help as far as getting acquainted with a codebase; it can easily make the difference between gaining new contributors and stumping people who move on because they can't figure it out. To put that point clearly, yes, comments are good. The codebase doesn't have nearly enough comments for me to suggest that their value outweighs the value of having them formatted consistently. Also, don't tell me it's a pain to add or remove some whitespace so that the comments line up; come on. As for my personal experience, my employer has fairly strict coding guidelines, which include that functions/methods MUST be commented to be checked in. This dramatically reduced my time to get acquainted with the code, because I could read through it, read what each method did and was intended to do, and figure stuff out in my head. To reiterate, I knew where new code was supposed to go because the comments dictated what the different methods were intended to do. By contrast, working through geeqie's new-window creation process, I saw a bunch of different ways I could try to fix the color-management thing. The problem was that it was practically impossible to tell which was correct or not — I had no way to figure out what a function was _intended_ to do, and the code was often convoluted enough that I had to run it through gdb to figure out what it actually did. In many cases, there were different codepaths that appeared to do pretty much the same thing, and it was practically impossible to figure out why the codepaths were different, or what I might break if I tried to merge them. So, this leads to another thing: we need tests. We absolutely need tests. Note that what "test" actually means is "a specificat
Re: [Geeqie-devel] Geeqie coding standards
Klaus Ethgen a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Am Mo den 25. Mai 2009 um 0:25 schrieb Omari Stephens:
I found myself with some free time this weekend,
Lucky dear. ;-)
yep ;)
#2) We need to get rid of tabs as an acceptable form of whitespace
Yes, switching will be painful. But ever since people started telling their
editors to use 4-character or 2-character tabstops, tabs have become more pain
than they're worth. This is especially evident when people try to align code or
comments written with one setting, and other people try to view them with an
editor set to some different setting. This is clearly visible in [1], and it's
ugly and hard to read (see lines 369, 375, and 380 for one example; 383???387 for
another).
I don't see the point. I myself prefer 3 spaces indenting. But I leave
the tap stops at 8 tabs which gets replaced automatically by my $EDITOR.
At least for the editor Vim there should be a modeline in every source
file which forces the coding style to the correct one. The same feature
might be available for other editors too.
Vim modelines are present in current svn.
As a replacement, I would suggest using 4 spaces per level of indentation. I
find that 4 spaces is wide enough that it's easy to visually track over long
vertical distances (2 spaces is not), but is also not so wide so as to make it
painful to write code 4-levels-deep (which is one problem with 8-space tabs).
As I mention above I like to have 3 space indenting. That is enough but
not to much. But even with 3 space indent I always have 8 space tab
stop. I do not think that we should force to change this 8 space tabs.
That would be difficult viewing the source by less or printing it.
Current indentation rules are working, just use an editor which handles
them correctly.
#3) Set some guidelines for comment appearance
Should people use // or /*...*/ for single-line comments that appear on their
own line or after a semicolon?
Well, I myself prefer the // comments for the comments in the codeline.
However, to accept that is a Gcc extension. There is no prove that other
C compilers accept them too. So I think for portability we should stick
on /* */.
Yes.
But one thing we should start to do is to use doxygen format.
That is irrelevant for c++ files like exiv2.cc as the language supports
// comments.
True.
How much space should go between a comment and the semicolon? Should
comments on successive lines be aligned?
No preferences...
It depends...
There are clearly tons of options here, and I think "use your judgment" will
have to be a big part of it. However, we still need some ground rules. Look at
[1] again. The comments are _all over the place_. Switching to spaces (see #2
above) will make this much more readable, but having some sort of concrete
suggestion would be a good thing.
It would be nice to have beautified code. But that doesn't happens
unless we prove that as a checkin filter. However. I prefer to _have_
comments than that they are left out cause of lazy to format them
proper. (And programmers _are_ lazy. ;-)
However, there might be code beautifiers around the net like perltidy
for perl. Maybe we can find such.
GNU indent ([2]) will probably be useful for this process.
Yes. In fact, I used it while diving thought the code at the begin.
I made some attempts to use such tool a while ago.
The main issue is that it breaks some code vertical alignment.
Also our (inherited from gqview) way of indenting {} is not well handled.
Perhaps we may adopt another (generic) coding style.
I don't think it is a main issue for now though.
Among few things i'd like, return value of functions on the line just
before the name:
gint
somefunc(gint param1, gchar *param2)
{
code
};
it eases grepping on function name (grep -n '^somefunc(' *.c) and
shorten the line a bit.
A thing i _really_ dislike is space between function name and first
parenthesis as used in
glib/gtk code: func() vs func ().
Just some thoughts,
--
Zas
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie coding standards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Mo den 25. Mai 2009 um 0:25 schrieb Omari Stephens: > I found myself with some free time this weekend, Lucky dear. ;-) > #2) We need to get rid of tabs as an acceptable form of whitespace > Yes, switching will be painful. But ever since people started telling their > editors to use 4-character or 2-character tabstops, tabs have become more > pain > than they're worth. This is especially evident when people try to align code > or > comments written with one setting, and other people try to view them with an > editor set to some different setting. This is clearly visible in [1], and > it's > ugly and hard to read (see lines 369, 375, and 380 for one example; 383???387 > for > another). I don't see the point. I myself prefer 3 spaces indenting. But I leave the tap stops at 8 tabs which gets replaced automatically by my $EDITOR. At least for the editor Vim there should be a modeline in every source file which forces the coding style to the correct one. The same feature might be available for other editors too. > As a replacement, I would suggest using 4 spaces per level of indentation. I > find that 4 spaces is wide enough that it's easy to visually track over long > vertical distances (2 spaces is not), but is also not so wide so as to make > it > painful to write code 4-levels-deep (which is one problem with 8-space tabs). As I mention above I like to have 3 space indenting. That is enough but not to much. But even with 3 space indent I always have 8 space tab stop. I do not think that we should force to change this 8 space tabs. That would be difficult viewing the source by less or printing it. > #3) Set some guidelines for comment appearance > Should people use // or /*...*/ for single-line comments that appear on their > own line or after a semicolon? Well, I myself prefer the // comments for the comments in the codeline. However, to accept that is a Gcc extension. There is no prove that other C compilers accept them too. So I think for portability we should stick on /* */. That is irrelevant for c++ files like exiv2.cc as the language supports // comments. > How much space should go between a comment and the semicolon? Should > comments on successive lines be aligned? No preferences... > There are clearly tons of options here, and I think "use your judgment" will > have to be a big part of it. However, we still need some ground rules. Look > at > [1] again. The comments are _all over the place_. Switching to spaces (see > #2 > above) will make this much more readable, but having some sort of concrete > suggestion would be a good thing. It would be nice to have beautified code. But that doesn't happens unless we prove that as a checkin filter. However. I prefer to _have_ comments than that they are left out cause of lazy to format them proper. (And programmers _are_ lazy. ;-) However, there might be code beautifiers around the net like perltidy for perl. Maybe we can find such. > GNU indent ([2]) will probably be useful for this process. Yes. In fact, I used it while diving thought the code at the begin. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBShpaYp+OKpjRpO3lAQrATAf9Gk3qqlAqSNjaqPKJ/WYL21/DIE9MU4ti D4JQyhrgOQEGZAv60ok79b3L/um+kjJm1/NUGKB4HSwQ/TxeyL8ElFxoMZt5x1k2 li/9Y4YAjzPYgzZhgqgyY66Nhsd/zMoIaL0CackMjKrgNHYYikWYb4A8zWoqiWqc sZb7uNS3QF3/xkZJFYBBZaDhQte4e47Tmsssj6SpwBPGvv1A1+w3szXQy+wN3nqt YAGAPFs8JN8nlABMSimyL0yWBQpsp7s9sCiEnE5M+ze/ays/DdMBXbU74YHVu7XD eXLmMNnsh/iePI8mgXR7kwGS9ZFbBH3yYNrFv0R7E6H3qLTIZFHPKQ== =r2RY -END PGP SIGNATURE- -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
