Coding Standard

[maksym-gryb]

There is very little coding standard in between the Dwarf Therapist sources, since multiple people worked on it "separately" without agreeing to a single coding standard beforehand.
It would behoove of us to create one and so I shall (for the C++ at least).; as well as remodel the old code to the new standard.

[OdellDotson]

What standards are you intending to implement?

[Hello71]

it would be nice to even just have "conventions", e.g. if (cond) vs if(cond), f(a,b,c) vs f (a,b,c) vs f (a, b, c) vs f(a, b, c).

[maksym-gryb]

I was thinking of something similar to what they have in the google code standard for C++: https://google.github.io/styleguide/cppguide.html
Basically so that things would be more easily readable through multiple different source files and more easily maintainable.
Basically naming conventions, character lining - like what @Hello71 was talking about or like having equal signs dictating spacing:
int potato = tasty
int muffin = good
int dwarf = smelly ok so in this case the "=" signs should be aligned, but it's not letting me do this here :P.
That kind of stuff. What do you guys think?

[epsilon-phase]

I'm not the biggest fan of the spaces between the parenthesis and the function or keywords. In my opinion, it makes more sense to focus on naming conventions.

I like snake case, you know something like

int potato_count = 0;

Of course, I think that classes should be upper case, and their methods, if they are more than one word, should be in snake case.

class Window{
   int get_width()const;
};

Though, given that this is written with Qt, I would rescind that recommendation and suggest that we follow the Qt naming conventions, so that would look like

class Window{
   int getWidth()const;
};

so you don't have to switch gears when you are writing code using the preexisting Qt classes and the ones that are written for Dwarf Therapist.

[OdellDotson]

I personally prefer

class Window {

as opposed to

class Window{

If the no spaces is a Qt convention though then I agree with you.

[maksym-gryb]

I agree entirely with you @jaked122 , the naming conventions should be the primary concern at the time being.
I was thinking of these few things - though some have been mentionned, I'm listing them for clarity's sake:

class Window{
    public:
        Window();
        ~Window();

        int init();
        int setupPotatoDisplay();

    private:
        int m_potato_count;
}

The header files would look something like the above. We should stick to the basic Qt conventions like the functionDeclarationConvention() and the class spacing.
Also, a m_ at the beginning of a variable, represents that it's an instance variable and not a local variable (using this since this is already in practice in some code I've seen in DT and it clarifies pretty decently what the variable belongs to).
Snake case variable declarations.
etc.

[epsilon-phase]

@maksym-gryb Yep, it makes it a lot more convenient, doesn't it? Personally I don't usually put a m_ before my private member variables, but it does provide a fairly unambiguous statement of how the variables are meant to not be used outside the class.

@OdellDotson Well, that's not actually terribly relevant to us when we work with Qt's conventions (so far as I know), but I prefer to keep the brackets next to the name, as I see them as a sort of punctuation, and for the most part, punctuation is not separated from the word that proceeds it. It looks an awful lot like this int c = 1 ; to me.

Isn't that horrible looking?

Besides, we should be able to make an astyle configuration that will enforce whatever style that we wish to use.

[MorganRodgers]

Some of this such as spacing and indentation can be automated/enforced with clang-format. Although that does introduce additional dependencies (they're easy enough for OSX and Linux users), I've found it makes working on projects that have had many authors over a long period of time much easier to read. My 2¢.