CS: code improvement

Got it! This site "robinsnyder.com" uses cookies. You consent to this by clicking on "Got it!" or by continuing to use this website. Note: This appears on each machine/browser from which this site is accessed.

Whenever writing new code keep the logic as clear as possible. For old code, if it works, leave it alone.

If it ain't broke, don't fix it.

For new code, keep the logic as simple and clear as possible.

Programmers are usually notoriously bad at guessing which parts of the code are the primary consumers of the resources. It is all too common for a programmer to modify a piece of code expecting to see a huge time savings and then find that it makes no difference at all because the code was rarely executed. Bentley, J. (1982). Writing efficient programs. Englewood Cliffs, NJ: Prentice-Hall., p. 32.

Bentley is author of the popular series Programming Pearls and the book Writing Efficient Programs.

More: Jon Bentley

Probably the biggest misuse of time any programmer can make is to invest in improving the performance of something that doesn't matter - a body of code whose execution time is already well below the end user's perception threshold (such as submillisecond text redraw) or that is dwarfed by the costs of other operations that occur in the same context. Thorpe, D. Delphi component design. Reading, MA: Addison-Wesley., p. 251.

More: Danny Thorpe

As Anders Hejlsberg, chief architect of Delphi, is fond of saying:

If you take a program with an inefficient design and implement the whole thing in hand-coded assembler, all you'll get is a faster implementation of a low design, which is never the same as a fast program. Thorpe, D. Delphi component design. Reading, MA: Addison-Wesley., p. 250.

Anders Hejlsberg, coauthor of Turbo Pascal and chief architect of Delphi, was hired away from Borland by Microsoft a years ago and is the chief architect of C# and a chief contributor to the .NET architecture.

More: Danny Thorpe

Explain a specific example of getting it right before you make it faster and one of not getting it right before you make it faster.

Fallacy: You should make your code run fast.

Here are Jackson's rules of code improvement (to run faster or take less space).

Rule 1: Don't do it.
Rule 2: (For experts only!) Don't do it yet.

Try to make your code clear as to correctness. If it does not have to work correctly, I can make the code as fast as you want.

A CS student takes courses on simple ways to make code reasonably fast. Making code fast has issues.

It can cost a lot in time and effort.
It makes the code less maintainable and more prone to errors.
It can cause legal issues if anything stops working or changes how it works.

The same remarks hold for making code take less space.

Before spending time making code fast, or taking less space, get the approval of the manager. [opportunity cost]

Few computer science undergraduates will ever do real computer science.

Many computer science undergraduates will do software development/engineering. The goal of software engineering is to develop software on-time, on-budget and that meets the needs of the customer.

The inherent problem in the goal of software engineering is that only two of the following three are possible.

fast (on-time)
cheap/inexpensive (on-budget)
correct (meets the needs of the customer)

Thus, many trade-offs must be made.

Here are some general guidelines.

Correctness first - make it work correctly.
Remove repetition and redundancy to make the code easier to maintain and change.
Identify slow parts - profiling, timing, etc.
Speed up the slow parts (that provide value in relation to cost)

In areas such as computer and data science, there are parts that need to be made fast. There are usually libraries that have done this. Use them.

Manually created code that is repeated is almost always a potential problem.

A large part of computer science and software engineering techniques are designed to help eliminate or minimize repeated code.

In most cases, this is always a good idea (for any new code or broken code that needs improved).