[FFmpeg-devel] [PATCH 4/6] avutil/bprint: use AV_BPRINT_SIZE_AUTOMATIC instead of 1

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Friday, June 26, 2020 12:47 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/6] avutil/bprint: use
> AV_BPRINT_SIZE_AUTOMATIC instead of 1
> 
> Soft Works (12020-06-26):
> > Isn't it a clear benefit to have a named constant where the name of
> > the constant indicates a meaning while a plain number does not?
> 
> No. If you know the API enough to use it properly, then the meaning of 1 is
> obvious. If you don't, the meaning of the constant is obscure.
> 
> "Avoid magic constants" is not an absolute commandment to apply with
> dogmatism, it is a rule of thumb to apply with intelligence. Like the ban of
> gotos.
> 
> If this was new code, then maybe it would be slightly better to use the
> named constant. But so slightly that the time you wasted just writing this mail
> is enough to nullify it. And this is not new code.
> 
> Seriously, stop wasting time on useless pseudo-cosmetic changes.
> Building ffmpeg.c produces a full page of warnings. These are a few orders of
> magnitude more annoying than a magic 1.

Hi Nicolas,

I replied because ffmpeg code is just one out of many projects where I'm doing
some work occasionally and finding such 'naked numbers' in the code is a 
regular annoyance when you have to look it up to understand the code.
I want to hint that there's another perspective, and as such, I hope that 
my writing is not a total waste.

Isn't there a paradox anyway?

When the reason to object a commit is considering it unnecessary and 
wasted time - why spend time to object and cause the developer to spend 
additional time to change the commit?  Obviously, reverting the commit 
does not recover or save any time.

I understand when someone does not want to spend his time for replacing
numbers with constant definitions. But why prevent somebody else from
doing?

As an occasional (code-)user, I'd like to state that I welcome such changes.

Kind regards,
softworkz