Types, packages & objects : the good old naming conventions question (without religious ware)
in [ADA]
|
Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings
From: tmoran on 29 Oct 2009 18:41 > - Which group finishes first? > - Which group can change things faster than the other? > - Again? > - Which group's members are better at explaining > the software? > > Etc. Etc. - Give the software to another group that has never seen it and see how quickly, and how correctly, they understand and can make changes to it. - People differ. You may not find that one style is consistently better for all programmers. Can you find a way to tell which style is better for a particular programmer to write or for a particular programmer to read, and use that information in making your programming and maintenance assignments? > Does such a study exist? If not, why not? Perhaps such a study has been conducted, either formally or informally, and it did not appear there was a large, clear, benefit to one style or the other, so the decision was made, either explicitly or implicitly, to leave the choice up to the particular programmer or team.
From: Robert A Duff on 29 Oct 2009 20:01 Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes: >... For example, the role > can be given as "just any object" of the type. I would not be > comfortable with such an answer... In some cases, "just any object" is the right answer. No need for discomfort. For example, parameters of general-purpose procedures. function To_Upper(X: String) return String; -- Convert X to upper case. There's nothing interesting to say about X, except that it's a String. Just any String. Trying to come up with a meaningful name for X will just generate noise. In the standard package Ada.Characters.Handling, it's called Item, which is no more meaningful than X. In the GNAT front end, there are huge numbers of parameters declared as: N : Node_Id - Bob
From: Hibou57 (Yannick Duchêne) on 30 Oct 2009 00:52 On 29 oct, 19:11, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> wrote: > If you can't find a name for an object, ask more questions > about it, its use, its relations, the programmer, its purpose, > his purpose, etc: > What is the role of the object? Does the role lead to a name? > It might not, at first. For example, the role > can be given as "just any object" of the type. I would not be > comfortable with such an answer (though, for practical reasons, > I live with it): > The person who says "just any object" should be able to give > a reason why "just any object" is sufficient. The reason, > and in particular stating the reason using words, increases the > likelyhood of finding a name expressing the reason. > Or the reaons leads to other ideas which, again, lead to a > name. (just about this sole point, the remaining later) An example trap (to me at least) : what about a type which would seems obviously named Size and a parameter which seems obviously named Size ? X would surely not be OK, neither Item. An idea may be to get a more or less close synonymous (like Count... not very good) for the parameter for which one may naturally be tempted to name Size. But this seems (and is) a work-around, and if the word work-around really legitimately applies on that situation, this means there is a trouble (not natural, at least). Why the work around will probably applied on the parameter ? Because the parameter comes later when the type definition is already introduced (in the worst case, it may be tempting to change the type name). This latter detail makes us to come to another aspect of the trouble : choosing a practicable type name, may requires an amount of prediction over what instance names may be. Note : Triggering this, I'm not attempting to advocate for the _Type or other _Xxx suffix convention, as I honestly find that using a simple noun as a type name, is smart and elegant in many ways. I'm just attempting to evaluate both cases in a formal and long life prediction way. I'm short with this reply, but I will be back to reply to other interesting stuff written back here by peoples.
From: Jeffrey R. Carter on 30 Oct 2009 01:08 Hibou57 (Yannick Duch�ne) wrote: > > An example trap (to me at least) : what about a type which would seems > obviously named Size and a parameter which seems obviously named > Size ? X would surely not be OK, neither Item. If Size is the best name for the parameter, and assuming this a numeric value, then I'd call the type Size_Value. > An idea may be to get a more or less close synonymous (like Count... > not very good) for the parameter for which one may naturally be > tempted to name Size. But this seems (and is) a work-around, and if > the word � work-around � really legitimately applies on that > situation, this means there is a trouble (not natural, at least). Why > the work around will probably applied on the parameter ? Because the > parameter comes later when the type definition is already introduced > (in the worst case, it may be tempting to change the type name). This > latter detail makes us to come to another aspect of the trouble : > choosing a practicable type name, may requires an amount of prediction > over what instance names may be. I think that you shouldn't be writing anything until you've decided on the type and its operations, including their parameters. This isn't trouble. A type is usually only part of what you're creating, and it's important to think about the whole thing before committing any part of it to code. This is especially true for the visible part of a pkg spec. -- Jeff Carter "C's solution to this [variable-sized array parameters] has real problems, and people who are complaining about safety definitely have a point." Dennis Ritchie 25
From: Hibou57 (Yannick Duchêne) on 30 Oct 2009 01:28
On 30 oct, 06:08, "Jeffrey R. Carter" <spam.jrcarter....(a)spam.acm.org> wrote: > I think that you shouldn't be writing anything until you've decided on the type > and its operations, including their parameters. > > This isn't trouble. A type is usually only part of what you're creating, and > it's important to think about the whole thing before committing any part of it > to code. This is especially true for the visible part of a pkg spec. That's a good note (in my mind, I was thinking about any context, but its clear that the one you've pointed is particularly important and should be guiding). So let's go further the standalone concept of naming convention, and add a seed of method, which may say name a type and its instance names in primitives, all together (and the remaining should be OK) :) |