I was (and still am) having a hard time figuring out the overall structure of the project and how the components interact with each other. One issue is variables (naming, meaning). I'm aware that variable naming is hard and everyone has their own opinion about the topic. It's explicitly NOT my intention to judge people for the choices they made regarding that topic in the past.
Nevertheless I think the project will benefit (improve code quality) from following a few simple rules/conventions and thus making life for contributors a bit easier.
Plan
I would like to begin with NumberPost as it's one of the fundamental structs used throughout the code in a lot of places.
Ask yourself:
"What does the name of that struct actually tell about it's contents or purpose?"
This PR adds comments to each line and makes a suggestions how that variable could be named and includes some explanation what it means or what it's used for. The actual renaming could follow (simple search-and-replace) when each definition is agreed on.
Also, a set of rules (camelCase or snake_case) could be defined that everyone should follow when adding new code or refactoring existing code.
Background, Motivation
I was (and still am) having a hard time figuring out the overall structure of the project and how the components interact with each other. One issue is variables (naming, meaning). I'm aware that variable naming is hard and everyone has their own opinion about the topic. It's explicitly NOT my intention to judge people for the choices they made regarding that topic in the past.
Nevertheless I think the project will benefit (improve code quality) from following a few simple rules/conventions and thus making life for contributors a bit easier.
Plan
I would like to begin with
NumberPost
as it's one of the fundamental structs used throughout the code in a lot of places.Ask yourself:
This PR adds comments to each line and makes a suggestions how that variable could be named and includes some explanation what it means or what it's used for. The actual renaming could follow (simple search-and-replace) when each definition is agreed on.
Also, a set of rules (camelCase or snake_case) could be defined that everyone should follow when adding new code or refactoring existing code.
References