6

Background: Currently an intern at a company and working on repurposing older programs (still in use, but for different departments) for use in testing new hardware. The new hardware is different in terms of register layout and firmware interface from the older iterations of hardware. I have been given free reign on how to setup this project as it is to be used for the new hardware exclusively.

Currently there is a single .c file and 5 different header files that make up the program. The .c file is currently over 10000 lines long and comprises EVERY single function in use of main().

My question is, should I split the code into more recognizable chunks of .c files? It is currently only a mild annoyance to go through and find the methods I need, but it is time-consuming and I do have deadlines. What are the benefits and tradeoffs of doing so now, rather than later?

I aim to finish re-purposing the program by next week (this is heavy optimism, it will most likely take two weeks), so is it more efficient to start culling and moving around code now, or will I benefit more from just attempting to force my way through as is?

ardent
  • 328
  • 1
  • 10
  • 1
    Very minor note: `.C` is (non-standard) extension for C++; `.c` is for C. It matters for example when you accidentally mix C++ code in C and the compiler does not complain. – K.Steff Jul 13 '12 at 21:36
  • @K.Steff, I don't think I ever mentioned using C++ in this question? – ardent Jul 13 '12 at 21:39
  • But the file extension you mention is related to C++ files, not C files. This can lead to subtle issues, which is the reason I'm mentioning it. – K.Steff Jul 13 '12 at 22:10
  • @K.Steff "Some Unix compilers use a lowercase ".c" extension for C and an upper case ".C" extension for C++, although this convention is not common." It's not a common convention, and one I did not know of, I have edited my question for clarity though. Thanks for the heads up. – ardent Jul 13 '12 at 22:19
  • 1
    You're welcome, my comments' purpose was to help you *not* learn the subtleties the hard way (as I did). Btw, great question. – K.Steff Jul 13 '12 at 22:27

3 Answers3

5

If it is possible make the existing code more manageable, you should better refactor it. Otherwise it's going to cause you trouble every time you refer to it. Imagine that you need to work with that code again in a year or two. I don't think it will be a pleasant experience.

Even if you don't have much time, it is really worth refactoring. I think one day will be more than enough for splitting the code into several logical pieces and creating a separate file for each. This will help you get the bigger picture of the code as a whole, and next time you need to find something you will know exactly where to look.

There are some similar (but not duplicate) questions. Take a look at them:

Community
  • 1
superM
  • 7,363
  • 4
  • 29
  • 38
0

Presumeably you are testing the code on the boxes with a view to migrate over to it. Therefore, I would presume it best to keep the software as close a possible to the original if that is to be used for side by side comparissons etc. Otherwise, what's the point?

Wolf5370
  • 191
  • 6
0

Here's what I did in my previous job. I too faced this problem where some idiot thought that it would be good idea to put the code in file and since he will be the only one working on it for years to come, he roughly knew line numbers for each function/method.

I knew it was going to break things If I would try to modularize whole code, so I started picking out pieces of methods/functions which I was changing. For example I had to fix a shopping cart display issue and for that I had to make changes in method/function clearShoppingCart(), so I took this code placed it in a separate file ShoppingCartUtility.java

Over a period of 3 months, I had moved out 75% of code in a manageable and easy to understand structure.

Cheers! Dinesh

Dinesh Arora
  • 101
  • 1