Programming

I have settled into this pattern:

1. Name expands as I understand better the structural role of a thing. Duplication in names begins to become easier to spot.
2. Removing duplication in names means introducing helpful structures, resulting in shortening names again, particularly as the intent/purpose of thing becomes clearer.

Long names stay unnecessarily long when we don't notice the patterns that suggest the missing structures.

The more examples of this kind of thing, the better!

(And my preferred name for that is rolesByEmployee. In general, "values by key".)

Though in some contexts, I might prefer a name like employeeToRole for a Map<Employee, Role> over the article's employeeRoles.

Following the article, the former describes the type (a map from employees to roles) while the latter describes the relationship (these are the employees' roles).

At the same time, I'm not pedantic enough to care in practice. Both are fine, and I'll get the point when I read either of those.

I agree with the author here that names don't need to be so verbose, but I also think there needs to be a balance. out or req or res are clear with context, but output, request, and response are always clear and not bad to write. http_response adds extra unnecessary info (unless there's another response variable in scope).

It also helps when languages support local variable shadowing. For example:

let response = foo();
let response = validate_response(response);

Both of these are responses, and fundamentally the same thing being passed around while being mutated. The types are (potentially) different. You won't use the first variable ever again (and in Rust, likely can't). Just reuse the name.

Great writeup! I shared with my devs