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

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

And - style matters.

share
add comment

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

When in doubt, manipulate the data!

share
add comment

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

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

share
add comment

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

Abstraction, Composition

share
add comment

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

It doesn't exist unless it's committed.

share
add comment

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
add comment
  1. Think First
  2. See 1.
share
add comment

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

Don't be stupid on purpose

share
add comment

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

share
add comment

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

No infinite loops.

share
show 8 more comments

Do not overuse Interface.

share
1  
This one is too language-specific –  finnw Oct 2 '08 at 1:07
show 1 more comment

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

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

In general: Problem solving.

That is what it all boils down to.

share
show 4 more comments

Progamming is not for the lonely geek.

share
add comment

Structured Programming

share
add comment

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

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

Humbleness.

share
add comment

making it bug free.

share
show 1 more comment

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

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

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

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