I've willingly inherited a VB.Net forms project based on .Net 3.5 last edited with VS2012. I was able to open it up and up-convert it to VS2017. I can compile and run it and make some little tweaks. The code is written a little more like a VBA project/module filled with random classes behind form files and 1000 line methods behind a button actions.

No namespaces are defined and it's not clear to me how I should try to re-organize the code without breaking it. (Because I already have done that once.)

Every time I create a new project in the solution, it creates subfolders and I need to add references to the existing project to the new one. It feels a little clunky and dis-organized.

So far, I've started to pull classes into their own files, but nothing more than that.

How do I best break apart the code and forms so I can get separate exes for the forms that require them? How should the underlying folder structure look? Flat or Sub folders? How should I apply namespaces?(I know this may be a little opinion based, but I'm stuck at where to start)

  • 1
    Consider, does the code need to be reorganised beyond the steps you've already taken to preserve its compilability and easy wins like separating classes into files? The overall folder structure is for you to determine in accordance with the conceptual structure of the program. If the code has been written very badly in the first place by a single author, then any code change may risk breakage, and there's no point bearing that risk and effort unless there is something to be gained from it. Not all code can necessarily be refactored safely and economically.
    – Steve
    Apr 14, 2020 at 22:32
  • @Steve You raise a good point. Economics. That's what's stopping me from rewriting large portions of it. It's working as is, but I just need a way to get the separate EXEs, without too much fuss, the separate forms. I guess I'll take some small wins if I can.
    – GisMofx
    Apr 14, 2020 at 22:57
  • 1
    Does this answer your question? I've inherited 200K lines of spaghetti code -- what now? Apr 15, 2020 at 7:24
  • Do you have a clear goal, a reason why you actually need to change the code? Which new requirements have to be added? Are there bugs to fix? Is something working "too slow" from the users perspective? What strikes me in this question is that there is not one single word about these points - refactoring "just in case" is a doomed approach.
    – Doc Brown
    Apr 15, 2020 at 8:03
  • @DocBrown my immediate goal to be able to compile a separate form to its own exe as it was updated. The "main" code uses the form as well, but it gets compiled into that main exe.
    – GisMofx
    Apr 15, 2020 at 11:42


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.