Suggestion - renaming, avoid excessive underscores about printf

[eyalroz]

Can you elaborate on the sense in which you find underscore use excessive? Do you mean the use of underscores at the end of function names?

I'm generally against abbreviations unless they're really necessary. I don't want the reader of the code to have to keep a bigger "dictionary" in their heads, decyphering shorthands and acronyms as they go, and wondering whether they actually mean the same thing as the long version of the name.

'prn' is a common abbreviation of 'print',

No it isn't... I've never seen any library using "prn" instead of "print". Maybe you mean prnf()? Even that is a bit fishy. If I see it, I would assume it might be somewhat different to printf().

Actually, it's bad enough that we have printf() rather than print_formatted() or formatted_print()...

It would make it obvious in applications which use prnf(), that they are not using the standard implementation.

1. And you believe it is not obvious that printf_() is not the standard implementation?
2. But it would make it non-obvious that they're using something that's compatible with the standard implementation.

printf() could still be overridden by the prnf() implementation, using #defines as it is now.

You can also write prnf() as a wrapper function around vprintf_() if you like.

[mickjc750]

Can you elaborate on the sense in which you find underscore use excessive? Do you mean the use of underscores at the end of function names? Yes. I'm fine with underscores replacing what would ideally be a space between words ie. do_something(). It's the use for the purpose of name dodging. No it isn't... I've never seen any library using "prn" instead of "print" To me it seems obvious, but perhaps it's from my DOS days. https://www.computerhope.com/jargon/p/prnd.htm 1. And you believe it is not obvious that printf_() is not the standard implementation? Of course not... Although I don't think anyone would actually want to use printf_() in source. If you were reading someone's source, and they had utilised an alternative implementation of printf, would you want to know?? I would say yes, but your point about compatibility has me second guessing myself. If prnf() is fully compatible with printf(), then perhaps the knowledge that this is an alternative implementation may be an unnecessary burden on the reader? I generally am ok with abbreviations, providing they are obvious and used strictly. I find the bulk of verbose names tiring. So for me, name dodging by abbreviation is preferable to name dodging by underscore. Although as you point out, printf_() does suggest that printf_() is compatible with printf() , which is a pro for the underscore approach. You can also write prnf() as a wrapper function around vprintf_() if you like. Given that users can opt not to override printf() and use their own wrappers to call it whatever they like (I doubt they would stick with printf_()) , it may be best to just leave this in their hands. Regards,

…

On Sun, Sep 5, 2021 at 5:24 PM Eyal Rozenberg ***@***.***> wrote: Can you elaborate on the sense in which you find underscore use excessive? Do you mean the use of underscores at the end of function names? I'm generally against abbreviations unless they're really necessary. I don't want the reader of the code to have to keep a bigger "dictionary" in their heads, decyphering shorthands and acronyms as they go, and wondering whether they actually mean the same thing as the long version of the name. 'prn' is a common abbreviation of 'print', No it isn't... I've never seen any library using "prn" instead of "print". Maybe you mean prnf()? Even that is a bit fishy. If I see it, I would assume it might be somewhat different to printf(). Actually, it's bad enough that we have printf() rather than printf_format() or formatted_print()... It would make it obvious in applications which use prnf(), that they are not using the standard implementation. 1. And you believe it is not obvious that printf_() is not the standard implementation? 2. But it would make it non-obvious that they're using something that's compatible with the standard implementation. printf() could still be overridden by the prnf() implementation, using #defines as it is now. You can also write prnf() as a wrapper function around vprintf_() if you like. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ2OLPSWL6MPT2B7OUA2B3UAMLJJANCNFSM5C735MZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- -- Michael Clift - Design Engineer. Clift Innovations Pty Ltd Suit 10/13 Walkers Road Nunawading, VIC 3131 ABN 24 286188328 Tel: [phone] Fax: [phone] Mob: [phone] Email: ***@***.*** Web: www.clift.com.au ***************************************************************************** PRIVATE AND CONFIDENTIAL This e-mail and any files transmitted with it are intended solely for the use of the addressee(s) and may contain information that is confidential or privileged. If you receive this e-mail and you are not the addressee(s), please disregard the contents of the e-mail, delete the e-mail and notify the author immediately. *****************************************************************************

[eyalroz]

My rationale for printf_() is: "This is just like printf(), but not printf() from the standard library."

The use of a trailing underscore for "just like but not quite" is common in, well, C++, e.g. when you have a member variable and you want to take an initializer with essentially the same name. So you typically named one of them foo_ and the other foo, or vice versa.

I'm not buying into prnf()... but if someone were to suggest a consistent alternative naming scheme for all functions with a rationale, I would seriously consider it.

Regardless - perhaps we can add an entry to the README about how to get whichever name you like with a wrapper.