> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu]
>
> Now about this style thing: When I contribute to a project, I always put
> in that extra 1% effort to get the coding style consistent.
Not everybody is going to be like you. Not everybody understands code
consistency. I doubt most people would even know that Subversion uses a
consistent coding scheme throughout.
> Project
> policies range from "no consitency" (e.g., Samba) through "reasonable
> consitency" (e.g., APR or HTTPD or Subversion -- for the record,
> Subversion's style is _not_ my natural style, so I have to put in that
> bit of effort when I code for SVN, too) to "Use Emacs with the GNU style
> or else", such as GCC. And yet the effort to keep the style of the
> contribution consistent is never significant,
Neither is the amount of work for a committer to keep mum about stylistic
issues and fix it themselves.
> *if* one gets it through
> their head that projects /do/ have a preferred style and that they have
> a reason for that.
Preferred; remember that word. It’s a preferred style, not a required
style.
> That reason is usually to make the code more
> maintainable (I think most people will agree that having all the code in
> a consistent style _does_ make it more maintainable).
>
I'm not arguing this. I'm arguing that if the project is going to be so
prude about it they need to take action instead of sitting on their ass
delegating the work out to the nice patch writers.
> In this context, the coding style is (almost) as important as giving a
> good explanation of what your patch does and why, providing a good log
> message (again, project requirements for those differ), and of course
> making the actual implementation right.
>
This is where I feel you are wrong. Would you rather see a stylistically
incorrect patch but a technically perfect patch versus one that conforms
to all the style rules but has a host of technical issues with it? Simply
asking for everything to be perfect is naïve. Of the three: style,
log/description, content; the most important is the content. If the
content is good, the rest doesn't matter. Which leads me to my next
paragraph (What an awful segue).
I also agree with what Stefan (I think it was he) said on this one. By
reviewing a patch, the reviewer should be able to write their own log
message. If they can not write an acceptable patch, they are not familiar
enough with the patch code to be sure that committing it is safe.
I'm not saying patch writers shouldn't write a log message or a good one;
I'm just saying that if they write one that is less than perfect, the
reviewer/committer should be familiar enough with the code to generate a
more suitable one on their own.
> Doing only part of the work and then expecting others to do the rest, as
> I've seen suggested elswhere in this thread, strikes me as being
> slightly rude. So are remarks about how one doesn't _have_ to write
> patches, implying that every patch is a royal gift that we should grovel
> over.
Every patch _is_ a royal gift; it strikes me as rude that you don't see
that. You don't have to grovel, but you can damn sure show more
appreciation than "Thanks, but you put some white space in the wrong place
here, here and here". What's going to take you longer, writing the patch
yourself from scratch or taking a working patch from somebody else and
fixing up their style mistakes?
It seems like you're trying to have your cake and eat it too. If you want
patches that come in just perfect with no style issues, close the source
and reject all new contributors. Otherwise, deal with style problems and
be pro-active on correcting style issues with software instead of humans.
> Both tend to ignore the fact that the vast majority of the
> contributors to this project are doing it in their free time; I really
> don't see why they should support other people's lazyness.
>
>
> -- Brane
This statement implies one of the following:
1) People writing patches are getting paid so there-fore they can do the
style stuff, too, and not waste free time but rather paid time.
2) Your free time is more important than the patch author's free time.
This isn't the stone-age anymore. I find it absurd (As I've stated many
times in this thread) that in 2005, we're having this conversation. Write
a script/program or find one that cleans up source code formatting (I
don't know any off the top of my head, I'm afraid). Stop the problem on
your end; don't try to push it out to the users who more than likely don't
care about the project's hang-ups on stylistic issues. I think a nice
Python or Perl script doing some regular expression search/replace work on
a file would stop style issues dead. I think there are even version
control software out there that could run such a script in a thing called
a pre-commit hook. Wouldn't it be nice if you knew where you could find
VCS like that?
- Valik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 26 16:21:57 2005