Nick Sabalausky Wrote: > "Jim" <bitcir...@yahoo.com> wrote in message > news:ikvped$1o35$1...@digitalmars.com... > > Okay, so there's a discussion about identifier names in the proposed > > std.path replacement -- should they be abbreviated or not? > > Should we perhaps seek to have a consistent naming convention for all > > identifier names in Phobos? > > > > > > Some of the potential benefits: > > > > Legibility, understandability and clarity (reduce ambiguity). > > Ease in finding a suitable function/class by name. > > Knowing if it's a cheap or costly function call. > > Aesthetics and professional appearance. > > > > > > Some properties that I can think of for discussion: > > > > Abbreviation (and if so, what to abbreviate and how much)? > > Preference of commonly used terms in other languages, contexts? > > Use of get and set prefixes or not (getName() or simply name())? > > Explicit use of a prefix (example: calc or calculate) for costly > > operations? > > Naming of function and template arguments? > > Uppercase, lowercase, camelcase, underscore in multi-word names? All > > caps for constants, or different appearance for different types (types, > > functions, arguments, constants...). What about acronyms: TCP, Tcp? > > > > Are there other concerns? > > I think that every individual variable, function and type in Phobos should > use the naming convention of whatever random language the author happened to > be thinking of when they wrote it. That way Phobos won't seem messy. Plus, > the lack of any sensible rules would make it super-easy to remember all the > different spellings, punctuations and capitalizations. > > >
I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly D programming language we must require every D programmer to be fluent in English, Latin and Greek (including cultural references to movies and such), have *at least* expert Unix hacking credentials, have a certified MSFT engineering diploma, be Guru level programmers in all of the following: c, c++, Haskell, Perl, APL, LISP, ALGOL and COBOL. AND, lest we forget, they must code ONLY in a terminal based text-editor with 80 character wide lines.