> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Nicolas George > Sent: Friday, June 26, 2020 12:47 PM > To: FFmpeg development discussions and patches <ffmpeg- > de...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
