I guess we will disagree. Your way is still hostile to new maintainers because it carries so
much implicit information. What if your code code has this?
inode->i_blocks = bytes >> 8;
What is a new maintainer to think? Even if he does recognize that this expression is
different from the others, he's still confused. Did you auto-optimize the expression (bytes
>> 9)*2? Is it typoed or a thinko?
Will every potentially confusing use of the shift operator in your code include a comment
stating the author's intention? If so, then will that convention still be true once someone
else has modified your code?
Also, you've given yourself a rather heavy restriction on variable naming haven't you? Will
all your variable names really contain "blocks" and "bytes" as appropriate? You'll probably
want to add this restriction as a comment to each file to which it applies or it won't last
long once other people start committing patches to your code!
Finally, your technique only works for trivial expressions like assignment. What happens if
you need to actually perform a calculation?
A BYTES_TO_BLOCKS macro solves all these problems by making the conversion explicit. Implicit
rules and unwritten conventions always make life hard for new maintainers. Always.
so it would seem the linux kernel believes numbers are usually clearer for others to read and understand.
if you believe otherwise submit a patch to the kernel removing all occurrences and replacing them with meaningful #defines.
#define 'ing all numbers is stupid, using identifiers that describe what they are should allow anybody to understand their context, if you use lots of operators and numbers in a single expression split them up to use multiple variables with appropriate names, if they are in conditions use multiple conditions with comments if necessary. The compiler will optimize all these away and make your code more readable without have 15 editors open or using code navigators to work out that the actual value of CLUSTERS_DIVIDE_BY_BYTES_IN_SECTORS_MULTIPLIED_BY_PI(x) is 2.