> Mhmm avoid the problem by saying
>
> int success = next_packet->AppendData(data, left);
> ASSERT(success);
It is always frustrating to see good programmers & software engineers using
bad-lazy practices (there are good-lazy practices too). IMNHO (I'll be
honest about that), omitting structure cues, whether or not they are strictly
necessary, is wrong.
Readability.
Consistency.
Folks, these are important. Many, many bugs I have had to deal with in other
people's code, if not most, have boiled down to just such poor, inconsistent,
"bad-lazy" practices. For example, omitting the braces and then coming back
and adding more code but forgetting to add them. That one happens a lot,
even with the brightest among us.
If I have to stop scanning through code and read back to figure out for sure
that there is a "block" there, then that wastes time. Sure, if I do it
enough I get pretty good at it, but it still takes additional time.
Contrast that with braces everywhere any type of block exists (whether empty,
with just one statement or many)...the code is *significantly* easier to
read, not to mention that the intention of the coder who wrote it is much
more clear.
Please, don't be part of the bad-lazy crown. Put the braces in. It does not
negatively impact compile time, so there should be no excuses.
BTW: Easier to read, structured, formatted code is significantly easier to
audit.
Sure. However, there's a chance that the standard (if indeed ASSERT is
part of the standard) already addresses this issue, in which case I'd like
to go with the slightly more streamlined syntax of omitting the {}'s.
I hope that you will consider (and then do it 
changing those back to
include braces { } wherever a block structure exists and they have been
omitted.
(I've already done it without {}'s for integrating the change and g++
is happy, but that of course doesn't mean it's standard-compliant.
I [idly] wonder how many folks build Bro with anything other than g++,
anyway.)
Not me :).