> How does RCS keyword expansion fit into this? Does that not modify the
> contents of the user's committed file? In fact there are a myriad of
> tools that perform pre-processing of source before compilation. In
fact
> compilation itself can change the behavior of source code. In
addition,
> source code generally relies on external libraries that can be changed
> and modified even as far down the road as runtime. Source code
> formatting should be the least of the developers worries when it comes
> to the intended behavior of their source code being reflected in the
> actual behavior of the application. In fact they shouldn't have to
worry
> about it at all, their tools should take care of it for them.
I don't use RCS keyword expansion for this very reason ;). Processing
code before compiling and after checkin are two completely different
things.
SCM involves tracking more than source code, as you allude to above.
Also, you say their tools should take care of it for them, and I agree.
Developer tools being their IDE or editors. Source control being an SCM
tool. I'm paid to track and build code, not alter it once it's in my
hands, by using a tool or otherwise.
I can go on and on about how the information in any RCS keyword is
contained in the metadata of any file in the source control database
anyway, so it's inherently useless. If you are sending your code out to
a third party, you damn well better know what it is when you send it and
where it came from, lest your third party edit your RCS keywords
(expanded) out so they can get a decent diff.
> > If your engineers are not coding against your standards, they
> > need to be taught to do so. I would urge you not to alter
> > their code behind their backs. If they aren't *writing* in a
> > certain style, then they won't be able to *read* it later. A
> > better idea might be to have a mechanism to check the coding
> > style and refuse the checkin if it is not up to snuff.
>
> I'm not convinced. There really is no reason that code formatting
> shouldn't be integrated into a repository. It still seems to me that
it
> would be very convenient to check-out a piece of code, have it
displayed
> in a format it to my liking, modify it, then check it back it without
> thinking of the formatting. If there is a conflict, the diff will be
> displayed post-format, which will factor out all insignificant
> differences and show only logic differences. This is simply an
> enhancement to a tool, allowing developers to work in a style they
feel
> comfortable in while still maintaining a consistent easily diff'ed
style
> in the repository. Formatting factors out insignificant changes, so
> revision 1.1 is truly different than revision 1.2.
I still respectfully disagree. If I'm writing code or a novel, I don't
want someone editing it without my knowledge. Here's another example in
a different context that I come across practically every day:
Why Johhny Can't Write - Because he doesn't have to know how to. Johnny
is in his early 20's and is a college graduate. Johnny comes to work at
Corporation X and has to give a presentation, complete with marker
board. His notes on the board look like someone illiterate wrote them.
He doesn't speak in a very articulate way, either. Why? Johnny has been
reared on the auto-correcting word processor. His resume is impeccable,
his e-mails read like Updike, but try to engage him in a hall way
conversation and you wonder how Johnny can feed himself.
That's a little bit of an exaggeration, but if you have an opportunity
to talk to 'kids these days' you'll find a good chunk of them can't put
together a complete sentence to save their lives. Mainly because they've
never had to, the word processor does it for them.
So, is this a good scenario? Is it good to let Johnny programmer think
he's writing the best code in the world? Perfectly formatted to the
Corporation's coding standards? Even though he's not? What happens when
Johnny's code is reviewed and someone has to ask him about it? He might
not even recognize it. And God forbid Johnny is called upon to review
someone else's code. He's not even speaking the language. Better for
Johnny to know the language than to have someone secretly interpreting
his lousy code. The code will bite back one day, I guarantee it.
-Matt
**********************************************************************
E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail.
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 22 23:44:22 2005