On Tue, Apr 27, 2021 at 12:01 AM Gary Jennejohn <gljennj...@gmail.com>
wrote:
> On Mon, 26 Apr 2021 17:16:01 -0700
> Kevin Bowling <kevin.bowl...@kev009.com> wrote:
>
> > Yup, I don't want to fatigue Neel or the tree with unnecessary churn,
> > he had the parens, someone said something about brackets {} and he
> > removed the parens. Since the function needs a rework per mjg's
> > review, it could be done when that occurs.
> >
>
> I'd say that the misunderstanding was caused by the use of the word
> brackets in the comment.
>
> Looking up bracket on wiktionary gives this definitiotn:
>
> 5. Any of the characters "(", ")", "[", "]", "{", "}", "<" and ">",
> used in pairs to enclose parenthetic remarks, sections of mathematical
> expressions, etc.
>
> (Britain) "(" and ")" specifically, the other forms above
> requiring adjectives for disambiguation.
>
> (US) "[" and "]" specifically - as opposed to the other forms,
> which have their own technical names.
>
> So, if Neel is used to BE he would remove the parens, which he did. I,
> as an American, would have been looking for [] and been confused by not
> finding any.
>
Thanks for the explanation.
> So, in future it might be best to explicitly use e.g. {}, [], () in such
> comments.
>
Seems reasonable and effective. The man page uses precise language and has
the symbols.
> > On Mon, Apr 26, 2021 at 3:29 PM Rick Macklem <rmack...@uoguelph.ca>
> wrote:
> > >
> > > Neel wrote:
> > > >On 2021-04-26 09:47, Kevin Bowling wrote:
> > > >> I'm not sure all the context or conversation here but the convention
> > > >> is to not use bare return values, i.e in style(9) "Values in return
> > > >> statements should be enclosed in parentheses." and that's what was
> > > >> asked to be changed on this mailing list.
> > > Just fyi to everyone, there is this in style(9):
> > > In general code can be considered ___new code___ when it makes up
> about 50%
> > > or more of the file(s) involved. This is enough to break
> precedents in
> > > the existing code and use the current style guidelines.
> > >
> > > As such, if the "return 0;" predates this patch series, Neel is correct
> > > to use "return 1;", since that precedent has already been established.
> > > I'll admit I see the above ignored a lot and personally don't care if
> > > the above generality is followed, but it is in style(9) and I do
> > > think a consistent style is preferred over a jumble within a source
> file.
> > >
> > > rick
> > >
> > > The review: https://reviews.freebsd.org/D29988
> > >
> > > I believe I was asked to do this in the review.
> > >
> > > -Neel
> > > >
> > > > Can you use and link to Phabricator for your src commits? As much as
> > > > possible it is preferable to get it right in one go, for MFCs,
> > > > bisection, etc and this kind of churn should be preventable with
> quick
> > > > reviews. Feel free to tag me as a reviewer.
> > >
> > > Sure, will do next time.
> > >
> > >
> > > > Regards,
> > > > Kevin
> > >
> > > -Neel
> > >
> > _______________________________________________
> > dev-commits-src-all@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
> > To unsubscribe, send any mail to "
> dev-commits-src-all-unsubscr...@freebsd.org"
>
>
> --
> Gary Jennejohn
>
_______________________________________________
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"
