Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

show 1 more comment

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
add comment

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

share
add comment

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
add comment

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
show 1 more comment

Do no harm :)

share
add comment

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

share
add comment
  • 20% code for function

  • 80% code for exception

share
add comment

"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
add comment

Sequence, Choice, Repetition

share
show 2 more comments

Refactor before it's too late.

share
show 2 more comments

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
show 1 more comment

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
show 2 more comments

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

  • Make it work right
  • Make it work fast
share
show 1 more comment

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
add comment

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

share
show 2 more comments

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
add comment

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
add comment

Don't repeat yourself!

share
show 2 more comments

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
add comment

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
show 1 more comment

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

share
show 1 more comment

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

share
add comment

"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
add comment

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
add comment

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

share
add comment

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
add comment

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

in that order

share
show 2 more comments

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

share
add comment
  • 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
add comment

Understand the problem.

share
add comment

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