2) How to keep proper backups? Should I manually save them on my Computer (in ZIPs, ..)?

I have 2 hard disks in my computer, one for use, and one for backup. This doesn't protect against theft or fire but in that case I have bigger problems than a few lost copies of open source repositories

3) How to provide a documentation for my software?

There are many different options that I found, but what would you recommend? Is there an industry standard?

I use Doxygen for C++ to document the code. I do that near implementations, so code and documentation is always together.

I found it the best solution to increase the chance that both get updated.

If I either don't understand code or documentation, the first thing I do is fix that. I don't want to decode anything more than once. Too much risk making stupid mistakes.

Edit:

I also build the documentation regularly. Not so much for use, but for checking the generated warnings about missing/wrong docs

It might be informative to look at the naming conventions used in the standard library (defined through an ISO standards document)

This. A thousand times this.

Why is it that so many C++ programmers choose a Java style and (often) also throw out any and all uses of the standard library...

I would not use the C++ standard library coding style as the definite coding style for C++. It's not that simple.

Stroustroup, for example, recommends to capitalize the first letter of your class names to distinguish them from the standard library names, which is not what the C++ standard library does. He also recommends using UPPER_CASE for macro names (if you can't avoid them in the first place) to emphasize on the fact that they are alien in C++ and do not respect language's grammar, even though standard macros like assert(...) are in lower.

So no I don't think the C++ standard library standard is meant to be a hint of how you should name your things. (Unlike Java which tries to impose the JFC naming on your own code to the point where Eclipse generates compiler warnings if you don't use the prescribed style!) Boost uses lower_case everywhere because its libraries aspire to be part of the C++ standard library so it's different from your game engine.

But by all means, if you like the all_in_lower_case style go ahead and use it! My point is just that the C++ standard library coding style is not necessarily meant to be imported in your code, the way the JFC coding style is meant to be used by all Java programmers.

Hey gamedev.net-community!

Lately I am cleaning up some C++-code (using Visual Studio 2015) and realised that I could improve a lot of things in terms of clarity, archiving/backupping and general software documentation.

I would like to give you a short overview of my questions:

1) What naming conventions to follow? Is this all opinion based? Is there a/an common/industry standard style?

When I worked with Java, there were quite a lot of tips on how to use the Javadoc (Eclipse) and what common naming convections exist.

For C++, I realised there are quite a lot of different opinions (while Java has a major movement - for example camel case - if my observation is correctly).

What naming convention would you recommend? Should I follow the Google: https://google.github.io/styleguide/cppguide.html?

Some say that not everything within this style guide is really that great. Sergey Zubkov even goes so far and calls it a deal-breaker: https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker

2) How to keep proper backups? Should I manually save them on my Computer (in ZIPs, ..)?

Backups are really important of course, I learned that the hard way. However even doing it manually costs time and leaves room for missing in between versions. The reliability of doing it by hand is simply quite low, at least when I perform these tasks.

What kind of software could help me out? Is a service like GitHub appropiated for a one programmer project?

3) How to provide a documentation for my software?

There are many different options that I found, but what would you recommend? Is there an industry standard?

I am well are that some of these questions are depending on personal taste, therefore I am looking for well proven solutions which may be industry standards.

In the end, thanks a lot for taking your time to read through this!

1) A convention is mendatory. But what kind of convention is up to you.

Read here:

https://en.wikipedia.org/wiki/Naming_convention_(programming)#C_and_C.2B.2B

2) GIT. if you don't know how to use it, learn.

https://try.github.io/levels/1/challenges/1

3) Anything that is related to software's architecture, design , code or QA and it's in a document Is a documentation.

There's no standard for this. Mostly I like to describe the design, the purpose of components and how they work with each other because I don't like long documents.

If you feel there's a part in your software that needs explenation, first check if you could improvde the code so it would be understood. If you cannot then write a documentation describing it.

I used to roll with a variant of the Hungarian Notation, but then I realized I live in the future where we have IDEs that show me this stuff and I changed my style to something more easily readable.

On a separate note, though - over time I've fallen in love with namespaces. Converting a function like: ConvertImageFormat() to image::convert_format() is both better encapsulated, less ambiguous, more intuitive and in many cases faster to type with auto-complete. Namespaces disambiguate things so you can keep your names short while you can selectively enable shorthand accessibility to what functionality you need.

For instance my vector class functionality is kept in namespaces like math::vec3_ops::, math::vec2_ops::, etc, which are populated with your usual normalize(), length() etc functions. This forms a clear separation of different types of operations performed on vectors, planes, etc. So the following becomes possible:

namespace math {
   namespace vec3_ops {
      real length(const vec3& v) { ... }
      }

   namespace vec2_ops { 
      real length(const vec2& v) { ... }
      }

   namespace vec  {
      using namespace ::math::vec2_ops;
      using namespace ::math::vec3_ops;
      }
}


void somefunc(const math::vec2& v2, const math::vec3& v3)
{
  real len0 = math::vec::length(v2);
  real len1 = math::vec::length(v3);
}


//Or if I'm using a lot of math functionality and I know I'm not mixing my code with something like GLM,
//I can do:

using namespace math;
using namespace math::vec;

void somefunc(const vec2& v2, const vec3& v3)
{
  real len0 = length(v2);
  real len1 = length(v3);
}

 

Simple. They find className.doSomeThing() more readable than class_name.do_some_thing().
That's it, and it's a perfectly valid reason.

IMO it is the opposite. But to each their own. Personally I think in many cases it was just "inherited" from the Java coding standard, because that was one of the most popular/well known of the codified standards.

Pascal is where I personally attribute the CamelCaseForm of identifiers, and many of the associated capitalization/spelling quirks that go along with it. I'm sure someone with a beardier neck than myself will arrive shortly to correct me about how it goes back even further.