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
