File Naming Convention

[KotzaBoss]

It is important to maintain a convention for directory, file, function and variable names. While Qt is solid, it is a general guideline which i propose we specialise.

PROPOSAL:

• Directory names: All lowercase with - for word separator if necessary. Eg.directory-of-doom/
• File names: Follow Qts convention but change Q to A. Eg. ADataBase.h
• Class names: Like above added A in the beginning. Eg. class ADataBase
• Free function names: Follow Qts convention with an extra a. Eg. aConquerTheWorld()
• Static functions: Without a and snake_case to emphasise limited scope. Eg. void utility_function_one()
• Limited scope variables: Variables like constructor parameters that are "consumed" should be snake_case. Eg.

APilotEntry(int throwaway_variable)
    : importantMemberVariable(throwaway_variable)

• Constants: All capital snake_case. Eg. const auto IMPORTANT_CONSTANT = ASecretOfUniverse(42);
• Type Aliases: [debatable] Follow Qt quidelines. Eg. using NewType = QMap<QString, int> [?]

Assume that A comes from Aviation :D

RATIONALE
Through this we can maintain a consistent aesthetic that is able to, at a glance, give context to the reader.

• AFooBar suggests an important custom class.
• FooBar suggests alias of important type. [?]
• aFooBar() suggests an important free function
• foo_bar() suggests a static "utility" function
• niceVariable suggests an important variable
• nice_variable suggests a "consumable", limited scope variable.

[fiffty-50]

• Directory names: All lowercase with - for word separator if necessary. Eg.directory-of-doom/
  • Agree
• File names: Follow Qts convention but change Q to A. Eg. ADataBase.h
  • I would prefer to keep them all-lowercase. This would be consistent with the directory structure and seems to be the qt convention as well?
    src/directory/all-lower-case/headerfile.h is preferable over
    src/directory/all-lower-case/headerFile.h what the F?
  • Benefit: avoid hassle with case sensitivity differences on *nix/Win
  • keep directory and file level consistent
  • consistent with qt and other naming conventions
• Class names: Like above added A in the beginning. Eg. class ADataBase
  • Agreed, we should also specify that (non-static) methods be camelCased
• Free function names: Follow Qts convention with an extra a. Eg. aConquerTheWorld()
  • Agreed
• Static functions: Without a and snake_case to emphasise limited scope. Eg. void utility_function_one()
  • Agreed
• Limited scope variables: Variables like constructor parameters that are "consumed" should be snake_case.
  • Agreed
• Constants: All capital snake_case. Eg. const auto IMPORTANT_CONSTANT = ASecretOfUniverse(42);
  • Agreed
• Type Aliases: [debatable] Follow Qt quidelines. Eg. using NewType = QMap<QString, int>
  • Agreed

[KotzaBoss]

Ok for headers all lowercase but i assume that for classes we should write the name fully (but lowercase)
For class AFooBarr: afoobar.h

True specify instance methods are normal camelCase.

[fiffty-50]

We should also have a convention for naming custom slots. The ones added by Qt Designer all follow this scheme:

void on_<object name>_<signal name>(<signal parameters>);

This is so that 'QMetaObject::connectSlotsByName' can connect the signals with their respective slots automatically. For custom slots, in order to avoid errors around "connect slots by name no matching signals found" etc., I would suggest naming custom slots similar to the convention above, but without the initial underscore, like so:
void on<object name>_<signal name>(<signal parameters>);

For example:

'Qt' slots:
void on_pushButton_clicked();
void on_lineEdit_editingFinished();
'custom slots'
void onADataBase_updated();
void onCustomSlot_triggered();

[KotzaBoss]

ah i see. but still its better to not have underscores at all
onSomething_Signaled() triggers my equilibrium ocd xD
onSomethingSignaled() seems like a safer bet

[fiffty-50]

Let's see if we can maintain ocd equilibrium, here's my pitch: ;)

I see 3 key advantages for using the underscore between objectname and signal name:

1. Consistency with Qt Convention

2. removing the underscore changes the signal's capitalization, keeping it maintains it:

   signal	slot
   customSignal();	onObjectCustomSignal();
   customSignal();	onObject_customSignal();

3. Having an underscore differentiates a slot from a method and clearly identifies a signal in a name

   For example
   onWhereIsTheSignalForThisSlot();
   onALongerObjectNameTriggeredBySomething();
   ----
   onALongerObjectName_triggeredBySomething();
   onSignalDistinguishableBy_underScore();

For example:

class CustomClass : public QObject
{
    Q_OBJECT
public:
    explicit CustomClass(QObject *parent = nullptr);
    void emitCustomSignal(QString&);
    void doStuff();
    void doSomeMoreStuff();
    void doALotOfStuff();

signals:
    void customSignal(const QString&);
    void someOtherCustomSignal();
    
private slots:
    
    void onCustomObjectCustomSignal(); // here custom signal has a different name than the signal, customSignal vs. CustomSignal
    void onSomeOtherCustomObjectSomOtherCustomSignal(); // same as above, but what's the signal, what's the slot?
    void overHereWeHaveSomeFunction(); // what differentiates the function from a slot?
    // comparison with 'Qt' Slots, these look more like methods than like slots
    void on_QObject_QSignal();
    void on_lineEdit_editingFinished();
    void on_pushButton_clicked();
    // compared with 'Qt' Slots, these are still visible as slots, but also distinguishable from the 'inhouse' ones.
    void onCustomObject_customSignal(); //customSignal has its proper name
    void onSomeOtherCustomObject_someOtherCustomSignal(); // even for longer names, the underscore clarifies what's the signal and what's the slot
    
};
'''

[KotzaBoss]

Οκ i see your point and i agree on the underscore. Though the class seems abit paranoid.
why is there a method called emitCustomSignal? Am i to assume that it looks like this?:

void emitCustomSignal(QString& x)
{
    emit customSignal(x);
}

Also i still am apprehensive about having internal emission of, and reaction to, signals. I dont see the reason to have the emission overhead when a simple function may do. The events we are dealling with dont really need anything more than a function call.

[fiffty-50]

Yes, it was just a quick and dirty example to demonstrate the behaviour of QMetaObject::connctSlotsByName, nothing I am actually planning on using.

If we can avoid using slots and call a function instead, I agree we should aim to do it. On the other hand, signals and slots are a core feature of Qt and avoiding or not using them would be a waste in my opinion. There are a scenarios where they are great, and some others where calling a function is more appropriate. Let's decide on a case-by-case basis and cross that bridge when we get there.

[KotzaBoss]

I never said avoid signals all together. I am specific.
Signals from a dialog for that dialog can be avoided with a simple func call.
Primarily we want to emit a signal so that others can react to it.

[fiffty-50]

Suggestion for formatting text displayed to the user, for example in Message Boxes, labels etc:

Qt supports different text formatting standards. Of those, I would prefer to use one that supports text formatting like this, so that would eliminate Qt::PlainText, leaving us with either markdown or rich text with HTML4 markup. I would like to use markdown, but seeing it is only supported from Qt 5.14 and considering that even major distros are still using Qt 5.12 I think it would be better to stick with rich text and the supported HTML4 markup for now.

Long story short, prefer "Hello,<br>User!" over "Hello,\nUser"

What's your take?

[KotzaBoss]

Ill just follow this for the future but its too low in priority atm i think. Getting the standard use of the program working is priority one. Making the error messages from plain text to html markup way bellow that.

Suggestion:
Write all the messages in the comfortable plain text for now. Focuse on using Qts rich formated text later.
Qt already has things like that covered.