There’s no issue with abstracting code into a helper function. If we want to optimize for cognitive load, the intent should be as clear as possible, starting with the name.
The msw/lsw naming solution really clicks for me. It's intresting how much the "chunk slot" cost comes from ambiguity rather than abstraction itself. I've seen similar issues where helpers that seem conveniet at first end up costing more mental energy when you have to open them to understand parameter order. Do you think there's a point where being too explicit in names backfires?
In some languages (with named arguments) you could write this as:
make_u32(msw: 0xABCD, lsw: 0xEFEF)
That similarly reduces the ambiguity and enhances readability.
But I think the other thing not discussed here was the principle of "telling one story" with a given patch set. Introducing a new way to combine 16-bit words is "one story", and it belongs in a patch set that continues the story by applying this new abstraction across the code base. Then you can read it in context and judge whether it makes the code easier to read, more fool proof, etc.
"Bug fixes for the RISC-V platform" is an entirely different "story" and shouldn't be commingled in one patch set. It might *depend* on the earlier patch, but its not the same story.
Would you send this new less ambiguous abstraction to Mr. Torvalds? If no, then the problem is not the ambiguity ;)
The msw/lsw naming solution really clicks for me. It's intresting how much the "chunk slot" cost comes from ambiguity rather than abstraction itself. I've seen similar issues where helpers that seem conveniet at first end up costing more mental energy when you have to open them to understand parameter order. Do you think there's a point where being too explicit in names backfires?
In some languages (with named arguments) you could write this as:
make_u32(msw: 0xABCD, lsw: 0xEFEF)
That similarly reduces the ambiguity and enhances readability.
But I think the other thing not discussed here was the principle of "telling one story" with a given patch set. Introducing a new way to combine 16-bit words is "one story", and it belongs in a patch set that continues the story by applying this new abstraction across the code base. Then you can read it in context and judge whether it makes the code easier to read, more fool proof, etc.
"Bug fixes for the RISC-V platform" is an entirely different "story" and shouldn't be commingled in one patch set. It might *depend* on the earlier patch, but its not the same story.