97 T hing s E ve ry Prog ra mme r Should Know http:/ / pr o gr - - PowerPoint PPT Presentation

97 T hing s E ve ry Prog ra mme r Should Know

http:/ / pr

• gr

amme r .97things.o r e illy.c o m @97T E PSK

Ke vlin He nne y

ke vlin@c ur br alan.c o m @Ke vlinHe nne y

Adria n Wible Ala n Griffiths Ale x Mille r Alla n Ke lly Ande rs Norå s Ann Ka trin Ga g na t Asla m Kha n Burk Hufna g e l Ca l E va ns Ca rroll Robinson Ca y Horstma nn Chuc k Allison Clint Sha nk Da n Be rg h Johnsson Da n North Da nie l L indne r Diomidis Spine llis E dwa rd Ga rson E ina r L a ndre F ilip va n L a e ne n Ge ra rd Me sza ros Gile s Colborne Giova nni Asproni Gre g Colvin Gre g or Hohpe

Gudny Hauknes

He inz Ka butz Ja n Christia a n "JC" va n Winke l Ja ne t Gre g ory Ja son P Sa g e Joha nne s Brodwa ll Jon Ja g g e r Jø rn Ølmhe im Ka ri Rø ssla nd Ka ria nne Be rg Ke ith Bra ithwa ite Ke vlin He nne y Kirk Pe ppe rdine Kla us Ma rqua rdt L inda Rising Ma rc us Ba ke r Ma tt Doa r Ma ttia s Ka rlsson Mic ha e l F e a the rs Mic ha e l Hung e r Mike L e wis Na te Ja c kson Ne a l F

• rd

Nic la s Nilsson Olve Ma uda l

Paul W Homer Pete Goodliffe

Pe te r Somme rla d Ra jith Atta pa ttu Ra ndy Sta fford Ric ha rd Monson- Ha e fe l Robe rt C Ma rtin (Unc le Bob) Rod Be g bie Russe l Winde r Rya n Brush Sa m Sa a riste Sa ra h Mount Sc ott Me ye rs Se b Rose Ste ve Be rc zuk Ste ve F re e ma n Ste ve Smith T homa s Gue st Udi Da ha n Ve rity Stob Wa lte r Brig ht Ye c hie l Kimc hi Yuriy Zuba re v

Ac t with Prude nc e Apply F unc tiona l Prog ra mming Princ iple s Ask "Wha t Would the Use r Do?" (You Are Not the Use r) Automa te Your Coding Sta nda rd Be a uty Is in Simplic ity Be fore You Re fa c tor Be wa re the Sha re T he Boy Sc out Rule Che c k Your Code F irst Be fore L

• oking to Bla me Othe rs

Choose Your T

• ols with Ca re

Code in the L a ng ua g e of the Doma in Code Is De sig n Code L a yout Ma tte rs Code Re vie ws Coding with Re a son A Comme nt on Comme nts Comme nt Only Wha t the Code Ca nnot Sa y Continuous L e a rning Conve nie nc e Is Not a n –ility De ploy E a rly a nd Ofte n Disting uish Busine ss E xc e ptions from T e c hnic a l Do L

• ts of De libe ra te Pra c tic e

Doma in- Spe c ific L a ng ua g e s Don't Be Afra id to Bre a k T hing s Don't Be Cute with Your T e st Da ta Don't Ig nore T ha t E rror! Don't Just L e a rn the L a ng ua g e , Unde rsta nd its Culture Don't Na il Your Prog ra m into the Uprig ht Position Don't Re ly on "Ma g ic Ha ppe ns He re " Don't Re pe a t Yourse lf Don't T

• uc h T

ha t Code ! E nc a psula te Be ha vior, Not Just Sta te F loa ting - Point Numbe rs Are n't Re a l F ulfill Your Ambitions with Ope n Sourc e T he Golde n Rule of API De sig n T he Guru Myth Ha rd Work Doe s Not Pa y Off How to Use a Bug T ra c ke r Improve Code by Re moving It Insta ll Me Inte r- Proc e ss Communic a tion Affe c ts Applic a tion Re sponse T ime Ke e p the Build Cle a n Know How to Use Comma nd- line T

• ols

Know We ll More tha n T wo Prog ra mming L a ng ua g e s Know Your IDE Know Your L imits Know Your Ne xt Commit L a rg e Inte rc onne c te d Da ta Be long s to a Da ta ba se

Learn Foreign Languages

L e a rn to E stima te L e a rn to Sa y "He llo, World" L e t Your Proje c t Spe a k for Itse lf T he L inke r Is Not a Ma g ic a l Prog ra m T he L

• ng e vity of Inte rim Solutions

Ma ke Inte rfa c e s E a sy to Use Corre c tly a nd Ha rd to Use Inc orre c tly Ma ke the Invisible More Visible Me ssa g e Pa ssing L e a ds to Be tte r Sc a la bility in Pa ra lle l Syste ms A Me ssa g e to the F uture Missing Opportunitie s for Polymorphism Ne ws of the We ird: T e ste rs Are Your F rie nds One Bina ry Only the Code T e lls the T ruth Own (a nd Re fa c tor) the Build Pa ir Prog ra m a nd F e e l the F low Pre fe r Doma in- Spe c ific T ype s to Primitive T ype s Pre ve nt E rrors T he Profe ssiona l Prog ra mme r Put E ve rything Unde r Ve rsion Control Put the Mouse Down a nd Ste p Awa y from the Ke yboa rd Re a d Code Re a d the Huma nitie s Re inve nt the Whe e l Ofte n Re sist the T e mpta tion of the Sing le ton Pa tte rn T he Roa d to Pe rforma nc e Is L itte re d with Dirty Code Bombs Simplic ity Come s from Re duc tion T he Sing le Re sponsibility Princ iple Sta rt from Ye s Ste p Ba c k a nd Automa te , Automa te , Automa te T a ke Adva nta g e of Code Ana lysis T

• ols

T e st for Re quire d Be ha vior, Not Inc ide nta l Be ha vior T e st Pre c ise ly a nd Conc re te ly T e st While You Sle e p (a nd ove r We e ke nds) T e sting Is the E ng ine e ring Rig or of Softwa re De ve lopme nt T hinking in Sta te s T wo He a ds Are Ofte n Be tte r tha n One T wo Wrong s Ca n Ma ke a Rig ht (a nd Are Diffic ult to F ix) Ubuntu Coding for Your F rie nds T he Unix T

• ols Are Your F

rie nds Use the Rig ht Alg orithm a nd Da ta Struc ture Ve rbose L

• g g ing Will Disturb Your Sle e p

WE T Dilute s Pe rforma nc e Bottle ne c ks Whe n Prog ra mme rs a nd T e ste rs Colla bora te Write Code a s If You Ha d to Support It for the Re st of Your L ife Write Sma ll F unc tions Using E xa mple s Write T e sts for Pe ople You Gotta Ca re About the Code Your Custome rs Do Not Me a n Wha t T he y Sa y

Ac t with Prude nc e Apply F unc tiona l Prog ra mming Princ iple s Ask "Wha t Would the Use r Do?" (You Are Not the Use r) Automa te Your Coding Sta nda rd Be a uty Is in Simplic ity Be fore You Re fa c tor Be wa re the Sha re T he Boy Sc out Rule Che c k Your Code F irst Be fore L

• oking to Bla me Othe rs

Choose Your T

• ols with Ca re

Code in the L a ng ua g e of the Doma in Code Is De sig n Code L a yout Ma tte rs Code Re vie ws Coding with Re a son A Comme nt on Comme nts Comme nt Only Wha t the Code Ca nnot Sa y Continuous L e a rning Conve nie nc e Is Not a n –ility De ploy E a rly a nd Ofte n Disting uish Busine ss E xc e ptions from T e c hnic a l Do L

• ts of De libe ra te Pra c tic e

Doma in- Spe c ific L a ng ua g e s Don't Be Afra id to Bre a k T hing s Don't Be Cute with Your T e st Da ta Don't Ig nore T ha t E rror! Don't Just L e a rn the L a ng ua g e , Unde rsta nd its Culture Don't Na il Your Prog ra m into the Uprig ht Position Don't Re ly on "Ma g ic Ha ppe ns He re " Don't Re pe a t Yourse lf Don't T

• uc h T

ha t Code ! E nc a psula te Be ha vior, Not Just Sta te F loa ting - Point Numbe rs Are n't Re a l F ulfill Your Ambitions with Ope n Sourc e T he Golde n Rule of API De sig n T he Guru Myth Ha rd Work Doe s Not Pa y Off How to Use a Bug T ra c ke r Improve Code by Re moving It Insta ll Me Inte r- Proc e ss Communic a tion Affe c ts Applic a tion Re sponse T ime Ke e p the Build Cle a n Know How to Use Comma nd- line T

• ols

Know We ll More tha n T wo Prog ra mming L a ng ua g e s Know Your IDE Know Your L imits Know Your Ne xt Commit L a rg e Inte rc onne c te d Da ta Be long s to a Da ta ba se

Learn Foreign Languages

L e a rn to E stima te L e a rn to Sa y "He llo, World" L e t Your Proje c t Spe a k for Itse lf T he L inke r Is Not a Ma g ic a l Prog ra m T he L

• ng e vity of Inte rim Solutions

Ma ke Inte rfa c e s E a sy to Use Corre c tly a nd Ha rd to Use Inc orre c tly Ma ke the Invisible More Visible Me ssa g e Pa ssing L e a ds to Be tte r Sc a la bility in Pa ra lle l Syste ms A Me ssa g e to the F uture Missing Opportunitie s for Polymorphism Ne ws of the We ird: T e ste rs Are Your F rie nds One Bina ry Only the Code T e lls the T ruth Own (a nd Re fa c tor) the Build Pa ir Prog ra m a nd F e e l the F low Pre fe r Doma in- Spe c ific T ype s to Primitive T ype s Pre ve nt E rrors T he Profe ssiona l Prog ra mme r Put E ve rything Unde r Ve rsion Control Put the Mouse Down a nd Ste p Awa y from the Ke yboa rd Re a d Code Re a d the Huma nitie s Re inve nt the Whe e l Ofte n Re sist the T e mpta tion of the Sing le ton Pa tte rn T he Roa d to Pe rforma nc e Is L itte re d with Dirty Code Bombs Simplic ity Come s from Re duc tion T he Sing le Re sponsibility Princ iple Sta rt from Ye s Ste p Ba c k a nd Automa te , Automa te , Automa te T a ke Adva nta g e of Code Ana lysis T

• ols

T e st for Re quire d Be ha vior, Not Inc ide nta l Be ha vior T e st Pre c ise ly a nd Conc re te ly T e st While You Sle e p (a nd ove r We e ke nds) T e sting Is the E ng ine e ring Rig or of Softwa re De ve lopme nt T hinking in Sta te s T wo He a ds Are Ofte n Be tte r tha n One T wo Wrong s Ca n Ma ke a Rig ht (a nd Are Diffic ult to F ix) Ubuntu Coding for Your F rie nds T he Unix T

• ols Are Your F

rie nds Use the Rig ht Alg orithm a nd Da ta Struc ture Ve rbose L

• g g ing Will Disturb Your Sle e p

WE T Dilute s Pe rforma nc e Bottle ne c ks Whe n Prog ra mme rs a nd T e ste rs Colla bora te Write Code a s If You Ha d to Support It for the Re st of Your L ife Write Sma ll F unc tions Using E xa mple s Write T e sts for Pe ople You Gotta Ca re About the Code Your Custome rs Do Not Me a n Wha t T he y Sa y

Do L

• ts of De libe ra te Pra c tic e

Jo n Jagge r

You do deliberate practice to improve your ability to perform a

• task. It’s about skill and technique. Deliberate practice means
• repetition. It means performing the task with the aim of

increasing your mastery of one or more aspects of the task. It means repeating the repetition. Slowly, over and over again, until you achieve your desired level of mastery. You do deliberate practice to master the task, not to complete the task.

L e a rn to E stima te

Gio vanni Aspr

• ni

An estima estimate te is an approximate calculation or judgement of the value, number, quantity, or extent of something. This definition implies that [...] hopes and wishes must be ignored when calculating it. The definition also implies that, being approximate, an estimate cannot be precise, e.g., a development task cannot be estimated to last 234.14 days. A tar target et is a statement of a desirable business objective, e.g., “The system must support at least 400 concurrent users.” A commitment commitment is a promise to deliver specified functionality at a certain level of quality by a certain date or event.

Know Your Ne xt Commit

Dan Be r gh Jo hnsso n

I tapped three programmers on their shoulders and asked what they were doing. “I am refactoring these methods,” the first answered. “I am adding some parameters to this web action,” the second answered. The third answered, “I am working on this user story.” It might seem that the first two were engrossed in the details of their work, while only the third could see the bigger picture, and that he had the better

• focus. However, when I asked when and what they would commit, the picture

changed dramatically. The first two were pretty clear about what files would be involved, and would be finished within an hour or so. The third programmer answered, “Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way.”

Comme nt Only Wha t the Code Ca nnot Sa y

Ke vlin He nne y

• 1. If a program is incorrect, it matters little what the documentation

says.

• 2. If documentation does not agree with the code, it is not worth much.
• 3. Consequently, code must largely document itself. If it cannot,

rewrite the code rather than increase the supplementary

• documentation. Good code needs fewer comments than bad code does.
• 4. Comments should provide additional information that is not readily
• btainable from the code itself. They should never parrot the code.
• 5. Mnemonic variable names and labels, and a layout that emphasizes

logical structure, help make a program self‐documenting. Kernighan and Plauger The Elements of Programming Style

Code in the L a ng ua g e of the Doma in

Dan No r th

if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) { ... } if (trader.canView(portfolio)) { ... }

Pre fe r Doma in- Spe c ific T ype s to Primitive T ype s

E inar L andr e

Phillip Calçado

http://fragmental.tw/2009/04/29/tag-clouds-see-how-noisy-your-code-is/

Re sist the T e mpta tion of the Sing le ton Pa tte rn

Sam Saar iste

Don't Re pe a t Yourse lf

Ste ve Smith

Duplication Is Waste Duplication Is Waste Repetition in Process Calls Repetition in Process Calls for Automation for Automation Repetition in Logic Calls Repetition in Logic Calls for Abstraction for Abstraction

Be wa re the Sha re

Udi Dahan

The fact that two wildly different The fact that two wildly different parts of the system parts of the system performed some logic in performed some logic in the the same way same way meant less than I meant less than I

• thought. Up
• thought. Up until I

until I had had pulled out pulled out those libraries of those libraries of shared shared code, these parts were code, these parts were not depen not dependent on dent on each other. Each could each other. Each could evolve independently. Each could change its logic to evolve independently. Each could change its logic to suit the suit the needs of needs of the the system’s changing business environment. Those system’s changing business environment. Those four four lines of lines of similar code similar code were were accidental—a temporal accidental—a temporal anoma anomaly, a ly, a coincidence. That

• coincidence. That is, until I

is, until I came along. came along.

T he Roa d to Pe rforma nc e Is L itte re d with Dirty Code Bombs

Kir k Pe ppe r dine

MORE OFTEN THAN NOT, PERFORMANCE TUNING A SYSTEM REQUIRES YOU TO ALTER

• CODE. WHEN WE NEED TO ALTER CODE,

EVERY CHUNK THAT IS OVERLY COMPLEX OR HIGHLY COUPLED IS A DIRTY CODE BOMB LYING IN WAIT TO DERAIL THE EFFORT. THE FIRST CASUALTY OF DIRTY CODE WILL BE YOUR SCHEDULE.

T he L

• ng e vity of Inte rim Solutions

Klaus Mar quar dt

T he Boy Sc out Rule

Ro be r t C Mar tin (Unc le Bo b)

Try and leave this world a little better than you found it.

Robert Stephenson Smyth Baden-Powell

T wo Wrong s Ca n Ma ke a Rig ht (a nd Are Diffic ult to F ix)

Allan Ke lly

Re a d Code

Kar ianne Be r g

We programmers are weird creatures . We love writing code. But when it comes to reading it, we usually shy away. After all, writing code is so much more fun, and reading code is hard—sometimes almost impossible. Reading other people’s code is particularly hard. Not necessarily because other people’s code is bad, but because they probably think and solve problems in a different way than you.

Write T e sts for Pe ople

Ge r ar d Me szar

• s

So So who who should you be should you be writi writing the tests for? g the tests for? For the For the person tryin person trying to g to underst understan and your code. your code. Good tests act as Good tests act as docume documentat ation for for the code they are the code they are testi

• testing. They
• g. They descri

describe be how how the code works. For each the code works. For each usage scenario, the test(s): usage scenario, the test(s):

• Describe the context,

Describe the context, starti starting poin g point, or t, or preconditions that must be preconditions that must be satisfied satisfied

• Illust

Illustrate rate how the software how the software is invoke is invoked

• Des

Describe t ribe the expec he expected r ted results lts o

• r po

postconditio conditions ns to be verifi be verified ed Di Differ ferent u ent usage s age scenarios wi enarios will have sligh have slightly ly diffe differen rent version versions of each

• f each of these
• f these.

Don't Be Cute with Your T e st Da ta

Ro d Be gbie

Ubuntu Coding for Your F rie nds

Aslam Khan

Umuntu ngumuntu ngabantu

The newest computer can merely compound, at speed, the oldest problem in the relations between human beings, and in the end the communicator will be confronted with the old problem, of what to say and how to say it.

Edward R Murrow