Are there limits or performance penalties on the amount of code inside of my home.cs form?
I am writing a database application front-end in C# in Visual Studio 2008. The way things are lining up, I am using a tab-page way of changing the info shown to the end users, instead of using new forms.
Coming from VBA/MS Access, I remember that if you go over a certain number of lines of code, it would produce an error and not compile. Will C# do this in Visual Studio 2008, or will I suffer a performance hit? I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations.
It's not the lines of code in your .cs files that you need to be worried about with regards to performance - it's the number of controls on your form at runtime that might cause problems. If it's just a few controls on a few tabs, you will have no problems. If it's hundreds of controls on lots of tabs, you may have performance problems (not to mention usability problems - I personally hate tab controls with more than one row of tabs).
Also, I don't think tabs are appropriate if the purpose of the UI is more wizard-like where you want the user to interact with all of the tabs in succession. Tabs are meant for presenting sets of options to the user, without requiring them to see all the options at once.
Finally, if the purpose of each tab is significantly different, I find that it's easier to encapsulate each bit of functionality as a separate form. With tabs, you could at least encapsulate each bit as usercontrols, and then have each tab on your form host one instance of a usercontrol.
The only problem i would foresee is that in the future its going to be very hard to maintain.
Try break the logic of that main form up as much as possible into classes so that when you need add something you can actually do it without having a fit.
If you are using tabs, you can still create custom user controls that will hold the content that goes in the tabs. Make a control per tab, and then you can keep your code for the different tabs separate. There is a walk-through on MSDN here.
In response to your comment above, about not showing the tabs, I would really re-think how you're approaching this. Why not simply have all of your user controls sitting on your main form, in a Panel if necessary, have them all set to Dock = DockStyle.Fill, and then change the Visible and Enabled properties based on which one you want to show? You may be making this harder on yourself than it needs to be.
More responses to comments - You may be looking for something like the CardLayout in Java. The source for the GNU Classpath version can be found here, it might give you some ideas on how to implement this.
"I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations."
In my experience, this attitude will ultimately leave anyone who has to maintain your code in the future with quite a headache, as it's an accepted practice to modularize your code so that the pieces that may change or the ones that serve distinctly different purposes are separated away from each other.
With that said, I don't think there is a limit imposed by VS on the length of your files, but I think you will run into some seriously frustrating performance degradation as your files become longer, especially while switching between design and code views.
I would urge you to save your future self and his/her sanity and break your code up logically into separate files. You'll thank yourself later!
It shouldn't be a problem.
Just keep good coding practices in mind and modularise your code for readability and maintainability.
On the other hand, if you put too many controls on your form, then it will probably take longer to load. Factor that into your design if you want a snappy interface.
Sounds horrible but I don't see any reason why it would be a problem.
I have a form that in inherited with my new job that had over 30,000 Lines. It is completely cancerous. Please think before you code and modularize!
Related
This is an issue of code management that I've run into several times. Say I've got a winforms application, and there is a lot of content - hundreds of controls worth of content, most of which have an attached event handler and method. When looking for recommendations on how to separate out such a large file, the 2 big ones that come to mind are regions & partial classes. However, these are both damned by almost every top answer out there.
So I'm wondering, what is the best practice for separating out something like this? It wouldn't make sense to separate them into new classes as they're simply control event handlers. Regions are nice but can still be extremely messy with so much code. I'm kind of at a loss, I can't figure out how to apply the SRP here and any recommendation I see seems to be considered bad practice.
The 'proper' way would be to split the form up into user controls.
Partial classes are meant to separate generated code from user code and regions are just layout (and useless in my opinion, but that is just an opinion)
Splitting the window in user controls promotes proper encapsulation and re-use.
Depending on the project, it might be too expensive to clean it up but splitting out couple of easy ones might help the readability and might save you some time when debugging. Also, when adding new controls and logic, consider adding user controls and start the process of splitting up that way. The cost will then be spread over a longer period and will only be paid for part that you actually use and need to be readable.
I'm basically having the same problem as this guy. The thing is, I want there to be a certain number of rectangles on the screen, depending on the screen size/resolution. Now the first comment on that question says "creating UI elements in procedural code in XAML-based technologies is discouraged, cumbersome, probably a bad idea, and just plain wrong".
So is there another way in which I can achieve my goal?
One way I can think of would be to have a minimum of 3x3 rectangles, but add UI code for 6x3 and make the last 3 rows visibility collapsed. In app load, I could figure out if I could fit more rows, and selectively make them visible. I'd still like to know if there is a cleaner approach.
I won't paste my code here since it's very similar to the linked question, but I will if asked, and it helps to clarify things a bit.
I understand the general sentiment that a XAML app should declare as much of the UI as possible in the XAML. But I also believe it's possible to be too dogmatic about things. If one genuinely has a scenario where the layout of UI elements one would otherwise select during design-time is unknown until run-time, then why not populate the UI at run-time based on that information?
Barring some clearly-written and compelling argument detailing why run-time creation of UI elements is actually bad, I'm going to keep on doing it when appropriate. I will happily design as much of the UI in advance, but if there are parts that depend on information known only at run-time, I will write code to do that.
A person can wind up with a lot of really awful code and maintenance hassles trying to shoe-horn a specific design goal into some constrictive, prescriptive dogma.
I went ahead and posted an answer to the question you've linked to. I don't know if that's actually something you needed, but if so you can look there. It seems to me that the main question here is "is it really so wrong to configure my UI at run-time?" and my answer to that is, as you can see, "no, not necessarily".
I've got an ASP.NET web application, that is essentially our intranet site. I made a lot of progress on the administration office's employee management pages. It ties into an SQL server database, and I'm using a three layered design (Objects, Logic, DataAccess). It was all reviewed and all of it was accepted, except! for the part that manages vacations and vacation histories.
My question, before I go into details is, how does one efficiently "untangle" code that is no longer necessary?
For example: previously I was treating each VacationDay as it's own entity with it's own history. Such that I could track the history of an individual day. To help in tracking, I have an enum called VacationDayAction, which includes options such as .Submitted, .RequestDenied, .CancellationRequested, and so on. This was in an attempt to provide meticulous detail for each day. It was then determined that we no longer need that. We do, however, still need VacationDays and all the basic functions of that (saving days, getting days, etc.), but now we no longer need any of the "history" related classes.
My problem is, when I right click a class that I no longer need in VS and go to "Show All References," I get a ton of results scattered across several pages. I need to get rid of all of them, without breaking the rest of the application. Is there not some kind of "smart" technique or method for easily untangling parts that are no longer necessary? This is particularly difficult because 90% of what I did was just fine, and needs to stay like it is. Yet scattered in that 90% is 10% of stuff that is no longer needed. I can't just go storming through with the delete key either, because with the removal of each reference, I need to be sure that any dependencies on that reference are also fixed in a way that they don't call stuff that isn't there anymore. And I still need the application is a compilable state, so that I can test along the way that the rest of the application didn't fall apart as a result of some deletion.
To give you an idea of my low level of experience, I started two years ago with having never used C#, ASP.Net, or Visual Studio. It blew my mind when, way after starting and as I was learning, someone taught me that I could use breakpoints. And then it really really blew my mind when I learned about multi-layered design. I'm wondering if there is not some technique or trick or feature that can help in scenarios like this, where you have to "untangle" and throw away unnecessary stuff.
This is not a simple question. In fact, I would say this is one of the major challenges for any systems developer; how to handle and get rid of old code which is not in use. There is lots of literature on this, and few really excellent answers. A good book may be "Working effectively with legacy code" by Michael Feathers, which deals with many related problems. It is no light read though, and will probably take some time to get through, but it will likely help you become a better coder, and better at these kinds of tasks in particular.
Maybe you can have a look at the Resharper tool? ( http://www.jetbrains.com/resharper/ ) It is a productivity tool which among other things shows "dead" code (unused code) in grey, and lets you remove it. It will also help you remove unused references from each class (again, they will be grayed out and let you remove them automatically).
Drawing diagrams where each major piece of code /component is a box with a line linking it to any related component might help you get a better overview; try to draw a hierarchy showing how different parts of the code are related and dependent.
The bottom line as far as I know, is that you just have to muddle through it, commenting out code a little at a time, then recompiling and testing it. If it still works, fine, now you can remove the commented out code completely. This would be easier if you had unit-tests covering your code, but I take it as a given that you don't, as is unfortunately often the case.
I just had a conversation with my manager relating to checkin\out policies on a project I'm currently working on. Basically I tried to edit a file that was already checked out by another developer and I couldn't - I asked my manager why we couldn't edit the same class at the same time and he gave this reason for turning that functionality off: We had a lot of problems with developers editing the same Form (or anything visual done in the designer) and then cheking it in. Merging the changes in the designer generated code was a lot of hassle...
As I'm writing this I'm struggling to see what problem they were having - surely they were getting the latest code before trying to check something in??
Have any of you come across problems with editing the same Form (or something in the designer) as another developer and then checking into TFS? If so how did your team get around the problem? Did you also turn off the ability for developers to work on the same class?
EDIT: The following post (found here) is exactly the problem my manager was describing. Anyone know of a simpler way to resolve the issue than the ones in that post?
I would argue that the solution to your problem would be to establish best practices for source code modification.
Discourage people from going into UI code and arbitrarily jiggling the components around in the designer. Any reasonable UI modifications should be easily mergeable. Your best bet is to try and educate people as to the best way to merge in any given source control system. Also, as helpful as the designer is, ignorance of what code is being automatically generated in the background will be significantly detrimental in the long-term.
People who insist on locking checked-out files for the reasons you stated in your post typically wait long periods of time to check their code in. Naturally, the more time passes, the more code gets modified, so it makes merging difficult for these people. Checking in early, often, and incrementally requires people to think about their changes in stages, and for some coders, this is a rather painful cultural/psychological adjustment.
I've just checked back through the histories of some of my .designer.cs files and I can't see any changes that would cause a merge problems. There were no wholesale rearrangements of code for example.
Another thing to consider is to make sure that everyone does a "get latest" at regular intervals then any individual merge/resolution isn't going to be that great thus minimising the chances of anything going wrong.
It might also be worth investigating a 3rd party merge tool. There are plenty around.
Now it could be that the changes I've done are simple compared to the ones you've got so you should take my anecdotal data with a pinch of salt.
It can cause problems (in general) when a lot of people are editing UI concurrently. The merge logic will do a fine job merging things, but in a lot of cases the UI is drawn according to how things are added to the form. Your UI can get messed up quickly.
I don't know if I would use this as an excuse to enforce exclusive checkouts across the board, though. I might go from a (non programmatic) policy standpoint that says shared checkout for business logic, but exclusive for UI changes.
I would couple that with a strong MVP, MVC, or MVVM approach, though, which should limit the number of people that have to touch the UI concurrently.
As others have alluded to, keep one of the seminal rules of SCM in mind: merge early and often, and your problems are reduced. (along with that is "always get latest before you start working on the code).
I'm trying to debug portions of the current application I'm working on, however when I try and check the value of a property/variable I get the error:
Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.
This is just a regular ASP.NET project. In some portions of the application I can view the properties and variables perfectly fine. I haven't figured out what's different about the blocks of code that I can and can not see the values of the variables in.
The problem was documented on an MSDN blog, as being a size limitation of certain types in certain situations, more details in the link. I believe it was 256 bytes and/or the total size/count of the number of arguments passed to a function. Sorry to say there does not seem to be a quick fix, but hopefully the MSDN blog entry will help you identify a way to solve your problem.
This article, Rules of Funceval gives a number of reasons why this can occur. If debugging is turned on and optimisation turned off already, there doesn't seem to be much else you can do about this problem.
Are you making release builds? Try changing the configuration to "debug" and see if it improves.
We have the same problem in two of our WinForm user controls. In both cases the user controls contain a lot of business logic (2000 and 3000 lines of code respectively) and make use of multiple fairly heavy objects (they have 30+ properties that get populated automatically from the database the first time when one of the properties are accessed). When you try to step through the (somewhat complicated) validation and saving methods, you get this same message when trying to access object properties.
We have come to the conclusion that the size and complexity of the user control combined with the size and complexity of the objects used and conditional database access just becomes too much for the debugger to handle and that we should probably just do some major refactoring to move most of the business logic out of the user control. It would be interesting to know if your problem arises from the same kind of situation and whether doing the said kind of refactoring actually does make a difference (we have not had the time and/or courage :) to do so).