Hello, I'm working on a project that has multiple headers with plenty of code in each file. I've been folding up the code using #pragma region/endregion and then the [-] button so it looks neat and easier to handle. But when I open the solution file again, I'd have to fold up everything again because it discards all the previous folds. Would there be a way to save the folding I have made so I wouldn't have to repeat the process over and over again? Thank you.
No. I don't know of any editors that remember folds across restarts. Do you really have so much code in a single file or function that this is an issue? In general, functions should be relatively small (typically able to fully fit on your screen).
Well there's this one file that has over 2000 lines of code with multiple functions that perform several different tasks which I don't really need to look at all the time when I'm adding something new. It's just neat to keep different parts of code minimized and concise that way I can concentrate better on what I have to do left but that's alright I guess, thank you. :)
Well there's this one file that has over 2000 lines of code with multiple functions that perform several different tasks which I don't really need to look at all the time when I'm adding something new.
Then why not have multiple files that contain some of these functions? A file that has over 2000 lines is much much too long.
Then why not have multiple files that contain some of these functions? A file that has over 2000 lines is much much too long.
Because these functions belong in that specific file and ideally close to each other. But I might be able to break few pieces apart and reduce the amount.
Because these functions belong in that specific file and ideally close to each other.
Why?
What does closeness matter? Remember if you wanted you could have many .cpp files that contain only one function.
You really should be striving for readability, and functions larger than 100 or so lines of code are starting to become unreadable. Normally your functions should be small, one to twenty lines of code (something that will fit on your computer screen without scrolling) and your functions should be less than two printed pages, if possible.
I agree. But for me it's not so much the length that makes a good method implementation. Some functions require quite substantial amount of code for them to work properly. I like to keep functions that perform related tasks close to each other (ideally in the same file) so that I wouldn't have to jump from one file to another if something needs tweaking.
Some functions require quite substantial amount of code for them to work properly.
While it is true that a rare function may require a substantial amount of code, large functions usually indicate that the function is doing too much. Functions should do the minimal amount of work, but do that work extremely well. It is much easier to test the functionality of small functions than it is to test large functions. Small well tested functions that can be reused should be your building blocks to solid reliable programs.
I like to keep functions that perform related tasks close to each other (ideally in the same file) so that I wouldn't have to jump from one file to another if something needs tweaking.
Keeping related functions in the same class is usually a good practice, however with today's operating systems that allow multiple files to be open simultaneously it should not necessarily be the overriding factor, remember you can group files that contain functions that do related tasks into directories. These directories with multiple files could then be compiled into libraries containing related functions. Also your functions should be defined to be independent of other functions whenever possible. If you must modify multiple functions when fixing a single bug, or when adding a single new feature, that is usually a good sign that the functions are doing too much and are too interrelated.