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?
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?
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}"
end
end
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"
end
end
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.
Some basic rules to make your work easier, especially with regard to maintenance.
The meaning of each is:
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
and
// 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?
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!
sources: