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 don't know if this is a question, or a start of a conversation or even a completely irrelevant topic.

Why isn't programming more standardised?

Im really new to this and I find it hellish difficult to find the answer to even basic questions. Things like--

  • How do I add validation to multiple texboxes in c# without using individual validation controls?
  • How do I add the input of a texbox to an ongoing array?

I'm talking about fundamental things that get used all the time. I would expect answers like "oh yeah, see jones' validation method (link) or peters' textbox to array function (link).

I just thought there would be standard techniques, like in chess, for doing things that are similar.

I hope this makes sense and someone can point me in the right direction if there ARE directories of standard programming technniques.

share|improve this question

migrated from Apr 28 '11 at 20:11

This question came from our site for professional and enthusiast programmers.

Because there are too many ugly languages. It starts to suck from the head. – Job May 4 '11 at 3:28

There are "standard" ways of doing things in programming, just as well as there are "standards" in e.g. jazz.

However, just as no jazz standard is ever going to be played twice the same way, no standard programming solution is going to ever be applied twice the same way. The context, the players, the mood always has an effect on how a piece of melody is improvised upon. The same way as the context, the platform, the programming language and a myriad of concrete details affects how a programming solution is going to be applied this time.

Some of the "standards" in programming are called design patterns, e.g. Adapter. Others are programming idioms, such as iterating over a collection; best practices, such as Test Driven Development; or methodologies, such as Scrum. However, each of these can be implemented in a million different ways. The concrete form of iterating over a collection differs in C++ and Java. The way Scrum is applied is quite different for a one-person team working with legacy embedded code vs a 20-strong team developing a greenfield enterprise web app. And so on.

As per the famous quote, "there is no silver bullet" in software development. All of the above are like specific tools in one's toolbox: useful when used the right time in the right manner and to the right extent, useless (or even harmful) otherwise. So common sense, personal/team judgment and experience is required to use any of these to the best effect. Blindly copying and applying them without due consideration probably does more harm than good.

share|improve this answer
+1: "Blindly copying and applying them without due consideration probably does more harm than good" that's the meat and potatoes of it right there. – Binary Worrier Apr 29 '11 at 10:41

A lot of things aren't standardized because there are so many ways to do the same thing that could be right in different circumstances.

Take your innocuous example of validating multiple textboxes. We all do it, should be straightforward, right?

Well let me point you to which is a classic paper describing how to solve that exact kind of problem in Smalltalk using the MVC paradigm. It handles a hard generalization of your problem, but assumes that you're working in a standalone application. It would take serious thought to apply it to a web environment. (That particular solution is the original root of Microsoft's Model-View-Presenter paradigm, which is used to solve a very different problem from validation.)

OK, we want to work in a web environment. There are a lot of technology stacks in a web environment. Like it or not, validation is closely tied to how we organize the generation of web pages. Which means that if I'm using a different technology stack than you (I am actually, I don't use any Microsoft technologies at all), then a design pattern that works for me is likely to be different from one that will work for you.

OK, let's say that we're working in the same technology stack. We can validate on the server side. Optionally validate in JavaScript. (You still need to validate on the server side because you never, ever, ever want to trust the client.) Suppose that I have a standard validation technique that I've come up with that lets me validate that numbers are going into numerical things, certain text boxes have stuff entered, but not too much, etc. It is simple, fast, easy and very good. For each text box you just specify a type and parameters and voila, you have validation.

Now suppose that you have two text fields that are supposed to be a range. So the valid in the one has to be less than or equal than the value in the other. My little validation mechanism looks at just one text box at a time. It has no way to look at two at once and compare them. You start to dive in and try to fix that, and realize that you'll have to rewrite a big chunk of it. What I wrote wasn't bad. But it doesn't work for your use case. Guess what? You'll need to take a very different approach than what I did. And when you've solved that problem, if you show it to me, it will be bad for me because it forces more complexity on what is, for me, a trivial operation.

Luckily it isn't a lost cause. Every codebase develops its own standards for how to handle lots of different kinds of problems. Many of those standards are shared with a wider community. Many more are private to that organization and that codebase.

But now suppose that you work for a company who has solved this problem. Then you're on a site like this, and someone says, "I need to validate a bunch of textboxes, how do I do it?" You know how to do it, you do it every day. But for legal reasons you can't just cut and paste your validation stuff. And your validation stuff is tied to the object-relational mapper that you're using, so even if you were willing to share, they can't easily use it without pulling in a lot more of your infrastructure. And the result is that, even though you are sitting there with a working answer to the questioner's problem, you can't just tell them, "Do this."

(Note that if you're using popular open source code, the odds of being able to share go up, and so do the odds that the other person already has the right dependencies go up. This is one of the appeals of open source.)

share|improve this answer
+1 for illuminating the problem with real-world examples. – Péter Török Apr 29 '11 at 7:49

This question is more philosophic than technical so I will answer that way...

Probably because programming per se is somewhat similar to art.

Every programmer find its own way of doing something that fits his imagination and needs at that point in time.

Standardization is OK, but not too much of it, because it subtracts from the programmers imagination, and would lead to programmers not being artists in any way, but programming machines.

A good middle point is ok because it leads to innovations from a much larger audience of programmers (read not only from those writing standards) while retaining compatibility between 'programming genres'.

Those 'small programmer' innovations sometimes become standards if they are found good enough.

share|improve this answer
I prefer to talk about programming as a craft rather than an artform. Most programming is done for business and having artists "producing value for shareholders" seems a bit far fetched to me. – Martin Wickman Apr 28 '11 at 21:30
@Martin, let's call it applied art then - think about an architect. – Péter Török Apr 29 '11 at 9:09
@Péter, why involve aesthetics at all? I don't think architecture has anything to do with programming. – Martin Wickman Apr 29 '11 at 10:13
@Martin, an elegant programming solution or a good design is not just efficient, clean, simple etc. - it is aesthetically pleasing to me (and I am not the only one to have felt this - several books have mentioned this, although I can't give you exact quotes). This is the same as the deep pleasure mathematicians feel upon seeing an elegant proof for a theorem. Of course, you may debate whether it has to do with aesthetics - to me it doesn't matter how you call it, it is the same feeling. – Péter Török Apr 29 '11 at 10:16
@Péter, yes our work can be aesthetic, but that can be said about any work a human does (be it flipping burgers, solving equations or driving the bus) but that doesn't make it an art. Labeling programming art and programmers as artists is blowing things out of proportions, and making it more than it really is. I think it's more about "petting our own egos and make our job seem elevated and dignified" (link). Programming is a profession involving skillful craftsmanship, and our customers sure doesn't want to pay for our work as they would an artist. – Martin Wickman Apr 29 '11 at 11:46

There are so many use cases in programming that there is just no way someone creating the documentation on a subject can mention them all. For example your

"How do I add the input of a texbox to an ongoing array?"

question. Instead of asking such a specific question, ask instead:

"How do I add an element to an aray?"

That's a simply answered question that you can find anywhere. But then again it depends: What language? What kind of array? Dynamic, or static? How many elements can it hold?

It just takes experience and time to learn your way around, but eventually you find most problems have a very simple generic question at the root. Identify that question and you r are much more likely to find an answer.

share|improve this answer
Exactly, thats te problem for us noobs trying to find info...what is the correct question? There are so many times in programms where pretty much the exact same thing is happening...I just thought there would be names for them...maybe im just beiong 'noob'..:) – Dylan Jackson Apr 28 '11 at 20:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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