Hi Arman, >>>>> + unsigned int notify_id, indic_id; >>>> >>>> I have never seen indication shorted into indic. I have to say that >>>> I do not like it that much. However I do not have any good >>>> suggestion either. >>>> >>> >>> Perhaps "indicn_id"? I could just spell out "indication_id" :P. >> >> What's wrong with "ind"? It's used in many places in the tree as a >> shorthand for indication and even shared/att.c uses it. On the other >> hand if you want to match the grammatical form of notify_id you should >> use indicate_id (which feels much worse to me). Third option that comes >> to mind if we want short versions of both is "ind" and "nfy", but not >> sure how decipherable the latter is. >> > > I initially had "ind" for indication and "not" for notification (which > seemed to be consistent with other places in the code, as you said), > though Marcel didn't like those :P I guess "ind" isn't super > suggestive of "indication" and, as Marcel pointed out earlier, "not" > is easily confused as "negation" rather than "notification. lets go with ind_id and notify_id for now. We can always change this later and I do not want to hold up merging patches because of that. It is just that the not_id and not_* is something that makes my brain always go into the negation first and that is not good coding style. > I personally prefer not to shorten them at all and spell out > "notification_id" and "indication_id", which I find the most readable. > I only started contracting things after mailing list feedback saying > not to use long names. We need to be careful with super long names since they can be nice and explanatory in some cases, but in other cases they cause large indentation and weird line breaks which then turns that code into unreadable mess. So this is something you have to weight against each other. This is not black and white, and the right answer is normally what makes code the most readable. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
