Another question on "Good Practices" involving code file size...
-
My application has a main window that provides most of the functionality. The window itself is nice and clean, and very user friendly IMO. However, the class CPP file for it is growing large and hard to navigate (I have to use Ctrl+F to find most functions). The reason for this is there are a lot of possible interactions the user can have with the interface, each having a unique function. The .cpp file is currently 24kb (845 lines including whitespace); which is a lot for me, I usually don't write large programs. I want to try to keep the code organized, and I'd like to know some good practices for doing this. (If I become a programmer as a job, I want to know how to make the code "presentable" and not just a mess.) Is it just a matter of trying to keep the functions sorted in groups (i.e. everything having to do with interaction of the list control together, then everything with the media player together, etc.. etc..) Or is there more that I can do to try to keep it organized? Lastly, Visual Studio 2008 defaults to making wizard generated message handlers public. I would think that they should be protected in most cases. Is there a convention here that I'm not aware of, or should I indeed move the ones that other classes shouldn't be calling to protected? Thanks again for any info!
-
My application has a main window that provides most of the functionality. The window itself is nice and clean, and very user friendly IMO. However, the class CPP file for it is growing large and hard to navigate (I have to use Ctrl+F to find most functions). The reason for this is there are a lot of possible interactions the user can have with the interface, each having a unique function. The .cpp file is currently 24kb (845 lines including whitespace); which is a lot for me, I usually don't write large programs. I want to try to keep the code organized, and I'd like to know some good practices for doing this. (If I become a programmer as a job, I want to know how to make the code "presentable" and not just a mess.) Is it just a matter of trying to keep the functions sorted in groups (i.e. everything having to do with interaction of the list control together, then everything with the media player together, etc.. etc..) Or is there more that I can do to try to keep it organized? Lastly, Visual Studio 2008 defaults to making wizard generated message handlers public. I would think that they should be protected in most cases. Is there a convention here that I'm not aware of, or should I indeed move the ones that other classes shouldn't be calling to protected? Thanks again for any info!
Well, one way you could organize your code is by separating out functionality into different classes. There are many ways to "break it up", but just separating out your business or application logic from the UI might be a good starting point.
- S 50 cups of coffee and you know it's on!
-
My application has a main window that provides most of the functionality. The window itself is nice and clean, and very user friendly IMO. However, the class CPP file for it is growing large and hard to navigate (I have to use Ctrl+F to find most functions). The reason for this is there are a lot of possible interactions the user can have with the interface, each having a unique function. The .cpp file is currently 24kb (845 lines including whitespace); which is a lot for me, I usually don't write large programs. I want to try to keep the code organized, and I'd like to know some good practices for doing this. (If I become a programmer as a job, I want to know how to make the code "presentable" and not just a mess.) Is it just a matter of trying to keep the functions sorted in groups (i.e. everything having to do with interaction of the list control together, then everything with the media player together, etc.. etc..) Or is there more that I can do to try to keep it organized? Lastly, Visual Studio 2008 defaults to making wizard generated message handlers public. I would think that they should be protected in most cases. Is there a convention here that I'm not aware of, or should I indeed move the ones that other classes shouldn't be calling to protected? Thanks again for any info!
Well, 845 lines is not so much, my last programm was about 15000 (all together). I like to separate functionalities a lot. Like a module/class to save datas, another for mathematical functions, another for GUI functions, another for "various" functions and so on. But at the end, the only one that can make it right, is you. Because every programm is different and is a bit difficult to say something "standard"
x87Bliss wrote:
i.e. everything having to do with interaction of the list control together, then everything with the media player together, etc.. etc..)
Of course making groups regarding functionalities is a great idea, but it may be a project where another aproach is better.
Greetings. -------- M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you “The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
-
Well, 845 lines is not so much, my last programm was about 15000 (all together). I like to separate functionalities a lot. Like a module/class to save datas, another for mathematical functions, another for GUI functions, another for "various" functions and so on. But at the end, the only one that can make it right, is you. Because every programm is different and is a bit difficult to say something "standard"
x87Bliss wrote:
i.e. everything having to do with interaction of the list control together, then everything with the media player together, etc.. etc..)
Of course making groups regarding functionalities is a great idea, but it may be a project where another aproach is better.
Greetings. -------- M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you “The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Besides just making classes for specific functionality, I also decided to start using '#pragma region' directives; so I can collapse groups of functions together. It's been very useful. I barely know anything about pragma statements. In my case I don't have to worry about it, since I will be using Visual Studio always to compile this. I am just wondering what would happen if a different compiler saw '#pragma region' if it'd skip over it, or have an error?
-
Besides just making classes for specific functionality, I also decided to start using '#pragma region' directives; so I can collapse groups of functions together. It's been very useful. I barely know anything about pragma statements. In my case I don't have to worry about it, since I will be using Visual Studio always to compile this. I am just wondering what would happen if a different compiler saw '#pragma region' if it'd skip over it, or have an error?
x87Bliss wrote:
I am just wondering what would happen if a different compiler saw '#pragma region' if it'd skip over it, or have an error?
"If the compiler finds a pragma it does not recognize, it issues a warning, but compilation continues" from msdn or something like, #if _MSC_VER > version #pragma region Region_1 #endif
x87Bliss wrote:
the class CPP file for it is growing large and hard to navigate (I have to use Ctrl+F to find most functions).
845 is not so lengthy, you can learn some shortcuts to speed up search. for instance you can use indexed search (ctrl + i) and type to search while typing. and to navigate to class and member in a file, the code view has scope and member field or class view you can select to navigate to the function, F12 a handy shortcut to navigate to the definition from its reference... You may redesign the GUI into different layouts or split GUI into pages if you have tomany controls that will be annoying the user. If your GUI is neat, may be you group range of event handlers that is handled in different class implemented in different files like ON_CONTROL_RANGE, ON_COMMAND_RANGE, ...
-
x87Bliss wrote:
I am just wondering what would happen if a different compiler saw '#pragma region' if it'd skip over it, or have an error?
"If the compiler finds a pragma it does not recognize, it issues a warning, but compilation continues" from msdn or something like, #if _MSC_VER > version #pragma region Region_1 #endif
x87Bliss wrote:
the class CPP file for it is growing large and hard to navigate (I have to use Ctrl+F to find most functions).
845 is not so lengthy, you can learn some shortcuts to speed up search. for instance you can use indexed search (ctrl + i) and type to search while typing. and to navigate to class and member in a file, the code view has scope and member field or class view you can select to navigate to the function, F12 a handy shortcut to navigate to the definition from its reference... You may redesign the GUI into different layouts or split GUI into pages if you have tomany controls that will be annoying the user. If your GUI is neat, may be you group range of event handlers that is handled in different class implemented in different files like ON_CONTROL_RANGE, ON_COMMAND_RANGE, ...
