What are DRY, KISS and YAGNI principles?


These three principles (DRY, KISS and YAGNI) are widely cited in web .

What are they? Who created them? How and where can they be applied?

asked by anonymous 01.07.2014 / 14:04

3 answers


DRY - Do not Repeat Yourself

If you use a lot of repetitions, you do not have full knowledge of the subject, ie you're rolling. Thinking about just not repeating the code does not mean you're fully using DRY , we have to work on logic too.

describe "Person#full_name" do
it "concats the first and last names" do
first_name = "John"
last_name = "Doe"
person = Person.new(:first_name => first_name, :last_name => last_name)
person.full_name.should eq "#{first_name} #{last_name}"

Above is the use of the DRY philosophy and below is not.

describe "Person#full_name" do
it "concats the first and last names" do
person = Person.new(:first_name => "John", :last_name => "Doe")
person.full_name.should eq "John Doe"

But second David Chelimsky ( link ), to follow this religiously may perhaps undermine the readability of the code.

YAGNI - You Are not Gonna Need It

This is the philosophy of You will not need it , I often put functions that were not needed in my system at the time, so what started to happen? People calling and asking. "What's this for?" In addition to reworking people and removing or disabling the view, this can lead to unnecessary processing. I've heard a lot of people saying: "What do you really need?" Go to a tip below:

"If it's cheap to do now and cheap then leave it for later. If it's cheap now, but it will be expensive later, do it now." ( link )

KISS - Keep It Simple, Stupid

Here where I work, I have a colleague who has many years of algorithms, he developed MUMPS , his nickname is Jacare, I'll tell him to enter the stackoverflow, I do not know if he wants to, but that's okay. He always taught me that we should do the simple, interesting thing is to see from the client side, even because I worked a period of my life as support. The customer does not know what is behind a beautiful screen, he simply wants to see everything working and why complicate and invent the wheel when we can do the simple in record time and with a good logic. Alligator always talks about doing the simple, but always makes a crazy code.

Certainly there will be people who disagree with these philosophies, but my main tip is:

Everything that is too much is wrong.

01.07.2014 / 15:04

Some basic rules to make your work easier, especially with regard to maintenance.

The meaning of each is:

  • DRY: Do not Repeat Yourself . Do not repeat yourself. Suppose the effort to fix a bug for a normal programmer is X. For a programmer who copies and pastes the same code into several different parts of the program, the effort is X times the number of copies of the same stretch. li>

Some people say that programming is similar to composing music. This is no excuse for putting a chorus in your code.

The two codes below, in Javascript, do the same thing:

// código escrito por um moleque, a mando de satã
var result = 2;
var temp = result;
for (var i = 0; i < 5; i++) {
    result *= temp;
if (result == 0) result = 1; // tratando exponenciação por zero


// código que não reinventa a roda, fácil de ler e que resolve o problema
Math.pow(2, 5);

Which do you prefer to maintain?

  • YAGNI: You Are not Gonna Need It . Literally, "you will not need it." It is a way of saying that if a code does nothing, give it a use or delete it from the repository. I like to apply also to comments that are not useful. It means you should not bother coding something, until you really need it. If you're going to code something because you think you'll need more ahead, you may end up finding out that you did not really need it, and then the time you spent with the component was lost. (thanks to Casali and Omni for the correction!)
01.07.2014 / 14:51


Do not Repeat Yourself: It is very popular in the community and for those who develop with Ruby / Rails, it is part of the fundamental principle that something that is already created must NEVER be repeated. There comes the name (Do not repeat yourself!). In other words, define a method, property in one place and reuse it, in any other !!. Look at the example that the wiki on the rails page gives:


For example, instead of having a Person table and a Person class, with a property, a getter method and a setter for each field in the table, you have only the bank of data. The required properties and methods are "injected" into the class through Ruby language features.


I do not know the definition very well, but from what I saw is the following. As the name itself (acronym) says you should keep it simple, Keep it simple, stupid! , (some authors use it without the comma or com, eventually they do not have a standard for it!), Anyway any complexity "should" be avoided , ie it does not have to be complex if it can be simple!


This principle says that you should only implement something, WHEN YOU REALLY WILL USE IT, not when you think you will use it later!

The names are very suggestive and the principles are very simple, but that in day-day, who can implement them the right way, has a code agile, simple, effective and beautiful! Get the sources (wikiiii!) To get into more details on each of them!


  • wikipedia dry
  • wikipédia kiss
  • wikipédia yagni
  • 01.07.2014 / 14:45