Naming

Here are the emergent-specific naming conventions -- please use these to keep the code as readable and consistent as possible!

First, we follow all the general Go conventions:

• https://golang.org/doc/effective_go.html#names
• https://github.com/golang/go/wiki/CodeReviewComments

And here are some additions for the Cogent Core framework:

• https://www.cogentcore.org/core/architecture/principles

Relative to the v1 version of emergent, the new v2 version based on Cogent Core makes these key changes:

• The emer interface is now minimal, only for functions that need to be defined for specific algorithms. This eliminates interface accessor methods and associated name conflicts.
• The emer.LayerBase etc base struct types have all the shared functionality. Use AsEmer() on the interface type to get to this base type. Thus, Name is just Base.Name, not .Nm and .Name().
• Eliminated the *Try versions of methods in favor of the errors.Log1(fun()) wrapper from Cogent Core errors package, which logs a non-nil errors 2nd arg, and returns the first arg (Log1 = 1st arg), so you can directly use the results in an inline expression.
• Generally removed acronyms, including Col -> Column, Idx -> Index etc.
• Renamed Prjn -> Path to avoid that unfortunate acronym. Projections are Pathways -- much better!

Changes from C++ emergent

This is the principle from the Ki naming page:

• avoid adding generic terms like Item, Data, State, Run, Compute, etc to names -- you'll find that they are usually superfluous -- almost everything a computer does involves these things, so just focus on what uniquely applies to the particular case you're trying to name.

In C++ emergent, we used "Data" and "Compute" extensively, and have now removed all uses thereof, to the great benefit of making the code much more succinct and clear. The first version of the ra25.go example project still violated this principle, but has now been fixed..

Standard receiver names

For methods, the Go standard is to use a consistent, short abbreviation of the type for the receiver variable. We typically use 2 letters to make it easier to search-and-replace vs. a single letter.

To make code more portable for copy-paste programming, the following standard names are always used instead of renaming for each type:

• ly for all Layer methods, even if it is a specific kind of layer (e.g., GPiThalLayer)
• pt for all Paths
• ev for for all env.Env environments

Leabra-specific naming issues

See the Leabra README for specific naming conventions for that algorithm.