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.
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!
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.
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. ;-)
"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.
Sequence, Choice, Repetition
Refactor before it's too late.
This is a good question.
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.
While keeping it simple (KISS) and not duplicating code (DRY):
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.
Never completely believe what you are told about how the program will be used.
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.
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.
Don't repeat yourself!
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.
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.
If it (the project) doesn't give you a hard-on, don't do it.
When you start something finish it!
Use the other principles to achieve this.
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." ---- Martin Golding
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.
Besides not reinventing the wheel, you should understand how the wheel was built and what it really does.
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.
SOC - Separation of concerns
KISS - Keep it simple stupid
DRY - Don't repeat yourself
in that order
Knowing WHAT not to program is as (sometimes even more) important as knowing what to program.