Stack OverflowWhat do you consider the 1st principle(s) of programming?
[+50] [94] pongba
[2008-10-01 19:03:43]
[ programming-languages ]

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.

[+87] [2008-10-01 19:05:30] Bill
  1. KISS - Keep It Simple Stupid
  2. DRY - Don't Repeat Yourself
  3. YAGNI - You ain't gonna need it

KISS should be Keep It Simple Smart. The first time you have to rewrite a large chunk of your code because you didn't design smart and extensible you will agree to this. :) - Sandor Davidhazi
(4) I think KISS should be "Keep It Simple, Stupid!" - Dennis Cheung
I'm actually working on a blog post about how these two are the two most near and dear to a programmers heart and how at the same time they are a bit of oxymorons as often times you'll need to choose one against the other - Andrew G. Johnson
(10) I would also add YAGNI. - Daniel Straight
This enumeration is the wrong way around. DRY should be first. - Svante
I also like the "Keep it SUPER simple" expansion of the acronym. - Agos
@Agos: But that's not the idea. It shouldn't be super simple. It should be simple enough ;) - ya23
KISS and KISS again ;-) - Perica Zivkovic
I always the KISS acronym was kind of dumb and hypocritical. After all, the extra S is more than the phrase needs. Keep It Simple conveys the point. The Stupid, Super, or whatever is superfluous. But hey, has to be clever right? - Programmin Tool
(3) @Programmin Tool - I don't think "stupid" is superfluous. I think it conveys that we have a tendency to want to be "smart" and this manifests as unneeded complexity. As I see it, the "stupid" tries to remind us of this tendency by helping us remember what we initially think is "smart" is usually not. - codekaizen
They are worthless if you don't understand the problem first: - OscarRyz
[+36] [2008-10-01 19:05:09] Daok

Write code like if it was you that would have to maintain that code.

This is a very practical heuristics, 3x :) - pongba
(15) Write code as if an axe-wielding psycopath will have to maintain it. FTFY. - Forgotten Semicolon
(8) ...and the axe-wielding psychopath knows where you live. - CAD bloke
(2) ..,and he has just sharpened his axe... - Roalt
dude, I love these comments, vivid and horrifying - CMinus
(1) ... and he is working by your side. - yelinna
... and you hear him muttering 'soon, precious, soon' - Adriano Varoli Piazza
[+23] [2008-10-01 19:06:26] OedipusPrime

Be as lazy as possible.

(2) Again, too general, IMO. This begs the question "How lazy is the appropriate amount of laziness, really?", because obviously "sloppy" is something you don't want to be either. - pongba
This is a reference to perl's "Laziness, Impatience, and Hubris" - Ólafur Waage
So we're talking about different kind of laziness? I thought by "lazy" Bob means "don't bother organizing your code before it gets tangled" :D - pongba
I think of programming laziness as "if the computer can do the job for you, it should". DRY and YAGNI are special cases of this principle. It can also be extended to "code clearly and plainly". When you come back to maintain the code the laziness should continue. - Darron
I've always said that there's an important element of laziness in programming... the "if the computer can do the job" type of laziness. This also becomes spending hours programming something to do a few minutes of work. Of course, the next time that few minutes of work comes along... - John Mo
(2) Too general. By that analogy all variables and functions would be 1 letter because I was 'too lazy' to type out something meaningful. Assuming I had to maintain it also however, then perhaps you are correct, because I would make it as easily maintainable as possible. - Kyle B.
(2) @Kyle: Yeah, that's the point. "True laziness" is making things easiest for yourself now as well as in the future. Which turns out to be the same as doing things properly. If you do less work now but more work later, you're not being "as lazy as possible" :) - Adam Bellaire
"I could write a good program that would handle this problem, but I'm really too lazy. I'll just suffer without." - Beska
[+22] [2008-10-01 20:18:07] Georgi

Zen, part I: Programming is only the road, not the way.

Programming is only the technique to teach a computer what it's gotta do. To be successful in creating fast, reliable software means to know your algorithms, best-practices and all the other stuff not necessarily connected to your Programming (language).

Zen, part II: If you are in a hurry, stroll along slowly. If you really are in a hurry, make a detour.

Sounds silly, but do not let yourself get into compromises that (really) may trouble you afterwards. I got a rule: If you are at the core of a program, try to be as precise and good as possible. If you are using methods from the core that are deep in your software, try to be faster in coding. If you are coding above these two, you can even get a little bit more sloppy.

Design errors are the hardest to find and/or fix, next step are programming errors in parts everyone relies on, then the "real showing-off software parts". If you need to fix a design error at the end of a project, ummm, that's not good... ;-)

Zen, part III: Know your path, Neo.

Know your environment, tools and the stuff you rely on on a daily basis and get it sorted so that it works for you. Best if you use your programming "environment" so natural that you do not even have to think of it. If you have to get a job done do not introduce "fancy new stuff" but do your work. This stuff can be introduced in a new project, namely then when you have time to prepare and use it.

Uh, and then again: I landed in Zen land whilst speaking about programming :) - Georgi
@part III - don't add "fancy new stuff" unless you're getting paid to do it! - Jason
+1 for the Matrix reference. I'm a sucker for a good one (that and the Zen. Makes me think of Python) - new123456
[+18] [2008-10-01 19:04:46] Dima

KISS (keep it simple, stupid).

It does indeed beg the question "How do you define simple?" And also "When is something too simple for the task at hand?" This is why you cannot become a good programmer just by knowing the first principle of programming.

I think this is a too general rule. It begs the question "how do you define 'simple', really". - pongba
(3) and if you're stupid, how would you know if it was simple? - Steven A. Lowe
That's a good one, Steven :) - pongba
"This is why you cannot become a good programmer just by knowing the first principle of programming" - love it. - yuval
no, this is why you cannot become a good programmer if you're stupid. Intelligent people recognize simplicity. Read 'Zen and the art of motorcycle maintenance', where the author calls this 'Quality', and treats it as undefinable. - Adriano Varoli Piazza
The simplest solution is usually the best! - Martin
@Adriano Sorry, but Robert Pirsig's Quality is more than just simplicity. - Dima
@Dima: you're right, I mean that quality and simplicity (in this case at least) are both undefinable, yet we know it when we see it, if our eyes are trained. - Adriano Varoli Piazza
[+17] [2008-10-02 01:23:26] Ryszard Szopa

Premature optimization is the root of all evil. -- Donald Knuth

Whether in implementation OR design. - Epsilon
[+16] [2008-10-01 20:33:49] OscarRyz

Understand the problem first!

Ah, finally somebody with this one. You ca kiss, yagni, dry all you want. It's useless if you program something for nothing. - e-satis
@e-satis: Yeap, that what I thought when I first answer this. I scroll for all the answer and surprisingly nobody posted before. - OscarRyz
Good answer. Hours and hours get wasted when programmers don't properly understand the full requirements of a problem. - Steve Wortham
Problem is: how do you you know you understand the problem? - Radagaisus
[+15] [2008-10-01 19:06:55] Daok

Do not reinvent the wheel.

The right answer to the question as to whether or not one should reinvent the wheel is always "it depends". So "don't reinvent the wheel" only goes so far. It may serve as a good heuristics most of the time, but not every time. - pongba
(4) Some "wheels" need to be reinvented. - CrashCodes
Tell that to Dunlop. He invented the pneumatic tire. If it wasn't for him, reinventing the wheel, we'd have a pretty bumpy ride. - Kibbee
(3) How about: Only reinvent the wheel if the benefits will be worth the costs - e.James
[+13] [2008-10-02 02:22:24] Brian M. Hunt

YAGNI - You Ain't Gonna Need It [1]. The idea behind YAGNI is to program for your requirements, not for prospective, potential features. The premise is that by keeping to what you need to program, you will (among other things) cut code bloat, reduce complexity, avoid feature creep, and reduce the restrictions on what can be done (and how it can be done) in the future.

I suppose it works in tandem with modular design: Future features can be augmented without redesigning existing code.


[+9] [2008-10-01 19:25:00] ctrlShiftBryan

Knowing when not to program.

what on earth is this supposed to mean? - anbanm
And when is that? - pongba
Sometimes you need to tackle a users problem differently - not just code a solution. - RichH
Human judgement and decision-making are part of everything; sometimes there's no point in trying to automate judgement. - S.Lott
Sometimes the "problem" you're trying to solve by coding is caused by another problem that can be resolved without coding. - Christopher Mahan
absolutely - I often find as a consultant many programming problems are really people problems or process problems. - Booji Boy
What he means is that many programming problems can be solved cheaper and more timely by purchasing off the shelf applications, components, or libraries. - Gordon Bell
[+7] [2008-10-01 21:54:29] Raz

If it wasn't tested, it is broken.

I agree on that one - Clox
[+6] [2008-10-01 20:09:03] user9282

Coffee in, code out.

(3) Tea in in my case =) - Clox
[+5] [2008-10-01 20:41:07] Michael Easter
  1. Distinguish between cause and effect (working with computers)

  2. Distinguish between fact and opinion (working with people)

  3. As simple as possible, but no simpler (design)

[+5] [2008-10-01 23:33:54] Christian Vest Hansen

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

-- Charles Antony Richard Hoare

[+5] [2008-10-08 04:07:08] Dov Wasserman
  1. Understand why the program will make someone happy (otherwise, why aren't you outside playing with all the other kids?). (This person can be you.)
  2. Develop a conceptual model of the business domain that captures all the needed complexity, and no more.
  3. Develop a conceptual model of the software architecture that captures all the needed complexity, and no more.
  4. Ruthlessly keep all other complexity out.

well said! couldnt agree more - Antony
[+4] [2009-01-08 19:11:26] Mike Hofer

Think first, code later.

You're nowhere near as smart as you think you are. Ask questions. Learn to value your peers.

When debugging, the first answer will almost always be wrong.

Code you write with the intention of tossing out tends to become a cornerstone of much larger processes. Never leave anything written haphazardly.

[+4] [2008-10-01 20:35:00] community_owned

it doesn't work till you showed it in a test

(6) That's not true, I've written tons of code that works and isn't tested! :D - Gavin Miller
(1) "I haven't tested it, I have only proved that it is correct" :) - Daniel Daranas
[+4] [2008-10-01 19:37:26] CrashCodes

Programming is a means not an end. Or perhaps, "Can does not mean should."

[+3] [2008-10-01 19:06:56] torial

Program with an audience in mind. By that, don't assume that anything you write will not be read and maintained by you or someone else.

A corollary to that: Prove that you understand the problem you are trying to solve by naming your variables and functions and classes well!

[+3] [2008-10-01 19:11:29] dmckee

Know your tools.

[+3] [2009-01-08 18:56:45] mh

In my opinion, the most important principle is the reduction of complexity by creation of good abstractions.

This includes

  • understanding the problem to be solved,
  • designing an appropriate solution for it and
  • implementing it,
  • preferably in a way that keeps the code understandable and maintainable,

but also determination of the point where to stop creating abstractions and get down to the fundamental properties of the implementation technologies (e.g. database system, programming language) to prevent creation of avoidable additional complexity.

[+3] [2009-06-22 10:18:35] Amy

Always write code as if the person who will be maintaining it is a psychotic serial killer who knows where you live

Also, never think you know everything about programming, keep learning

[+2] [2009-01-08 21:15:03] Konrad Rudolph


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->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. ;-)

I didn't read all of that but yes indirection is the cornerstone of abstraction. - Ollie Saunders
[+2] [2009-01-08 20:09:35] Bill

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.

[+2] [2009-03-09 12:26:49] Mike Sickler

Do no harm :)

[+2] [2009-06-14 12:09:27] tomjen

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

[+2] [2008-12-04 08:27:25] Norman Ramsey

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!

[+2] [2008-10-01 19:19:07] Bill the Lizard

I got into programming by way of studying digital electronics, so I guess for me the basic logic gates (not, and, or, xor, implies) were the first principles of programming.

[+2] [2008-10-01 20:10:40] Bryan Oakley

It's all about the user.

[+2] [2008-10-01 19:25:22] James Curran

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.

Could you elaborate a little? - pongba
Much code, particular that by junior programmers, tends to be overly complicated. Most refactoring is just simplifying the code. - James Curran
[+2] [2008-10-01 19:29:22] S.Lott

Principle: Software is Knowledge Capture.

Consequences: Many techniques for knowledge representation, all founded on Abstraction. Gives us layers, tiers, encapsulation, separation of concerns.

Many techniques for procedure representation, all founded on Sequence, Choice, Repetition.

[+2] [2008-10-01 20:35:28] Gabriel Isenberg

Write code for the next guy.

[+2] [2008-10-01 20:53:45] Quibblesome

DRY, pretty much everything else spawns from it. KISS is the other end of the balancing act to make sure you don't pursue software elegance to levels of insanity.

[+1] [2008-10-01 21:46:05] community_owned

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.

[+1] [2008-10-01 21:47:03] CAD bloke

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.

[+1] [2008-10-01 20:45:50] HLGEM

Garbage in - Garbage Out It doesn't matter how nice your user interface is if the data is bad.

[+1] [2008-10-01 20:22:25] Ates Goral

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


[+1] [2008-10-01 19:32:55] sharvell

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

  • Make it work right
  • Make it work fast

Correctness is vital. But fastness isn't necessity. - pongba
[+1] [2008-10-01 19:39:43] Will M

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

I assume you mean "... about how the program will be used?" - And Amen to that. - CrashCodes
Oops. Thanks. Many times I've been told, "no you don't have to worry about that edge case." Guess what? - Will M
[+1] [2008-10-01 19:22:12] Jeff Yates

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

6 first principles. Any pithy summary? - S.Lott
[+1] [2008-10-01 19:09:05] Joshua

Any problem can be solved with another layer of indirection.

Actually, having too many indirections is itself an issue waiting to be identified and resolved. So.. - pongba
resolved... by another layer of indirection! =) - Erik Forbes
Oddly enough, its true. Look at Spring... - Joshua
[+1] [2008-10-01 19:05:18] Joel Coehoorn

Sequence, Choice, Repetition

Sequence, Selection, Iteration - camh
Sequence, Selection, Recursion - or assignment, test, branch - Steven A. Lowe
[+1] [2008-12-04 08:33:34] seanb

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

[+1] [2008-12-29 13:29:02] Thomas Danecker

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

in that order

Aren't SOC and Dry redundant? - Neil N
I think they're quite orthogonal, sometimes even contradicting... - Thomas Danecker
[+1] [2008-11-30 06:43:49] J.T. Hurley

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.

[+1] [2008-10-02 13:34:48] Jivko Petiov

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

[+1] [2008-10-05 08:43:29] blizpasta

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

[+1] [2008-10-02 01:58:52] Booji Boy

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.

[+1] [2008-10-02 02:00:56] community_owned

Start with the output and work backward.

[+1] [2009-06-22 10:13:37] community_owned
  • 20% code for function

  • 80% code for exception

[+1] [2009-06-14 11:40:53] Ollie Saunders

Beneficially relating elements.

This means that there are elements (modules, subroutines, whatever) that relate in order to benefit one another (nothing superfluous). This is part of Kent Beck's responsive design concept. There's a talk on it [1].


[+1] [2009-01-08 20:32:13] johnny

Understand the problem.

[+1] [2009-01-08 20:49:44] duffymo

Decomposition. Solve large, complex problems by breaking them into smaller, more manageable pieces.

And - style matters.

[+1] [2009-01-08 19:51:48] peSHIr
  • The way of thinking is more important than pushing the actual buttons
  • All good programmers are lazy, but not necessarily the other way around (!)

[+1] [2009-03-09 12:25:18] pi

Abstraction, Composition

[+1] [2009-01-08 21:18:18] Rob K

Do one thing, and do it well. It's the UNIX philosophy ( It works at every layer.

[+1] [2009-01-08 21:22:42] TechHike


Just smart, and you will be engineering your way into bloated frameworks and writing UML until Duke Nukem Forever is released.

Just lazy and you are worthless, eating bon-bons in your sweats with no hope of amounting to anything.

If you are smart and lazy, that's where the money is. Engineering your way to nirvana by being pragmatic and recognizing ways to make your life easier daily.

[+1] [2009-01-08 21:24:05] SomeMiscGuy

When in doubt, manipulate the data!

[+1] [2009-02-17 13:44:31] pmlarocque

You have to resolve all the problems in the world with "if, for, while".

[+1] [2009-02-17 13:51:10] ng5000

JFDI - Just @#*&^%$ do it.

A friend recently suggested that agile, waterfall, iterative, etc etc etc are a waste of time and the best way to write software is the JFDI school of thought. Not my mantra, but made me smile.

[+1] [2009-01-08 19:10:31] Demian Garcia

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

[+1] [2009-01-08 19:16:46] Orkun Balkancı

making it bug free.

but everybody makes crappy buggy software!! - yelinna
[+1] [2009-07-31 18:39:53] yelinna

"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.

[+1] [2009-07-31 18:44:14] Kevin Pang

It doesn't exist unless it's committed.

[+1] [2009-07-31 18:47:47] Timur Fanshteyn

Computers do ONLY what you tell them to. If it doesn't work right, its because you haven't "told it" (coded) it right.

2nd favorite: its usually a problem with you (your code) - interpret this as in "first look for bugs in your code, before blaming it on bugs in libraries you use"

[+1] [2009-07-31 18:51:25] nwahmaet

Loose coupling. [1] High cohesion. [2]


[+1] [2009-07-31 18:52:59] community_owned
  1. Think First
  2. See 1.

[+1] [2009-07-31 18:53:03] Michael Stum

Always code as if the person who will maintain your code is a maniac serial killer that knows where you live

No idea where that phrase originated from (possibly from some humorous caption), but I think there is some truth in it: Code for maintainability. If other people can maintain it, then that usually means that it's kept simple and well structured for the most part.

[+1] [2009-07-31 18:53:08] Mike Two

Don't be stupid on purpose

[+1] [2009-07-31 18:54:28] ojrac

Code is written once, and read many times. Optimize for the reader.

[+1] [2009-08-03 17:25:12] jeje

I think that one consequence of the Church-Turing thesis [1] is that any algorithm that can be thought of, can be programmed on a machine.

It makes it incredibly hard to tell a manager/a client 'this is impossible' because in theory, if you can describe it, it is possible.

The rest is a matter of resource. The difference between a programmer and a non-programmer is that a non-programmer will ask for features which will range from 5 minutes development to 5 billion years, and they will be equally happy with each one of them. I exaggerate a bit, but that's the idea.

So here's the first rule of programming:

Maximize your 'end users satisfaction'/'resource' ratio.


I don't know that that's the "first principle", but it's a good one. - Jay
[0] [2009-07-31 19:04:14] Captain Segfault

We are morons. [1]


[0] [2009-08-03 16:37:24] osij2is

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

  1. Never trust data from users or other sources.

In other words, always check data for validity first. Bad (or unexpected) data can create havoc.

[0] [2009-08-03 16:47:35] Jay

I'll second DRY and KISS. I'd also add, "Knowing a language is not the same as knowing how to program. Just like knowing how to use the steering wheel is not the same as knowing how to drive." Learn fundamental principles, and then apply those using whatever language or tools you have available. Languages and database engines and the like come and go. Data structures and algorithms are forever.

[0] [2009-08-03 17:02:21] SP

Ask Questions first.

[0] [2009-03-09 09:48:36] community_owned

This is a good question.

[0] [2008-10-02 01:06:30] Tobias

Don't repeat yourself!

could you say that again? - Steven A. Lowe
Ironic that this is a repost of several previous answers. - Neil N
[0] [2008-10-02 02:54:36] Chris

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

Women aren't going to be able to do any projects with this criteria. - Beska
[0] [2008-10-02 13:17:46] Charles Beattie

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

[0] [2008-10-01 19:08:47] Pokus

Refactor before it's too late.

You don't wanna refactor too early, either. So that begs the question of WHEN. - pongba
When it needs to be done. :D - Jeff Yates
[0] [2008-10-05 08:06:57] edfoh

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.

[0] [2008-12-01 13:43:25] mannu


[0] [2008-10-01 19:24:35] pongba

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.

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
[0] [2008-10-01 20:29:44] Joshua

Structured Programming

[0] [2008-10-01 20:53:45] millenomi

When you assume, you make a YOU-KNOW-WHAT out of U and ME.

The golden rule, that one is. Always verify what you're taking for granted.

I like this one. Don't just assume, especially not unconsciously. - pongba
[-1] [2008-10-01 19:36:48] pmlarocque

Progamming is not for the lonely geek.

[-1] [2008-10-01 19:10:12] Giao
  1. Don't do it.
  2. If not doing it isn't possible, get someone else to do it.

[-1] [2008-10-01 19:05:43] Pokus

Do not overuse Interface.

How do you define "overuse"? I think the more appropriate way to say this is "Be aware of the possibility of overusing language features such as interface". - pongba
(1) This one is too language-specific - finnw
[-1] [2008-10-01 19:07:14] Jim C

Sequencing, what do I do and When do I do it.

[-1] [2008-10-02 02:17:31] Martin Cote

I will go with an item that is too often neglected: check your I/O.

When you write a program/function/etc. make sure that the input/output is valid.

[-1] [2009-01-08 19:18:54] Jim C

0 + 0 = 0

1 + 0 = 1

0 + 1 = 1

1 + 1 = 10

1 * 10 = 10

10 / 10 = 01

~ 0 = 1

~ 1 = 0

That is all there is to computers

There's no such thing as 2. Maybe you meant 10 / 10. - ojrac
[-2] [2008-10-01 19:11:43] GEOCHET

In general: Problem solving.

That is what it all boils down to.

And what's the 1st principle(s) of Problem Solving, again? - pongba
That's what everything boils down to. So if you think about it, we don't gain anything from this perspective. - pongba
@pongba: So it is an answer as useless as the question then? Perfect. - GEOCHET
I don't think the question is useless, especially judging by the cute answers :) - pongba
[-4] [2008-10-01 19:04:40] Mostlyharmless

No infinite loops.

And if you are a video game programmer? - Ed S.
Even video game loops have to terminate sometime. (I dont know, im not one) Also, programming is sort of like playing a guitar. Once you are 1337 enough (which you would be if you were a game dev), ignore the basics and let the instincts talk. - Mostlyharmless
The guitar metaphor is way off the track, IMO :P - pongba
What I'm saying is, that its easy for a good programmer to go back and selectively use his "lessons" as applicable. But once you tell a newborn that its okay to have infinite loops "sometimes", (s)he will think every situation falls in that 1% where infinite loops are allowed. - Mostlyharmless
@Mostlyharmless well, even "Infinite loops" will terminate some time too (Infinite time is just not real in this case). Even though I agree that inifinite loops is something to watch out for I hardly think it could be considered even close to "the 1st principle of programming" - kigurai
@kigurai: I was nowhere close to being serious when I gave that answer. Though it IS a common trap, its hardly a guiding principle. Its like saying "Dont drive the car off the cliff" should be the first principle of driving. - Mostlyharmless
@Mostlyharmless: And as such the answer got voted down ;) - kigurai
@kirugai: lol, i expected it to get a few down votes (okay as long as it makes some tired programmer smile)... what i did not expect was for it to get three up votes. - Mostlyharmless
[-6] [2008-10-01 19:10:26] dacracot
0 + 1 = 1
1 + 1 = 10
10 + 1 = 11
11 + 1 = 100
100 + 1 = 101
101 + 1 = 110

Get it?

Can't vote down right now. But will do :D - pongba
Don't like my humor? Ok, but it is a real answer. The "founding fathers" of programming coded in binary. The first principle of programming is binary. Its all based on binary. Get it? - dacracot
We don't need to get it anymore. That's why they invented assembly, C, C++ and all the other high level languages. Binary can take a hike. ;) - Jeff Yates
There's no practical gain in knowing that, because it's too basic and simple to be constructive in any scenario. And because everybody knows it. - pongba
Oh really! Tell that to the engineers at Intel who created a math error...… - dacracot
Problem is, the reason they screwed up wasn't because they didn't know binary arithmetic, so.. - pongba
I suppose you speak Latin too? - CAD bloke
I agree that this isn't a great answer, but -5!? I find that an understanding the underlying machine does tend to make one a better programmer. Of course, that doesn't mean that we should program in raw 1's and 0's. - Steve S