Prefix or suffix? [modified * 2]

[peterchen]

I prewfer top own (e.g. ZoomIncrease, ZoomDecrease, AxisRangeIncrease, AxisRangeDecrease) over the 'correct' but in my view struxturally garbled IncreaseZoo, DecreaseZoom, IncreaseAxisRange etc. This simply helps with orientiiton, and works better with IDE tools (class browser, intellisense etc.) For your example, I can't derive however if "Historic" would make a sensible group. (Of course it would even be better to have this as subobjects: Zoom.Increase, Zoom.Decrease, etc. but that wasn't the question, right? right?)

We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist

[Rajesh R Subramanian]

Look at a bunch of functions like: GetWindowName(), GetWindowClass(), GetWindowState(), SetWindowPos(). Window is an entity here and these functions are performing some action (or querying it for its own state information) on it to yield some result. I generally don't put the entity/type that I am performing an action upon at the end (of course, there can be something like GetWindow(), but that's different). Historic data (is that the term :~ ) is an entity in your case and you may perform various actions on it, like getting the index curve of it, getting the correlation, etc., Similarly, live data is another entity. So, we've got two different entities and we you shall build up functions around them. :) Of course, I know there may be exceptions and I'm just talking in general.

Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Codeproject.com: Visual C++ MVP

[Rama Krishna Vavilala]

Vikram A Punathambekar wrote:

getHistoricCorrelation()getHistoricRollDate()

As the function gets the historic correlation data, it makes sense to name it GetHistoricCorrelation.

You have, what I would term, a very formal turn of phrase not seen in these isles since the old King passed from this world to the next. martin_hughes on VDK

[Rajesh R Subramanian]

:doh: I must have read your reply before I replied to Vikram. I've suggested the same thing, but I think my explanation is far more confusing.

Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Codeproject.com: Visual C++ MVP

[Christoph Menge]

Hey Rajesh, obvioulsy we agree on this :-) I just read a few lines of "Code Complete 2" about naming methods: "To name a procedure, use a strong verb followed by an object" As you pointed out already, "Get" is already a strong verb - so the real question here is whether "Correlation" itself can be regarded as an entity - but that requires some knowledge about the subject matter (which I don't have). However, in "Code Complete", Steve McConnell also points out that in an OO-environment, the method itself does not need to include the object name, because it is included in the invocation such as myHistoricData.GetCorrelation(). I think I'd still go for this, if possible. On the other hand, that might raise question whether to name the class/webService "financialDataHistoric" or "historicFinancialData"... Chris

"Obstacles are those frightening things you see when you take your Eyes off your aim" - Henry Ford
Articles  Blog

[Rajesh R Subramanian]

Christoph Menge wrote:

myHistoricData.GetCorrelation()

I was thinking of a situation where you're writing this API on the global namespace. So, it made perfect sense to me to have names like ::GetHistoricCorrelation() and ::GetCurrentCorrlation(). Of course, it were a member function, then GetCorrelation() is sweet enough. :) On the perverted side, we can have an overload like ::GetCorrelation(Entity E) if we have too may entities on which we could possibly make this call. :-O

Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Codeproject.com: Visual C++ MVP

[Vikram A Punathambekar]

Rajesh R Subramanian wrote:

Historic data (is that the term ) is an entity in your case and you may perform various actions on it, like getting the index curve of it, getting the correlation, etc.

Au contraire. Correlation, IndexCurve, etc are entities, and I'm getting their historic (anything before today) and live (today's) values.

Cheers, Vikram.

---

"real dictators don't loose[sic] elections." - Diego Moita.

[Vikram A Punathambekar]

Christoph Menge wrote:

the real question here is whether "Correlation" itself can be regarded as an entity

Yes. SpreadCurve, IndexCurve, Correlation, etc are the entities. I'm building functions to get their historic (anything before today) and live (today's) values.

Cheers, Vikram.

---

"real dictators don't loose[sic] elections." - Diego Moita.

[Christoph Menge]

Hi Vikram, what I meant is: "Is correlation alone a sufficient description for the entity, or is it necessary to call it liveCorrelation?". In essence, I prefer GetHistoricalCorrelation() over GetCorrelationHistorical() like most (all?) of the other posters did. Chris

"Obstacles are those frightening things you see when you take your Eyes off your aim" - Henry Ford
Articles  Blog

[Vikram A Punathambekar]

Christoph Menge wrote:

Is correlation alone a sufficient description for the entity, or is it necessary to call it liveCorrelation?

Actually, yes. A SpreadCurve is an entity by itself. The only thing that differentiates between live and historical SpreadCurves is that the historical ones are from previous days. Thanks for your input; I'm somewhat surprised (and somewhat pleasantly so) to see pretty much everybody actually disagrees. ;)

Cheers, Vikram.

---

"real dictators don't loose[sic] elections." - Diego Moita.

[Robert Rohde]

Are you really planning that these methods don't have any arguments? What about making the difference with some kind of overload? Something like:

getCoorelation() --current
getCorrelation(Date date) --historic correlation of date

Robert

[Vikram A Punathambekar]

Generally speaking, the methods will have quite a few arguments. They are far from being finalized, though. Great suggestion, I was surprised nobody else noticed. :-D

Cheers, Vikram.

---

"real dictators don't loose[sic] elections." - Diego Moita.

[Rajesh R Subramanian]

I think in that case GetIndexCurveHistory() and GetIndexCurve(), etc., should fit in right. The word, histor_ic_ is a bit confusing.

Vikram A Punathambekar wrote:

I'm somewhat surprised (and somewhat pleasantly so) to see pretty much everybody actually disagrees.

Everyone disagrees, for a reason, may be? Or you just think that is plain coincidence? :-D

Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Codeproject.com: Visual C++ MVP

[Rajesh R Subramanian]

Vikram A Punathambekar wrote:

I was surprised nobody else noticed.

On my reply to Cristoph, I already said we could have overloads.

Rajesh R Subramanian wrote:

On the perverted side, we can have an overload like ::GetCorrelation(Entity E) if we have too may entities on which we could possibly make this call. :-O

Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Codeproject.com: Visual C++ MVP

[Al Beback]

I would consider: getCorrelation(bool historic); getRollDate(bool historic); along with getCorrelation(); // calls above with false getRollDate(); // calls above with false Cheers.

- Is God willing to prevent evil, but not able? Then he is impotent. - Is he able, but not willing? Then he is malevolent. - Is he both able and willing? Whence then is evil? - Is he neither able nor willing? Then why call him God? Epicurus

[Vikram A Punathambekar]

Not quite. Historic data should be available for a few years, so the date has to be specified. I'm gravitating towards what the other guy said - one overload that takes a date parameter.

Cheers, Vikram.

---

"real dictators don't loose[sic] elections." - Diego Moita.

[Vikram A Punathambekar]

Rajesh R Subramanian wrote:

I think in that case GetIndexCurveHistory() and GetIndexCurve(), etc., should fit in right. The word, historic is a bit confusing.

History doesn't really make sense. It implies you want the entire bunch of past values. I thought Historic was bang on target (and so did my UK colleague).

Rajesh R Subramanian wrote:

Everyone disagrees, for a reason, may be? Or you just think that is plain coincidence?

Not sure I understand what you're saying. :~ I still think getIndexCurveHistoric is better than getHistoricIndexCurve but I will go with the date overload. It will look like this:

IndexCurve getIndexCurve(string curveID);
IndexCurve getIndexCurve(string curveID, DateTime asOfDate);

Cheers, Vikram.

---

"real dictators don't loose[sic] elections." - Diego Moita.

[Shog9 0]

getCorrelation(string timePeriod) getRollDate(string timePeriod)

You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...

[Dan Neely]

Vikram A Punathambekar wrote:

I still think getIndexCurveHistoric is better than getHistoricIndexCurve but I will go with the date overload. It will look like this:

I like this better than any of the other suggestions I've seen.

Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull

[SuperJdynamite]

A convention I originally used for SQL, but has permeated into other code, was to not prefix procedures with "Get", "Set", "Update" or the like. Instead I have "CustomerNameSelect()" or "CustomerNameUpdate" instead of "SelectCustomerName()" or "UpdateCustomerName()". In an alphabetical listing I find it's easier to find what you want if all your "CustomerName" operations are lumped together rather than all your Select operations.