Timeline for Character classes and character creation for an RPG (early prototype)
Current License: CC BY-SA 3.0
12 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 26, 2017 at 8:46 | comment | added | anon |
I'm refactoring my code right now and a new question came up. On the topic of unsigned int s, should I use them for variables that are getting range-checked and appropriately corrected anyways, just for transparency? I'm kind of scared of overlooking some silent conversion of a negative number into an unsigned int when using them too loosely.
|
|
Jul 25, 2017 at 14:44 | comment | added | corsiKa | "most developers agree that more whitespace is better than less." At the very least, most developers would agree that these walls of text need more whitespace. | |
Jul 25, 2017 at 14:23 | vote | accept | CommunityBot | ||
Jul 25, 2017 at 14:23 | vote | accept | CommunityBot | ||
Jul 25, 2017 at 14:23 | |||||
Jul 24, 2017 at 19:17 | comment | added | Ben Steffan | @TrveBlack In general, using screen space well is not much of an issue. Actually, you cannot parse code fast enough to be able to just scroll through it and have read and understood everything. Instead, having each statement on its own line and statements that belong together grouped together vertically immensely helps readers to understand the structure of your code. The horizontal space advantage you get could be used for having another file open for reference, or a browser tab with important information etc. | |
Jul 24, 2017 at 19:14 | comment | added | anon | Excuse me, but I forgot to ask one more question: Strongly recommended 2) I do totally agree that splitting the content of tightly packed lines over more lines increases the legibility a lot. However, my fear is, that by shortening my code in the "horizontal" dimension and enlarging it in the "vertical" dimension, 1.) I make it harder to get an overview of the full code and 2.) I use only 20% of my monitor horizontal size and spend way more time scrolling up and down. Do you have some recommendations on keeping a balance between these two? Or maybe a resource where such gets addressed. | |
Jul 24, 2017 at 19:04 | comment | added | Delioth |
@TrveBlack more on Strongly Rec 7) That many parameters makes code unreadable. If you need that many, you likely need a struct or similar to bundle them up. That many parameters means the function is probably doing too much and should be broken into either more functions or a more generic function.
|
|
Jul 24, 2017 at 19:03 | comment | added | Ben Steffan |
@TrveBlack I choose the example a little badly. What I meant to lay the focus on is that int does not explain your intent very well (assuming that you want to say "Please input a number between 0 and INT_MAX"). Not doing anything on negative input is not that much of an issue, but it might be confusing to users (a "Please try again" message would solve this).
|
|
Jul 24, 2017 at 19:00 | comment | added | anon |
And one last question: - Recommended 2) how does making numghouls an unsigned int improve the handling of negative user input? In the current implementation, negative user input has the same effect as inputting "0", which is somewhat what I intended.
|
|
Jul 24, 2017 at 18:58 | comment | added | Ben Steffan | @TrveBlack Stringly recom. 3): Usually, having the name be self-explanatory is preferred. Only if the name would become ridiculously long are comments also ok. Strongly rec. 7): No. The names are part of the issue, but not everything. Please read the link to the c++ core guidelines. Rec. 1): Because that is why we have loops with conditions in their head. This makes it easier for compilers to reason about termination and also makes it easier for readers to see what a loop actually does. | |
Jul 24, 2017 at 18:52 | comment | added | anon | Thanks for the effort put into this answer. I will try to rework the code according to your recommendations. However, I have some questions: - Strongly recommended 3) Is it acceptable to explain their meanings in a comment where they are declared? Or does it need to be obvious what they mean, wherever you stumble upon them? - Strongly recommended 7) I only now realize that it is not forbidden to give function parameter names in their declaration...would the same snippet of code be acceptable if there were selfexplanatory names? - Recommended 1) Why is the latter preferrable? | |
Jul 24, 2017 at 17:00 | history | answered | Ben Steffan | CC BY-SA 3.0 |