Rewriting code from scratch

[sancho3]

This is a very interesting article.

you can ask almost any programmer today about the code they are working on. “It’s a big hairy mess,” they will tell you. “I’d like nothing better than to throw it out and start over.”

The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.

[jj2007]

OGC, in other words: Organically Grown Code ;-)

[Tourist Trap]

This is a very interesting article.

It’s harder to read code than to write it.

This is also that we forget the meaning of the code that is not freshly typed. So rewriting can only be appealing. However to avoid this issue there is a trick, documentation. Document everything and document the documentation :D

[cbruce]

.
It's just the same as everything else that has a creative process... it's a *process*... and the process gets in the way of the process itself.

It follows the theory that every moment of decision is a *cusp* in time. If I choose left, the future is left-oriented. If I choose to use doubles in the solution, the future is doubles-oriented.

These decisions take place in every AHA! moment, every code planning session, every keystroke I type.

It is easy, (after writing a lot of code - or finishing a project), to look at where you are and go, "I wish I had made that decision instead". But even if I had taken that alternate path and decided to use integers instead of doubles... I could also find many issues going down that path... perhaps enough issues that it would make me think it would have been better to use doubles!

The more I learn, the easier it is to make better decisions in many situations.

But the more I learn, leads me to tackle new and harder projects... which means that there is always another moment of decision - and another cusp in time.

We do tend to be rather proud of a project that we have crafted and polished. But it is always humorous when we go back one year, two years, etc., later and start finding the things that we could-have-done-better... either because we have put more tools in our toolbox since then - or because we just see that project from a new perspective.

Although we are not (usually) being punished and forced to write code... it often seems that we find ourselves in the same situation as Sisyphus.

We should be thankful that we do not find ourselves in the same situation as Tantalus. At least we, occasionally, get a sip of water when we *think* we've done a great job on a piece of code... (for the moment). [smile]
.

[lizard]

Although we are not (usually) being punished and forced to write code... it often seems that we find ourselves in the same situation as Sisyphus.

We should be thankful that we do not find ourselves in the same situation as Tantalus. At least we, occasionally, get a sip of water when we *think* we've done a great job on a piece of code... (for the moment). [smile]
.

Then we better write code like Hercules. :-)

[jevans4949]

It largely depends on whether the programmer(s) amending the code understand the mindset of the original coder. I once wrote a macro in IBM assembler to print out the contents of a mainfile record, with the field name and the data printed according to type (bit, binary, decimal, character) and length. The person who came after me needed to add a field, but didn't understand the macro, so did it the hard way.

I never programmed in the APL language https://en.wikipedia.org/wiki/APL_(prog ... _language); it is very concise due to the use of mathematical-type symbols. I was told that the rule was: if you don't understand the programme in half a day, you should rewrite it.

[grindstone]

if you don't understand the programme in half a day, you should rewrite it.

That's the way I learned to like modular programming, through the years. <smile>

[lizard]

if you don't understand the programme in half a day, you should rewrite it.

That's the way I learned to like modular programming, through the years. <smile>

Similar for me. There are few rules to make code clean and readable.

1. Choosing "speaking" variable, sub and function names. Then many lines are almost readable like normal human language. In Variable names like "fgZr45_4BB" its hard to read anything, they are only confusing.

2. Clear program structure like first block init, then processing and last close. If there are functions and subs all in order on the beginning or after the end.

3. Comments and blank lines before each separate code block. Inside code block no blank lines to show which lines belong together in a block. Further comments at difficult parts.

4. At the beginning program name and short description.

5. In bigger programs sometimes it is useful to develope single parts in separate little test programs and when working to paste in the big program. Single child-windows can be designed in a sub or function and when ready simply included and called from main program.

6. To me it is more readable to have the most important data in global variables at the beginning instead to have them spreaded all over the place.

7. Not to much little functions,subs and macros. Better group the code in logical units, speeds up and makes it more readable.

[Mihail_B]

I suppose it's rather a matter on one's perception about the code and the abilities does he [or she] possess the most.

Code rewrite is not so error prone when you have lots of code to rewrite.
It's a bad a idea to start rewrite when you have more than 30K lines of code.
You will end up with new code that needs to be tested again and you will find yourself "inserting" new bugs and even repeating old mistakes.
If your code is stable and works fine but only has limitations then it is rather good to start Refactoring your code and to do this via continuous integration.

Refactoring and continuous integration will always keep your code compilable, testable and even compatible; you will get accustomed with the code, understand it and even be visionary to what it should become in the future.

But to do that you need to learn about :
1. refactoring (here's a good resource : https://refactoring.guru/refactoring )
2. continuous integration ( https://en.wikipedia.org/wiki/Continuous_integration )
3. tests writing

It's good to have in mind a programming model that, let's say, you have seen it at older programmers (or more experienced if you wish to call it by name) in their own nice libraries (not giving any names here).

Why invest in writing from scratch, having to care for 2 versions, releasing bug fixes for 2 versions that don't go well with each other ?

Refactoring code keeps your code stable and testable and releaseable at any time because you used continuous integration as way of coding.
Of course a good editor could help a lot (like replace in all files, search in all files, etc, like in NetBeans/PhpStorm or Visual Studio - more or less).

Writing tests for your code is also a good idea, since refactoring (like moving a standalone function from global context to being a [static] method on a class) done in a hurry could have left some parts of your code unattended and so you could have broke some functionalities.

But if you don't like refactoring and code rewrite is much easier for you and you know that you will have time to rewrite, test and release your code than perhaps refactoring is not for you ...
Anyway, refactoring also includes code rewrite but only where its suited :) so you should still read about refactoring (and continous integration (and testing))