Michel Fortin wrote: > On 2009-04-12 14:24:07 -0400, Leandro Lucarella <llu...@gmail.com> said: > >> Leandro Lucarella, el 12 de abril a las 15:19 me escribiste: >>> Michel Fortin, el 12 de abril a las 12:54 me escribiste: >>>> On 2009-04-12 11:09:51 -0400, Lars Kyllingstad >>>> <pub...@kyllingen.nospamnet> said: >>>> >>>> Perhaps it should be renamed to isUnbounded then. >>> >>> I was about to write exaclty the same suggestion. I'm glad I read the >>> responses before posting =) >> >> Maybe isBounded, to avoid the double negation when checking for >> !isUnbounded... > > Which makes me think of one thing: why "isBounded" instead of plain and > simple "bounded"? Ranges don't respond to "isEmpty": they have "empty" > instead. > > I think it is time to establish some kind of standard for naming things, > and then follow it. Something a little like Cocoa's Coding Guidelines > comes to mind: > > <http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html>
You mean http://digitalmars.com/d/1.0/dstyle.html ? That said, the "Naming Conventions" section is actually about formatting names, not choosing them. One major advantage Cocoa has over D is that argument names seem to be part of the function's name. For example, this call: sendAction(aSelector, anObject, flag); appears to be written like so in Objective C: [sendAction: aSelector to: anObject forAllCells: flag]; To be honest, there are times I almost wish we could not only name arguments on the caller side, but demand that they're named in the definition. void sendAction(SEL, Object to, extern bool forAllCells); sendAction(aSelector, to: anObject, // optional forAllCells: true); // required -- Daniel