1

Apparently naming things is one of the hardest things in programming..!

I have a synchronisation implementation which uses timestamps (number of seconds since unix epoch) to sync.

Currently, the timestamps have simply replaced an older revision field. My question is, does it make sense to name it "Revision" or is "Timestamp" better?

Revision makes sense to me since that's what's used to version an entity - to know what's created, updated, deleted. But if I needed to increase the granularity of the revision field in the future (ie. to become a decimal, to include fractions of a second), I wouldn't be sure that a decimal revision would make sense. On the other hand, perhaps I want to move away from timestamps in the future (ie. to sequence numbers) in which case revision would make sense.

closed as primarily opinion-based by gnat, Kilian Foth, Bart van Ingen Schenau, amon, Dynamic Mar 24 '14 at 18:46

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

1

Just my opinion, but I would call it timestamp (or more precisely, modification timestamp), not revision.

  1. It is a timestamp, so when it's named timestamp, someone seeing the field can infer when the file was last changed, whereas when it's called revision, people might be confused to see a huge number, like 1395653358, when it's just the first or second revision of the file.

  2. If you want to change the format of the field, e.g. towards using decimal time (fractions of seconds) or a revision count, I would suggest using a different field for that, anyway. Imagine the confusion when the value of the revision field is 1395653358, and then for the next revision it's 3!

Having said that, the best option might be to create a dedicated class for this. This not only hides the internal representation (which can also be made up of several field, like date of creation and last change, revision count, comment, etc.), but can provide methods for comparing revisions or generating new revision numbers, whatever format is internally used.

  • I think that's the best argument for using timestamp yet! We already have a class for this, it just works using timestamps at the moment. The client doesn't care what the revision or timestamp is, it just knows it needs to store it and send it back to the server. – Jamie Mar 24 '14 at 10:08
1

If it's simply a time stamp, and that is its only function, then call it a timestamp. If it has a larger purpose (i.e. Revision), then name it that.

Generally, it is better to name things by their function rather than their type. As you yourself pointed out, the type can change over time.

  • It's function is to track if something has changed since the client last made a request to the server. The client is essentially asking for everything with a revision or timestamp greater than the one it currently has. – Jamie Mar 24 '14 at 8:39
0

Revision implies that the field is updated when the object is changed. Revision does not necessarily imply that the field is a date/time, just that value is bumped each time the object is revised.

Timestamp implies that the field refers to the date/time that something happened. What? That's not implicitly clear. Last change? Creation? Last time examined? The world can be used to refer to any of these conditions, so often another word is added to indicate what you're tracking -- "Creation Timestamp", "Modification Timestamp", etc.

  • and don't forget that a revision is often composed of multiple files/documents. Each of which will have its own timestamp to indicate when it was last changed. – jwenting Mar 24 '14 at 7:42
  • Entities may all have the same "Revision" or "Timestamp" because if multiple entities are modified in a single request they are deliberately given the same timestamp. – Jamie Mar 24 '14 at 8:32
0

Revision to me is a count of how many times the object has been edited, and possibly even with an audit history. A timestamp though is just that, a stamp of he last time changed, often used for concurrency checks. I'd obsolete the old property and create a new one for the timestamp.

Not the answer you're looking for? Browse other questions tagged or ask your own question.