Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I always liked to ask myself "what's the first principle(s) of this?" after I learned the basic stuff of something (e.g. programming). It's an inspiring question, IMO, that can force you to think about the most important principle(s) behind something, especially a skill such as programming.

So, what do you think is the first principle(s) of programming? I'll give my answer below a little later.

share

locked by maple_shaft May 15 '13 at 16:40

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

    
We do not talk about fight club. – Job Jul 10 '11 at 14:25

93 Answers 93

Paraphrasing Fred Brooks:

Representation is the essence of programming. Much more often, strategic breakthrough will come from redoing the representation of the data. This is where the heart of a program lies. Show me your code and conceal your type definitions and function prototypes, and I shall continue to be mystified. Show me your type definitions and your header files, and I won't usually need the bodies of your functions or methods; they'll be obvious.

And just to add a shred of originality, when you write down your data-structure definitions, document their bloody invariants already!

share

What is the simplest thing that could possibly work...

share

I would have to say that testing is one of the most important pieces of the puzzle. In my opinion test early and test often. Whether you design method is highly planned or agile there is nothing more important than testing to keep you on the right path.

share

Indirection.

It might not be obvious why this is, or even what this means. But indirection is really at the basis of all of programming.

At a more superficial glance, it only seems to touch abstraction (as a concept), or perhaps also pointers (after all, they are the archetype of indirection). But pointers are just one instance (there! indirection!) of the concept, and there are many more, that are effectively equivalent upon closer examination.

First and foremost, variables are indirections because they allow the manipuation of a value indirectly via a symbol (name). As a direct consequence, functions are an indirection, because they replace one symbol (the formal parameter) with another (the actual parameter, or argument (sometimes, the definition is the other way round)).

Since classes are historically just functions in disguise, classes are obviously an indirection for the same reasons as functions.

Arrays (or lists, same thing) are another indirection, often exposed as a fundamental type. In fact, there is no difference between an array and a pointer. Both refer to other things, or none (in which case the array is empty, the pointer is null or a special placeholder, “not in list”: NIL).

I've recently read a paper where the pseudo code contained the following function, and use:

function UpdateItem(item, position) do
    P <- { }
    if item.x > position then
        item.count <- 0
        P <- { item }
    item.count <- item.count + 1
    item.x = position

Results <- { }
for something or other do
    position <- GetPosition()
    Result <- Result U UpdateItem(current, position)

The point here is that, like all good mathematical pseudo-codes, it operates on mathematical sets, and augments a Results set by joining it to another one. Now, how would one implement this? Obviously, we could just use a Set data structure, or an array, or a vector, or any of these. But usually, this is done via pointers, right?

item_t* update_item(item_t* item, int position) {
    if (item->x > position) {
        item->count = 0;
        return NULL;
    }
    ++item->count;
    item->x = position;
    return item;
}

item_t* result = (item_t*)malloc(sizeof item_t * N);
unsigned index = 0;
for (something; or; other) {
    item_t* r = update_item(item, get_position());
    if (r != NULL)
        result[index++] = item;
}

For me, this shows really well that many, many different programming concepts just implement/perform some kind of indirection and that, despite all their differences, most of them can be expressed in terms of other means of indirection trivially.

So yes, I think indirection is really the first principle of programming, since all others are just indirection in disguise. Except recursion. Of course, recursion can be used to describe indirection. ;-)

share
    
I didn't read all of that but yes indirection is the cornerstone of abstraction. – Ollie Saunders Jun 14 '09 at 11:42

Do no harm :)

share

Use your head. It is terrifying how many people fail that one.

share
  • 20% code for function

  • 80% code for exception

share

"Computers Are Blind, Deaf and Stupid".

I should tell this to that teacher (not a programmer) who thinks that the formula is enough for programming an app that makes math calculations. You must tell the computer what to do with that formula, doh!! (the same is for data from a BD).

Blind and Deaf... if you make signal and image processing, you know this.

share

Sequence, Choice, Repetition

share
    
Sequence, Selection, Iteration – camh Oct 2 '08 at 3:53
    
Sequence, Selection, Recursion - or assignment, test, branch – Steven A. Lowe Nov 21 '08 at 15:47

Refactor before it's too late.

share
    
You don't wanna refactor too early, either. So that begs the question of WHEN. – pongba Oct 1 '08 at 19:18
    
When it needs to be done. :D – Jeff Yates Oct 1 '08 at 19:28

This is a good question.

  • Know your requirements
  • Know your user
  • Know your limits
  • Always assume you don't know everything
  • Always understand the code you're using/writing
  • Never reach conclusions without evidence
share
    
6 first principles. Any pithy summary? – S.Lott Oct 1 '08 at 20:07

When refactoring unnecessarily complex code, I often repeat the mantra:

The computer wants to do the right thing, you just need to get out of the way.

share
    
Could you elaborate a little? – pongba Oct 1 '08 at 19:34
    
Much code, particular that by junior programmers, tends to be overly complicated. Most refactoring is just simplifying the code. – James Curran Oct 1 '08 at 20:44

While keeping it simple (KISS) and not duplicating code (DRY):

  • Make it work right
  • Make it work fast
share
    
Correctness is vital. But fastness isn't necessity. – pongba Oct 1 '08 at 19:43

In practice, and very unfortunately, good testing turns out to be more important than good programming. Testing increases the value of ugly code. If you can't write beautiful code, you should at least make it testable.

share

Never completely believe what you are told about how the program will be used.

share
    
I assume you mean "... about how the program will be used?" - And Amen to that. – CrashCodes Oct 1 '08 at 19:42
    
Oops. Thanks. Many times I've been told, "no you don't have to worry about that edge case." Guess what? – Will M Oct 1 '08 at 21:09

Think about how then end product will be used at least as much about how the code looks. You could write the best commented, most maintainable, most brilliantly logical code ever but it's essentially a failure if no one wants to use the end product.

share

Occam's Razor. Reduce the problem/task to its simplest form. Then - and only then - start coding. Don't put the cart before the horse. Requirements first. Sure, they may evolve but the core requirement will be the core of your code.

share

Don't repeat yourself!

share
    
could you say that again? – Steven A. Lowe Nov 21 '08 at 15:46
    
Ironic that this is a repost of several previous answers. – Neil N Jul 31 '09 at 18:57

If the system won't work on paper then it won't work as a program. The reverse isn't always true, but a good computer system is usually based on a good paper system.

share

Think as if you don't know any particular programming languages (so that you don't fall into the trap of "thinking in XXX". Code to realize that thinking using the proper language.

share
    
Actually I consider this to be not very helpful because "thinking in XXX" is a must to get to efficient, maintainable solutions. But I definitely encurage knowing several languages well, also several programming paradigmas, to avoid seeing every problem just from the point of a language. – mh Jan 8 '09 at 19:02

If it (the project) doesn't give you a hard-on, don't do it.

share
    
Women aren't going to be able to do any projects with this criteria. – Beska Jul 31 '09 at 18:39

When you start something finish it!
Use the other principles to achieve this.

share

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." ---- Martin Golding

share

One important aspect of programming that is often neglected and ignored is "Separation of concerns". Before starting to code, it is crucial to analyze and design your classes to ensure they are not tightly coupled. Otherwise you will end up with very dependent objects and code, which makes change very difficult and refactoring a nightmare.

Applications should be layered sufficiently and use of design patterns to decouple your classes allows for easy maintainence and ease of testing.

share

Besides not reinventing the wheel, you should understand how the wheel was built and what it really does.

share

There are only three things in the universe: data, containers for data, and tools that either put data in a container, take data out of a container, or change the data in a container, and they overlap.

share

SOC - Separation of concerns
KISS - Keep it simple stupid
DRY - Don't repeat yourself

in that order

share
    
Aren't SOC and Dry redundant? – Neil N Jul 31 '09 at 18:52
    
I think they're quite orthogonal, sometimes even contradicting... – Thomas Danecker Aug 4 '09 at 6:42

Knowing WHAT not to program is as (sometimes even more) important as knowing what to program.

share
  • The way of thinking is more important than pushing the actual buttons
  • All good programmers are lazy, but not necessarily the other way around (!)
share

Understand the problem.

share

Not the answer you're looking for? Browse other questions tagged or ask your own question.