We at Eons use a particular naming scheme that is designed to extend the semantic information present in a filesystem URI.

  1. All names begin with a part of speech describing their purpose followed by additional, descriptive groupings. This often generates the pattern: {part-of-speech}_{descriptor-1}_{descriptor-2}...{descriptor-n}.
  2. The {part-of-speech} is a verb for tasks and a noun for products. For example create-file_my-file (verb, does work) vs file_myfile (noun, product of work).
  3. The descriptor is a series of terms, often nouns, in order of increasing scope (think of this as how you would organize your folders, with the top-most folder (e.g. /) on the right and the furthest sub-folder on the left). This means we would left-to-right-read if our folders would be /read/right/to/left.
  4. All sequentially related terms are separated with en dashes; e.g. narrowing-of-scope
  5. All distinct groupings are separated by underscores; e.g. thing_other-thing_yet-another-thing
  6. Distinct, non-sequential terms of a group are separated by commas; e.g. first,second,third_things
  7. Parentheses are used to impart a matrix-like, associative property to groups. For example, first-thing,second-thing,third-thing becomes thing(first,second,third), and (a,b)(1,2,3) expands to 1-a,2-a,3-a,1-b,2-b,3-b.
  8. This naming scheme does not use spaces and should keep special characters to a minimum.


The reason to organize each descriptor this way can be thought of as easiest to read while actively working on but descriptive enough to look back on. For example, if we are working on file_some-fork-of-my-file, with this naming scheme, we can stop reading once we get to “of” but can, likewise, continue reading for increased certainty that we have the right thing. When used properly, this naming scheme will allow you to quickly glance at the middle of a word to comprehend its full meaning and simultaneously contain enough information to be understood with only minimal context.


The ordering of descriptor groups is often arbitrary but can follow the same sequence as descriptor terms. The reason descriptor group order does not matter is that each group should represent a perspective through which a thing can be viewed. All perspectives are semantically equal and have no semblance of hierarchy. For example, if we have file_some-fork-of-my-file_subproject-project_1-Jan-2021, we could just as easily name the file file_some-fork-of-my-file_1-Jan-2021_subproject-project, as neither the date nor the project descriptor group is more important than the other. It may be the case that the first descriptor comes to bear more semantic weight than the others but this is not always the case. Also note that you can use whatever date format you’d like; however smallest time increment to largest time increment is recommended.


There should be very few, if any, perspectives through which two parts of speech mean the same thing. In other words, the first descriptor of a file should act as a unique identifier for how to treat the file. It is perfectly fine for parts of speech to be nested (e.g. a square_ is always a rectangle_ and could even be written as square-rectangle-shape_) but the contents of a file should have an absolute and unique means of being interpreted (e.g. square_s != triangle_s)

In software terms, a class of one part of speech may not inherit from a class of another part of speech, and when composing two parts of speech together, a third part of speech should be created. As a biochem example, this means you can’t have things that are both a western blot and a dna gel without creating a new combination of “quantified-expression-image” or the likes.


The Eons naming convention was developed in order to effectively communicate laboratory research results with remote teammates. The convention is thus much more applicable to condensing information of great complexity and can be burdensome, if not outright confusing, when dealing with information of low complexity. Despite this, we attempt to abide the Eons naming convention as much as possible, if for no other reason than to enable consistency across projects of varying complexities.

Limitations in Software

Unfortunately, most programming languages do not allow for dashes or parentheses (-) in variable names. While we can label files with this convention, we find it better to keep the name of the file the same as the name of the primary unit of code within the file (usually the class). Thus, we attempt to only use underscores in software development and reduce complexity wherever possible.