opening comments

[Roedy Green]

Sun used to always start off a Java program with a comment like this:

/*
* @(#)Bio.java


Now Oracle always starts off with a comment like this:

/*
* %W% %E%
*
* Copyright (c) 2006, Oracle and/or its affiliates. All rights
reserved.
* ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/

I presume those mysterious symbols are commands to some version
control system.

Is there some recommended way for ordinary developers to begin
programs?

--
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
..

 

[Owen Jacobson]

Sun used to always start off a Java program with a comment like this:

/*
* @(#)Bio.java


Now Oracle always starts off with a comment like this:

/*
* %W% %E%
*
* Copyright (c) 2006, Oracle and/or its affiliates. All rights
reserved.
* ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/

I presume those mysterious symbols are commands to some version
control system.

Is there some recommended way for ordinary developers to begin
programs?

These are SCCS keywords, along with the replacement text, which is
usable by the 'sccs what' command. sccs is a much outdated version
control system; CVS's (well, RCS's) $Id$ and other keywords were
*inspired* by it, which should give you some idea of how far back this
goes.

While per-file content identifying a specific SCM revision might once
have been a useful idea, version control in general has moved towards
whole-project revisions and away from per-file revisions. With that in
mind, it's usually more than sufficient to include a single chunk of
SCM metadata in a project's build output - either a revision number, or
something more usable like a tag name. It's trivial to generate this
kind of metadata at build time.

Some tools do this (or something like it) automatically: maven, for
example, includes a copy of the POM as well as a short proprties file
in the META-INF dir of each JAR it produces, which for releases (you do
*tag* your releases, right?) is sufficient to identify the point in
version control a given binary was built from. It's also not terribly
hard to do it yourself, using your SCM tool of choice's version
interrogation facilities.

I would say:
* Don't bother putting revision keywords in your source files. They're
a source of spurious diffs if they ever get disturbed.
* In particular, anything that injects file history directly into a
file is a merge hazard. $History$ was notorious for blowing up merges
in CVS.
* Do include some kind of pointer back to the specific revision being
built in your release builds.
* Do it automatically.

-o

 

[Tom Anderson]

Sun used to always start off a Java program with a comment like this:

/*
* @(#)Bio.java


Now Oracle always starts off with a comment like this:

/*
* %W% %E%
*
* Copyright (c) 2006, Oracle and/or its affiliates. All rights
reserved.
* ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/

I presume those mysterious symbols are commands to some version
control system.

Is there some recommended way for ordinary developers to begin programs?

Unit tests.

tom

PS I'm here all week, folks! Try the steak.

 

[Esmond Pitt]

I presume those mysterious symbols are commands to some version

control system.

Not only that, they are evidence that the file hasn't been checked-in
properly. They should have been replaced or augmented by the replacement
text they refer to.