-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image stack refactors #188
base: master
Are you sure you want to change the base?
Conversation
-Simple refactor for addImage()
- further small changes
can anyone give this a look :) |
Ping @Floessie @heckflosse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well done! 👍
I'm not bias against CamelCase or under_score notation. But IMO it is better to stick with what is already used, and as far as I can see that's CamelCase here in HdrMerge. Of course it's up to the owner/main devs to decide, but I have mixedFeelings with mixed_notation ;) |
Good point, I personally still like this mixed notation because it adds an extra level of semantic separation between methods and variables which may reduce the ambiguity even a tiny bit. This is just the beginning so it would be nice to decide now before i continue refactoring the rest. If everyone prefers camelCase that's fine by me too, maybe my python background is pulling me towards under_scores for variables but i'm used to both. |
Please don't merge this PR just yet, some time has passed and i totally agree with what you are saying. will strictly use |
I would've liked to have the whole class refactored and then make a PR but I'm thinking if I make frequent PRs it will reduce the possibility of unnecessary merge conflicts.
I come from Python / JS , what I learned from Python is that things should be as clear as possible :).
This is my first attempt at refectory C++ so please throw all your constructive criticism at me now while I haven't formed my preferences and biased opinions on C++ conventions yet.
PR reason: #180