Priorities for writing code

Question

I've been following SO for a while now, and every so often I see people asking about the fastest way to do something. I certainly acknowledge that code must be well written and even tuned every now and then, but in my everyday work I am much more concerned about maintainability of code and only occasionally do I actually have to tune code to make it go faster.

Therefore I would like to know what priorities others are following when writing code. So in other words: What are the most important attributes of the code? And as a follow-up questions I would like to know who made this decision (management or developers)?

Answer 1

Tests are top of my list of important attributes. Makes life so much more easier down the road. It's been my decision to do where I work as no one else does TDD.

Answer 2

Code must perform its intended task in a time period short enough to be usable. This varies widely between applications. Striving to make your code "fast" when you fail to understand how fast it needs to be is a waste of time; at the same time, striving to make your code "maintainable" when you lack a clear, high-level idea of what your code is meant to accomplish is doomed to failure. Therefore, top priority must be given to understanding the problem you wish to solve; everything else follows from this understanding.

See also: When is optimisation premature?

Answer 3

Separation of concerns is very important to me. If each class has a limited number of purposes (hopefully one) then whenever code needs to be maintained you have fewer places to look. This also avoids the multi thousand line monstrosity that only Bob can fix or work on. Combined with proper unit testing the scope of each class and test is reduced ensuring that each section of code is easier to understand and diagnose.

Answer 4

Software Quality should be on the top of every code-writing priority list...

• Maintainability
• Flexibility
• Portability
• Reusability
• Readability
• Testability
• Understandability

Answer 5

When coding:

1. Correctness,
2. Readability,
3. Efficiency,
4. Simplicity

In that order.

When designing:

1. Organization (many things, including OOP and single-task concerns),
2. Cleanliness (no redundant code),
3. Testability (including separation of concerns).

In that order.

Answer 6

mdbritt's answer is pretty close to my attitude, but a few other things:

• I personally value readability over correctness. It's easier (IME) to go from readable but incorrect code to readable and correct code than to get there from correct but unreadable code.
• I know it sounds like a given, but I think it's hugely important to understand what you're actually trying to do before you start coding. I'm not saying you need to know everything about your whole application before you start - and you can certainly improve the design of some areas as you go; but when it comes to a single class, you should at least know what results you're looking for and why you're doing it.
• Performance is important for architecture but much less so for implementation. If you get the architecture wrong to start with so that it doesn't scale, you're in trouble - but if the architecture's right, you can fix an implementation later on. I know it's a well-worn adage, but it really does make sense to write the simplest working code first, then profile the application and optimise just the bottlenecks until you're satisfied. (This puts simplicity above efficiency in my version of mdbritt's answer - for most of the code.)

Answer 7

My priorities:

1. The code has to be readable.

2. The code should do something useful.

3. In many cases, it has to get out the door quickly, in which case I may comromise on things below.

4. The code should be nicely decomposed into modules.

5. It should be fast enough.

Last time I had code that wasn't fast enough was when I was writing an equation solver and needed to turn equations into code, which meant replacing arbitrary variable names with valid program identifiers. Turns out a sequence of 30 single substitutions wasn't very smart---way too much allocation. Doing a single substitution of all 30 variables in one pass saved the day.

Answer 8

This really depends on what software you are developing and who it's for.

If you are writing a LOB web app for an enterprise where everyone uses the same version of IE for all web browsing, then a bug that causes your app to horribly break in Fire Fox isn't important.

If you are Google developing Gmail, then such a bug becomes a lot more important.

Sometimes performance can out weigh correctness. For example if you have a bug that impacts say 0.1% of your customers, and fixing it would require you to slow down the app considerably for the other 99.9%, then performance becomes more important.

So, I'd say it really depends on your individual circumstances.

Answer 9

The fastest way to develop something IME is to have accumulated so many parts of solutions that are to the most part easily assembled into the new problem. For example, I have a data engine that I always use, I have a service base class, a scheduler, functions to copy files and check their hashes, etc. I normally can whip out a program fairly quickly just because I have these previously developed and tested code at hand.

Answer 10

Performance is usually not a problem except you have a batch processing of thousands of data files. A good deal of the performance comes with the simplicity, which is one of my priorities. I would see my priorities roughly in the following order:

1. Reliability
2. Simplicity (in algorithms, interfaces etc.)
3. Genericity (can I make my program solve the problem in a more generic way so that future changes will be easier?)
4. Robustness
5. Reusability (can I make my program solve other problems as well?)

Answer 11

My priorities are LTFCE: Legible, Testable, Flexible, Compliant, and Economical, in that order. A more detailed discussion of these priorities is posted in an answer to this question.

As you can see, I agree with you that almost always speed is nowhere near the top concern.

Answer 12

My number one priority above everything else is that changes in requirements, no matter how big, require only small changes in code. No matter what you think, or what they tell you, they are going to change the requirements. And none of them are safe.

• Assume everything will change.
• Parameterize E V E R Y T H I N G.
• Eliminate dependencies.

If a requirement changes and I have to change code in more than one place, I feel like I've failed. But then I figure out how to rewrite that code so when the requirement changes a second time (you know it will,) I can change it in a single place.

There's a reason why people invented things like n-tier and MVC and other de-coupling techniques.

--
bmb