目次

Version 1, last updated by mads379 at Nov 27 20:17 UTC

The following is completely not at all finalized and is based on my understanding from reading through the relevant threads. Please update.

General Goals and Guidelines

(These are clear but very general rules that should never be broken, although in some cases names may not conform due to backwards compatibility considerations. They MAY conflict with each other in some cases! For more specific conventions, see below.)

  1. Remove ambiguity wherever possible! There are a number of places
    where very similar names are used to refer to utterly different
    things. Kris
    • As an aide removing ambiguity, consider outlawing or eliminating
      extremely generic names, or else establish a single way in which a
      given name will be used across Lift. Examples are Field, Info, Holder,
      etc. The issue I take with FooHolder is that this name doesn’t say anything about why you
      might want to have that particular kind of container (or indeed have a
      container at all) for a Foo. In some sense, every object that contains
      data is a holder – and I don’t think “StringHolder” makes much sense;
      why does FooHolder? Kris
  2. Prefer Scala-style accessors and mutators (def x, def x_=) over Java get/set. Kris
  3. Use abbreviations cautiously: Only abbreviations which are commonly recognized may be used as part of a name Heiko and nafg
    • And the expanded version is provided in the comments. The comments should java/scala doc where possible Jim
  4. Names should not be too long, to serve those not using IDEs dpp
  5. Use names related to the “nature” of the thing being named: We should be able to know what a type is or a method does from reading its name. Heiko
  6. “Best choice” name over scala conventions per se dpp
  7. Most popular setter syntax for fields was apply syntactic sugar dpp
  8. To change an existing name it must either
    • Be possible to deprecate the old name so that old code is not broken dpp
    • Or be used only internally or rarely enough that those who do use it will be able to migrate easily dpp
    • Or have a very compelling reason dpp

Conventions

(Here more specific rules should be compiled, e.g., when to use calc as opposed to calculator or which to use always, etc.)
TBD

  1. Property names should not use spaces adamw