What is the best way to write it? Whatever is best for the program itself and best for the programmers.
Be just as careful with with minor code as with major code, as you don't know in the end which will be more important.
Consider what you lose when not writing the code properly against its gains, and consider the benefits of a poor implementation against what it loses.
Focus on three things and you will avoid code repetition: Know what other code exists, others will review your code, the code will exist for a long time.
It's best to write code for the customer's demands, they will overlook its negative qualities.
Code that's not written for those buying it will be for naught, and improving it will lead to code repetition.
Those writing for a community should write the code for its own sake, those that came before you will help you.
You will end up getting credit for the work that gets added on as if you yourself did it.
Be wary of standards bodies or other organizations, since they only recruit people for their own agenda.
They will act like they love you when it is to their advantage, but they will not stand by you when you need it.
Desire what the community wants, and the community will want what you desire.
Do what they want instead of what you want, and other programmers will desire what you desire.
Don't alienate the community.
Don't trust code till the code is about to be recycled.
Don't judge an implementation till you try to implement it yourself.
Don't do something that is unaccepted hoping it will eventually be accepted.
Don't plan to only write it properly later, maybe you won't.
An idiot doesn't care about code repetition.
One who is unlearned will never be a hero.
One who is embarrassed will never learn.
One who is always angry and demanding can't teach.
Those who solely focus on making money will never be more than an idiot.
Wherever there is no one else to write the code, you write it.
The master who invented the above statement once looked at a hack being recycled, and stated:
Since this hack replaced an older hack, it itself got replaced, and the hack replacing it will also be replaced.
One who increases code size increases bugs.
One who increases features increases worry.
One who increases threads increases overhead.
One who increases processes increases communication layers.
One who increases the amount of code they solely enjoy increases black magic in the code.
One who increases usefulness of the code increases its lifespan.
One who increases the amount of thought put into writing the code increases its intelligence.
One who increases his own agenda only does so for himself.
One who increases usefulness for the sake of the community will earn for himself everlasting gratitude.
If you write a lot of code, don't view yourself as so special, because it is for this reason you became a programmer.
The master who invented the above statement had five students.
The first was someone who never overlooked a detail.
The second always looked to the source of the issue.
The third was a hero.
The fourth always avoided code repetition.
The fifth was always increasing his own understanding and knowledge of techniques.
The master said of his first student, if we weighed him against everyone else out there, his abilities would outweigh them all.
Another master said, if the fifth student was weighed against the other four, his abilities would outweigh them all.
The master asked his students: What is the best trait for becoming a good programmer?
The first answered: One who carefully checks his code.
The second answered: One who has a good friend to bounce ideas off of.
The third answered: One who sees the needs of those around him.
The fourth answered: One who anticipates future needs.
The fifth answered: One who desires to write the best code he can.
The master stated, the fifth answered best, as his answer includes all the others.
The master then asked his students: What should a good programmer avoid?
The first answered: Ignoring what is going on in the code.
The second answered: Idiot friends.
The third answered: A weak community.
The fourth answered: Allocating resources without freeing them.
The fifth answered: Becoming complacent in his understanding of what is best.
The master stated, the fifth answered best, as one who becomes complacent will end up with what everyone else answered.
Stick up for your fellow programmers as you would for yourself.
Don't get angry easily.
Fix the code before the problem is apparent.
Enjoy the fire of clever code, but be careful lest you be burned by it.
Bad analyzing, no desire for good code, and hating your community will all cause one's code to be thrown away.
Managing resources you allocate should be as important to you as managing the resources you already have.
Perfect your programming abilities, as this is what a programmer is.
All your code should be written for its own sake.
Be meticulous in learning about what you need to accomplish, and the tools necessary to do so.
Don't make the theory of prime importance.
Don't underestimate yourself, and don't think your work will only be minor.
Have a good answer ready for those who may find issues with your code.
Understand your customer.
Understand your employer.
The day may be short, but there's a lot of work to be done.
Programmers are lazy, even though their programs do much.
The boss is demanding.
You don't have to do all the work by yourself, you don't have to finish every last bit of it.
You however can't leave the code in disarray.
If you write a lot of good code, you'll be properly compensated for it.
Believe that those who employ you will compensate you for your effort.
Know that those who put in the effort will be compensated greatly in years to come, even if not initially.
Monday, May 25, 2009
Ancient coding ideas finally in English - Part 2
Labels: Ancient Coding Ideas