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

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

And - style matters.

share

Do one thing, and do it well. It's the UNIX philosophy (http://en.wikipedia.org/wiki/Unix_philosophy). It works at every layer.

share

When in doubt, manipulate the data!

share

BE SMART AND LAZY

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.

share

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

share

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.

share

Abstraction, Composition

share

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.

share

It doesn't exist unless it's committed.

share

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"

share
  1. Think First
  2. See 1.
share

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.

share

Don't be stupid on purpose

share

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

share

I think that one consequence of the Church-Turing thesis 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.

share
    
I don't know that that's the "first principle", but it's a good one. – Jay Aug 25 '09 at 15:44

No infinite loops.

share
    
And if you are a video game programmer? – Ed S. Oct 1 '08 at 19:11
    
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 Oct 1 '08 at 19:14
    
The guitar metaphor is way off the track, IMO :P – pongba Oct 1 '08 at 19:16
    
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 Oct 1 '08 at 19:16
    
@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 Oct 1 '08 at 19:22

Do not overuse Interface.

share
    
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 Oct 1 '08 at 19:17
1  
This one is too language-specific – finnw Oct 2 '08 at 1:07

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

share
  1. Don't do it.
  2. If not doing it isn't possible, get someone else to do it.
share

In general: Problem solving.

That is what it all boils down to.

share
    
And what's the 1st principle(s) of Problem Solving, again? – pongba Oct 1 '08 at 19:20
    
That's what everything boils down to. So if you think about it, we don't gain anything from this perspective. – pongba Oct 1 '08 at 19:32
    
@pongba: So it is an answer as useless as the question then? Perfect. – GEOCHET Oct 1 '08 at 20:20
    
I don't think the question is useless, especially judging by the cute answers :) – pongba Oct 2 '08 at 2:50

Progamming is not for the lonely geek.

share

Structured Programming

share

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.

share
    
I like this one. Don't just assume, especially not unconsciously. – pongba Oct 2 '08 at 2:55

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.

share

Humbleness.

share

making it bug free.

share
    
but everybody makes crappy buggy software!! codinghorror.com/blog/archives/000099.html – Broken_Window Jul 31 '09 at 18:41

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.

share

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.

share

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

share
    
There's no such thing as 2. Maybe you meant 10 / 10. – ojrac Jul 31 '09 at 18:55

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