Thank You

Thank you for showing interest in contributing to HDRMerge. It is people such as yourself who make this program and project possible.

Contributing as a Programmer

Announce and discuss your plans in GitHub before starting work.
Work in a new branch. Fork if necessary.
Keep branches small.
Prefer templates and constexpr variables over macros. Avoid macros as much as possible (e.g. use #pragma once instead of traditional include guards).
Use C++11.

The naming isn't homogeneous throughout the code but here is a rough guideline:

Identifiers (variables, functions, methods, keys, enums, etc.) should be clear and unambiguous. Make them as long as necessary to ensure that your code is understandable to others and to your future self.
Types (classes, structs, enums, typedefs...) should be named with UpperCamelCase.
Functions and methods should be named with lowerCamelCase.
Variables should be named with lower_underscores to avoid conflicts.
Enum values should be named with UPPER_UNDERSCORES.
Add comments when needed. Not too little but not too much. Try to be reasonable and keep a good balance.
Give an overview of the code block/algorithm. If the identifiers are clearly describing the intent, single lines don't need to be commented.
Be consistent, even when not sticking to the rules.

Don't shy away from refactoring code, it helps more than you think.

Change the naming and add comments when they don't match with the guidelines above.
C++11 gives many opportunities to simplify code (e.g. default initializing with = {} or default returning with return {};).
When using auto think a bit about the reviewers reading diffs and guessing types. It's a double-edged sword.
Help the compiler and reviewers by using const as default for almost anything.
Reduce scopes. This also means moving private functions with little or no dependency to this to an anonymous namespace inside the implementation.
Try to separate "code refactoring" commits from actual functionality changes.