You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Sinz <Mi...@sinz.org> on 2006/02/16 10:58:18 UTC
Re: any spaces ever?
kfogel@collab.net wrote:
> Greg Stein <gs...@lyra.org> writes:
>> Part of the dev-process with the no-space model is being able to
>> search for "dir(" so that you can find calls to the svn_fs_make_dir
>> function without picking up "dir" in random places. And without having
>> to type the full svn_fs_make_dir. Yup, a user strategy, but an
>> incredibly effective/efficient one.
>
> Hmm, I hadn't thought of that.
>
> We haven't been observing this convention in our code very much.
> Function calls will put the paren on the same line as the function's
> name when the first parameter also fits on that line, but when the
> first parameter is on the next line, we usually (but not always) put
> the paren on the next line too. Now that you mention it, the most
> consistent exception to that is code written by you... I always
> wondered what was up with, e.g., this from libsvn_ra_dav/session.c:
>
> authorities = svn_config_get_server_setting(
> cfg, server_group,
> SVN_CONFIG_OPTION_SSL_AUTHORITY_FILES,
> NULL);
>
> Now I know :-). Nice tactic. (It happens even more often in
> declarations, where it's less useful I guess, but whatever.)
>
> Anyway, one of the effects of r18471 was to undo a lot of those cases.
> Not all of them -- it turns out I missed 28, due to silly reasons not
> worth going into here. Now, I could put back the old cases, but
> they'd still be a minority and we'd be inconsistent. Or I could apply
> the patch below which "fixes" (or breaks, depending on how you look at
> it) the 28 remaining instances. I was about to test & commit this
> when I read your mail and decided to hold off.
>
> Thoughts? Greg? Anyone? Bueller?
My vote as to the style was based on the concept that the "(" was part of
the function token (not really, but syntactically) So, I would claim that
if the opening "(" is on the next line you break that rule and thus if you
are looking for "function(" you will miss those cases.
Any others from the "no-space" voting block? (I know what the "space" voting
block would say :-)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: any spaces ever?
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-02-16 10:19:41 -0600, kfogel@collab.net wrote:
> One of the problems with putting the paren on the previous line is
> that (at least in a default Emacs setup) it indents badly:
>
> ______________________________________________________________________
> | /* Simplified version check to make sure we can safely use the |
> | VTABLE parameter. The RA loader does a more exhaustive check. */ |
> | if (loader_version->major != SVN_VER_MAJOR) |
> | { |
> | return svn_error_createf( |
> | SVN_ERR_VERSION_MISMATCH, NULL, |
> | _("Unsupported RA loader vers[...]"), |
> | loader_version->major); |
> | } |
> `----------------------------------------------------------------------'
No-one would indent a code like that. So, this could probably seen as
a bug in the Emacs indentation code. It may be worth to report it.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: any spaces ever?
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 16 Feb 2006, Michael Sinz wrote:
> kfogel@collab.net wrote:
> > We haven't been observing this convention in our code very much.
> > Function calls will put the paren on the same line as the function's
> > name when the first parameter also fits on that line, but when the
> > first parameter is on the next line, we usually (but not always) put
> > the paren on the next line too. Now that you mention it, the most
> > consistent exception to that is code written by you... I always
> > wondered what was up with, e.g., this from libsvn_ra_dav/session.c:
> >
> > authorities = svn_config_get_server_setting(
> > cfg, server_group,
> > SVN_CONFIG_OPTION_SSL_AUTHORITY_FILES,
> > NULL);
> >
This style looks a little odd to me, but I could live with it. I hope
someone can modify svn-dev.el to make Emacs indent like this, though....
But I don't buy the reason - to find call sites - because of function
pointers.
> My vote as to the style was based on the concept that the "(" was part of
> the function token (not really, but syntactically) So, I would claim that
> if the opening "(" is on the next line you break that rule and thus if you
> are looking for "function(" you will miss those cases.
>
> Any others from the "no-space" voting block? (I know what the "space" voting
> block would say :-)
>
>
Heh, you know where I come from...:-) IMO, we were explicitly voting about
space characters; not newlines...
I think it makes sense to go with what's most used in the code currently -
or be slightly inconsistent and accept that and be done with it... But no
strong opinion.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: any spaces ever?
Posted by kf...@collab.net.
Michael Sinz <Mi...@sinz.org> writes:
> My vote as to the style was based on the concept that the "(" was part of
> the function token (not really, but syntactically) So, I would claim that
> if the opening "(" is on the next line you break that rule and thus if you
> are looking for "function(" you will miss those cases.
Sorry for the misunderstanding. A vote about "space" (as opposed to
"whitespace") can be interpreted differently by reasonable people,
yeah. But there are many places in Subversion that didn't abide by
the convention you describe, even in code that used the no-space style
*before* r18471. For example libsvn_ra_svn/client.c:
______________________________________________________________________
| /* Simplified version check to make sure we can safely use the |
| VTABLE parameter. The RA loader does a more exhaustive check. */ |
| if (loader_version->major != SVN_VER_MAJOR) |
| { |
| return svn_error_createf |
| (SVN_ERR_VERSION_MISMATCH, NULL, |
| _("Unsupported RA loader version (%d) for ra_svn"), |
| loader_version->major); |
| } |
`----------------------------------------------------------------------'
One of the problems with putting the paren on the previous line is
that (at least in a default Emacs setup) it indents badly:
______________________________________________________________________
| /* Simplified version check to make sure we can safely use the |
| VTABLE parameter. The RA loader does a more exhaustive check. */ |
| if (loader_version->major != SVN_VER_MAJOR) |
| { |
| return svn_error_createf( |
| SVN_ERR_VERSION_MISMATCH, NULL, |
| _("Unsupported RA loader vers[...]"), |
| loader_version->major); |
| } |
`----------------------------------------------------------------------'
I'm pretty sure that it was because of that indentation problem that I
first started putting parens on the next line (long before Subversion,
of course).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org