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 <ma...@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@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
