rewriting code

[nether]

Anyone else ever feel like as soon as you get close to finishing a project, you want to rewrite a lot of your code, because in the time you've taken on the project, you've thought of a much better/more efficient way to code it?

[LB]

I don't really rewrite so much as refactor - most of the code is fine but the organization is lacking now that I have it all in front of me and working.

[E0p9LyTq]

Unless rewriting code can be a significant boost in performance or less prone to errors leading to crashes, then no.

That doesn't mean I won't reorganize code (refactor as LB mentioned) for easier reading and maintenance.

If I do rewrite I change a little at a time and test, test, test! before rewriting another section, so I know there are not unintended consequences from the rewrite.

A good example of what I would consider something to rewrite is (very simplistic):

#include <vector>
#include <iostream>

int main()
{
   std::vector<int> fibonacci = { 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 };
   
   for (int loop = 0; loop < fibonacci.size(); loop++)
   {
      std::cout << fibonacci[loop] << ' ';
   }
   std::cout << '\n';
}

Maybe to this:

   for (auto loop = fibonacci.cbegin(); loop != fibonacci.cend(); loop++)
   {
      std::cout << *loop << ' ';
   }

or to this:

   for (const auto& loop : fibonacci)
   {
      std::cout << loop << ' ';
   }

[punksheep]

Hi nether ^_^
Very good question.
I will say that, with only few exceptions, when at the end you need the urge to change (restructure) somehting, it's the sign that you went the wrong way somewhere and end up in that situation. And it can happen to anybody anytime.

Do you know agile development ?
For example, in TDD, we use a cycle that is short enough for you to see the final end result of your code... it's a principle you may want to experiment : consider your code as a final product at each step of your modification and consider yourself in a situation where you will always have to deploy.
You'll then do your best, the most valuable functionalities sooner and before the others and relie on refactoring to improve your code.

When a "big" refactoring is "needed", probably you'll want to do it as soon as possibly (it's a principle that states "do the hard things sooner").
But big refactoring occurs in "bad" codes.

Then you talk about efficiency.. this is an other story ^_^ and a very important one for C++ programmers as us.
And your feeling is right, optimization must always come at the end. And yes, you sometimes have a lot to modify for that.
Sometimes you will find yourself stuck in an architecture you've created, it was good months ago, now, no more. It happens also... change it if it's required.
Other optimizations are rarely so "destructive" and only impact one or few functions.

Rule of thumbs : always, perpetually refactor (all the time). But optimize at the final end when your program is finished.
Readibility, robustness first. Then efficiency ;o)

FuryGuy, I would add an other step to the refactoring :

dump(fibonacci);
...
void dump(... container)
{
	for(auto const& e : container)
	{
		dump(e);
	}
}

:oP~