At some point, if a module/pass/service is large enough, it becomes worth investing in a local naming convention that carries the relevant type information, and enforce that convention through code reviews. Module-specific hungarian notations, if you will.
I'm working on an inference pass in a compiler, and it's up to 2000+ lines of F# manipulating tuples/dimensions/tables/chains/indices, and identifiers referencing these.
1. each variable in the module can have one of these ten types, not immediately obvious from their names. While I can hover the variable and have the IDE tell you the type, it happens so often that it feels like hunting for an invisible cow.
2. a typical method will contain several variables related to the same concept. When inferring a "group by" statement, I will have an "origin tuple", from which I infer the "origin chain", from which I extract the current "origin table", and construct an "origin index", from which I discard duplicates to obtain an "unique index", which defines a new "unique table" for which it is the primary "unique dimension", and there is a corresponding foreign "origin dimension" on the "origin table". Some of these will also need to be indirected through identifiers.
In the end, there's a "hungarian.md" file in the module that explains that a `vec` suffix is a vector, `vecs` is a vector tuple, `vid` is a vector identifier, and so on.
At some point, if a module/pass/service is large enough, it becomes worth investing in a local naming convention that carries the relevant type information, and enforce that convention through code reviews. Module-specific hungarian notations, if you will.
I'm working on an inference pass in a compiler, and it's up to 2000+ lines of F# manipulating tuples/dimensions/tables/chains/indices, and identifiers referencing these.
1. each variable in the module can have one of these ten types, not immediately obvious from their names. While I can hover the variable and have the IDE tell you the type, it happens so often that it feels like hunting for an invisible cow.
2. a typical method will contain several variables related to the same concept. When inferring a "group by" statement, I will have an "origin tuple", from which I infer the "origin chain", from which I extract the current "origin table", and construct an "origin index", from which I discard duplicates to obtain an "unique index", which defines a new "unique table" for which it is the primary "unique dimension", and there is a corresponding foreign "origin dimension" on the "origin table". Some of these will also need to be indirected through identifiers.
In the end, there's a "hungarian.md" file in the module that explains that a `vec` suffix is a vector, `vecs` is a vector tuple, `vid` is a vector identifier, and so on.