First, some of these suggestions will make it harder to introduce bugs when updating the code. That's good! Particularly tricky is when somebody splits up identifiers or function names. These types of things often occur at boundaries (calls between servers or to the db) which can make them tricky to test. Even if all your identifier combining is initially done in a single file, it's easy for someone to see the final shape of the identifier and accidentally hard code it somewhere else.
Second, In the spirit of Titus Winters' "software engineering is programming over time", a codebase should be greppable over time.
That means that if you rename a function, you might consider saving the old name of the function in a comment.
First, some of these suggestions will make it harder to introduce bugs when updating the code. That's good! Particularly tricky is when somebody splits up identifiers or function names. These types of things often occur at boundaries (calls between servers or to the db) which can make them tricky to test. Even if all your identifier combining is initially done in a single file, it's easy for someone to see the final shape of the identifier and accidentally hard code it somewhere else.
Second, In the spirit of Titus Winters' "software engineering is programming over time", a codebase should be greppable over time.
That means that if you rename a function, you might consider saving the old name of the function in a comment.