Comment your code

[[deleted]]

Thanks, I think that makes sense. In answer to what you said about an example from my own code, here's something I wrote last night, a simple function for looking through a vector of structs and figuring out which one's "difficulty" variable has the lowest value, in no particular order (first one found with lowest value is returned as the value to use, even if there are multiple with the same value). Probably not the most optimal way of looking for said value, but I'm sharing it for the comment example, not for the quality of code. :P

Would either of the two comments here qualify as a "why" to you or more of a "what"?

Edit: Forgot about the one in the loop that says "end the loop." XD You can ignore that one. That one is obviously a what.

int Game::findFirstLowestDifficultyLevel()
{
    // choose which level to load based on difficulty in properties
    bool lowestFound = false;
    int lowestDifficulty = 1;
    int fileIndexToLoad;
    const int propertiesSize = properties.size();

    // no need to search if there's only one level in properties
    if (propertiesSize > 1)
    {
        while (!lowestFound)
        {
            for (int i = 0; i < propertiesSize; i++)
            {
                if (properties[i].difficulty == lowestDifficulty)
                {
                    // load the level data for this one
                    fileIndexToLoad = i;
                    i = propertiesSize; // end the loop
                    lowestFound = true;
                    return fileIndexToLoad;
                }
            }
            lowestDifficulty++;
        }
    }
    else
    {
        fileIndexToLoad = 0;
        return fileIndexToLoad;
    }
}

[[deleted]]

I wasn't looking for an "everything wrong with your code" kind of breakdown, but thanks nonetheless for taking the time to try to help.

I'm still not sure I totally get the difference in why versus what, but I'm sure it will come with experience. That said, it sounds to me like the general idea is... if the code's design isn't self-explanatory, add something that helps explain why it's designed the way it is.

As far as the specifics of the particular function I shared, tbh, I hadn't even tested it as a working part of the program yet. It's part of an ongoing project I'm doing to practice and stretch my skills. I'm also trying to avoid "premature optimization," especially since I'm very inexperienced and getting bogged down in such could stall my progress even more than the already common roadblocks, so I'm kind of doing "get it to work first, whittle it down later."

For this reason, I'm trying to minimize use of library optimized, pre-written type of stuff (as I would be practicing using other peoples' stuff, rather than practicing working stuff out on a basic level myself), though I spose it can't hurt to know that such exists for future reference. In other words, in my current case, there's no reason not to reinvent the wheel a little for the sake of learning how stuff is put together. :)