Project Conventions

[silnarm]

Also as a side note: Members are initialized in the order they were declared in the class definition not the order they appear in the member initalization list so it might be good to keep the same ordering to avoid confusion.

GCC throws warnings about this. I'm fixing them every now and then.

These are predominately my fault, these days I actually copy the data decs to the constructor and reformat it into an initialisation list, to ensure I don't introduce more.  None of the existing ones are in anyway dangerous however, none of the initialisations rely on other initialisations, the warnings are a nuisance though, as they could mask problems introduced in the future where there is interdependency.

I have no problem with prefixes like m_* which is quite common (i mostly use this->) but i actually dislike to encode the type in the name in some way. Look up the declaration or use a proper editor.

Yeah, I can't stand Hungarian notation of any sort^[1], that little 'help bubble' doesn't take long to pop up, if you're not sure what type something is, hover the pointer on it!

The m_ thing I never really cared for either, but I would have to agree that having them grouped in the autocomplete list would indeed by very nice, so I'm all for it.

[1] Not entirely true, I've always used 'a version' of it with Gui code, but only for Gui elemenets, btnPlay, lstMaps, etc.

[hailstone]

Is there any reason for using a typedef to hide a pointer (eg typedef StaticImage* Ptr;) ? I think it could create unneeded compile time if the class definitions were to be separated. I suspect the class definition is required to supply the type, therefore, it would not be possible to use forward class declaration to avoid recompilation of dependent header files.

StaticImage needs to be recompiled each time Container.h is modified.

Code: [Select]

#include "Container.h"

StaticImage(Container::Ptr parent);

Whereas the following doesn't. From my understanding anyway.

Code: [Select]

class Container;

StaticImage(Container *parentPtr);


[silnarm]

The reason pointers are frequently typedefed is to make them behave more like types should,

Code: [Select]

Container * a, b;a and b have different types, which is silly

Code: [Select]

typedef Container* ContainerPtr;
ContainerPtr a, b;Same type, both pointers.

Embedding them in the class as a public typedef I only did a few days ago, previously I was doing it as above, which also works with forward decs, I might change it back, but you can always just use regular pointer syntax where you need to. Within the Widget classes this is sometimes necessary, but when using the Widgets from elsewhere, you will have already seen evertything declared, so it's not an issue in the menus/game.

[hailstone]

I'd like to suggest also using a prefix for returning values via a parameter such as out_variable for the same reason as using m_ prefix - makes the scope of the variable you are modifying clearer.

[silnarm]

I toyed with this a bit, I think doing this with all parameters might be a good idea.

I don't like 'in' and 'out' though, each fine on their own, but inout_ is too long for my liking, so how about i_, o_ and io_ ?,

bool doSomething(const int i_param1, int &o_output1);
bool doSomethingElse(Vec2i &io_param1);

[hailstone]

I'm not sure about input variables since I tend to think of them as another local variable; they behave in the same way. If you modify an input parameter it is only modifying it locally. Whereas modifying a pointer or reference parameter has consequences beyond the function (same with member variables). I might need to use it somewhere to see how it is.