0

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)

GisMofx
  • 379
  • 1
  • 4
  • 14
  • 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 '20 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 '20 at 22:57
  • 1
    Does this answer your question? [I've inherited 200K lines of spaghetti code -- what now?](https://softwareengineering.stackexchange.com/questions/155488/ive-inherited-200k-lines-of-spaghetti-code-what-now) – Bart van Ingen Schenau Apr 15 '20 at 07: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 '20 at 08: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 '20 at 11:42
  • And *why* do you want this? Is there some benefit from the users perspective? – Doc Brown Apr 15 '20 at 17:02
  • @DocBrown Yes. The whole application has multiple forms. The "main" application runs as monitor and processes files as they appear in a folder. During that process it uses code in form2 to do some things like format the data and print it. Now, if the user wants views the processed data at a later date, they only need form 1. The main program does not expose direct access to the other form via the UI nor would any user just viewing data need access for form 1. – GisMofx Apr 15 '20 at 22:19
  • Sounds to me, for this goal, you could avoid to have a "separate exe" - just make it possible to run the main application in two modes - a "viewer" mode and a "monitor&processing" mode. Of course, trying to entangle some things here is probably not wrong, but I would recommend only to clean up only the areas in code you need to touch to achieve your current goal. The canonical answer to these kind of questions is usually "get a copy of Feather's book 'Working effectively with legacy code'". – Doc Brown Apr 16 '20 at 06:22

0 Answers0