[Development] Signal naming convention (was: A modest proposal: disable lower-case keywords...)

[Benjamen Meyer]

Honestly, a naming convention may solve the issue within the Qt
code-base, but I don't think it would necessarily be adopted by all
users of Qt.

Personally, I in my Qt projects I just use the Q_EMIT macro, and I do
find that helpful.

The downside of the naming convention aspect is that Lambdas may be
involved so it might not be clear based on the name either, at least
when looking under a debugger.

Overall, the conversation has been interesting, and while my opinion may
not matter much (being I haven't been involved much in the last few
years given work constraints) - I'd lean towards moving away from `emit`
and back to using `Q_EMIT` and then allowing `Q_EMIT` to generate the
compiler annotation for supported compilers or being an empty macro in
other cases.

Any how... $0.02 FWIW.

Ben

On 2/28/20 3:13 PM, Vasily Pupkin wrote:
> Prefixing identifiers is a slippery slope. In a fit of unifying coding
> style everything will get prefixed. There will be slot_, m_, property_,
> setter_/getter_ and so on.
> Type name prefixing worth mentioning - unbelieably ugly
> convention  https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions .  
> 
> If you do this in your code base, consider postfixing, rather than
> prefixing. It enables better readability.
> Given a module, that implements a feature with several aspects.
> class Feature
> {
>     void aspect1_signal();
>     void apscet1_slot();
> }
> 
> пт, 28 февр. 2020 г. в 22:38, Max Paperno <max-l at wdg.us
> <mailto:max-l at wdg.us>>:
> 
> 
>     I humbly suggest, in general, that a signal name could be prefixed with
>     "sig", "sig_", "signal" or "signal_".  "sigEmptied()" doesn't look
>     horrible IMHO, and should work semantically with any verb. Using
>     prefixes to signify meaning already has some precedence in C/C++ world
>     as well. And lastly even "dumb" syntax highlighters could pick up on
>     that pretty easily (even w/out access to, or needing to parse, any
>     header files to determine what is a signal), though of course there
>     could be "false positives" for any other words starting with "sig"
>     (like
>     "significantElements()" :) ).
> 
>     As a Qt user and frequent reader of other people's code (like on
>     StackOverflow for instance to answer questions, git repos, code
>     reviews,
>     e-mails, etc, etc), it's clearly useful to know that a method call is a
>     signal vs. anything else. I'd rather not have to remember that "hot
>     pink
>     color on SO highlighter" means it's a signal (and in many cases there's
>     no way for a highlighter or basic text editor to even determine that).
> 
>     Cheers,
>     -Max  (returning to lurk mode)
> 
>     (This is not a reply to anyone in particular, just quoting the most
>     recent relevant bits below.)
> 
>     On 2/28/2020 4:34 AM, Edward Welbourne wrote:
>     > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
>     >>> Taking a step back... I think some of the reason for the current
>     >>> situation has to do with API design. Which of these is easier to
>     understand?
>     >>>
>     >>>    if (map.empty())
>     >>>      emptied();
>     >>>
>     >>> - vs. -
>     >>>
>     >>>    if (map.isEmpty())
>     >>>      emit emptied();
>     >>>
>     >>> One reads like plain English. The other is missing words in a
>     way that
>     >>> can confuse readers.
>     >
>     > Allan Sandfeld Jensen (27 February 2020 23:03) replied:
>     >> That is how I see it too. It essentially violates Qt code
>     guidelines. If it
>     >> was a normal method we would name it "emitEmptied()", so far we
>     have just
>     >> lived with "emit emptied()" instead.
>     >
>     > Indeed; most of the case for "emit" can be answered by a sensible
>     naming
>     > convention.  Even the case of "functions that trigger signals" can be
>     > handled by that, when it really matters.
>     _______________________________________________
>     Development mailing list
>     Development at qt-project.org <mailto:Development at qt-project.org>
>     https://lists.qt-project.org/listinfo/development
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> 


-- 
Ben Meyer
Software Engineer
(703)901-2797
bm_witness at yahoo.com