On Mon, Oct 13, 2014 at 5:25 PM, Jim Grosbach <grosbach at apple.com> wrote:> This convention sounds like it would cause people to have to be constantly > asking themselves "is this common enough to be an initialism-as-word or > not?". The thing that started this conversation was someone complaining > about going between codebases that they weren't sure whether to capitalize; > now that person will have to get a feel for the local initialism-as-word's, > which is a much greater burden than just the naming convention. > > > Perhaps, but IMO, I think we’d get a long way with a “If you really have > to stop and ask, it’s not common enough,” guideline. >Moreover, this seems like the easy stuff to sort out in code review. If you aren't sure, it isn't common enough. if the reviewer then says "yes it is", well, now you know. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/2710c83f/attachment.html>
On Mon, Oct 13, 2014 at 5:29 PM, Chandler Carruth <chandlerc at google.com> wrote:> > On Mon, Oct 13, 2014 at 5:25 PM, Jim Grosbach <grosbach at apple.com> wrote: > >> This convention sounds like it would cause people to have to be >> constantly asking themselves "is this common enough to be an >> initialism-as-word or not?". The thing that started this conversation was >> someone complaining about going between codebases that they weren't sure >> whether to capitalize; now that person will have to get a feel for the >> local initialism-as-word's, which is a much greater burden than just the >> naming convention. >> >> >> Perhaps, but IMO, I think we’d get a long way with a “If you really have >> to stop and ask, it’s not common enough,” guideline. >> > > Moreover, this seems like the easy stuff to sort out in code review. If > you aren't sure, it isn't common enough. if the reviewer then says "yes it > is", well, now you know. >If you're willing to blow off this issue as "easy stuff to sort out in code review", why not just blow off the entire variable naming issue since that is also "easy stuff to sort out in code review"? -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/0dd57691/attachment.html>
On Mon, Oct 13, 2014 at 5:44 PM, Sean Silva <chisophugis at gmail.com> wrote:> On Mon, Oct 13, 2014 at 5:29 PM, Chandler Carruth <chandlerc at google.com> > wrote: > >> >> On Mon, Oct 13, 2014 at 5:25 PM, Jim Grosbach <grosbach at apple.com> wrote: >> >>> This convention sounds like it would cause people to have to be >>> constantly asking themselves "is this common enough to be an >>> initialism-as-word or not?". The thing that started this conversation was >>> someone complaining about going between codebases that they weren't sure >>> whether to capitalize; now that person will have to get a feel for the >>> local initialism-as-word's, which is a much greater burden than just the >>> naming convention. >>> >>> >>> Perhaps, but IMO, I think we’d get a long way with a “If you really have >>> to stop and ask, it’s not common enough,” guideline. >>> >> >> Moreover, this seems like the easy stuff to sort out in code review. If >> you aren't sure, it isn't common enough. if the reviewer then says "yes it >> is", well, now you know. >> > > If you're willing to blow off this issue as "easy stuff to sort out in > code review", why not just blow off the entire variable naming issue since > that is also "easy stuff to sort out in code review"? >This feels like an inflammatory line of discussion. Yes, we can in fact make a rational distinction that *some* aspects of naming are worth codifying in a coding standard and other aspects are not. If you disagree with the distinction I am drawing, please state why and suggest a different rubric. Don't just raise a straw man of "why have a convention at all". That isn't helpful. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/8aedb636/attachment.html>