Sie sind auf Seite 1von 15

Código Limpo

d uas razões pelas qua i s você está lendo este livro : você é programador e deseja se tomar um

. ill l d a melhor. Ótimo . Precisamos de programadores melhores.

a p arti r

d e d ife re n t es

term inarm os, terem os um amplo co nhecimento sob re c ódigos e s eremo s c a pazes d e dist inguir

e n t r e um c ó digo bom e um c ó di g o ruim. Sa beremo s como e s crever um bom códig o e como to ma r um ru i m e m u m b om.

p e r s pe ctivas : d e b aixo par a c im a , de c i ma pa r a b a i x o e d e den tro p ara fora . Ao

Es te li v r o fala s obr e pr ogra m ação

e e st á repl eto d e c ó d igos qu e exa minar e m os

o Código

Po d e m

pr ogr ama ção de i x ou de se r um a p reocup ão e qu e devemos

está

próx im o; que l ogo todo có di go será gerado , e não ma i s escr i to. E qu e não prec i sarão mais de programadores , pois as pessoas criarão progra m as a partir de especificações. Bobagens! Nunca nos livraremos dos códigos, pois e l es represe n tam os d eta lh es dos

re q u i sitos . E m c e rto nível , não há c om o ign orar ou a bst rair esse s deta l hes; e l es precisam

ser es p e cifica d os. E especi f i car re qui s it os de talh adame nte d e m o do qu e u m a m á q u ina po ssa

exec u - Io s é programar - e t al espe c i fi cação é o código .

e re qui s i tos. Ou t r o s até mes m o alega m que o f i m do c ódi go , o u s eja , da p rogra mação,

di zer q u e um li vro so b re có d ig o s

é, d e c e rta form a , a lg o ultr apassad o ,

q u e a

nos p re o c upar c o m mode l os

 

Espe r o

q ue o n í v el

de de nossas li nguage n s

cont inu e a a umen tar e q u e o número de

l

inguagens

e s pecífi cas

a um domínio continue c r escendo. Isso será bom , mas o aca b ar á com

a

programação. D e fato , todas as especif i cações e scritas n essas l ing u agens de n í ve i s mais a l tos

e

específ i cas a u m d omín i o serão códigos! Eles pr ecisa r ã o ser m in uciosos , exatos e b as t ante

fo

r m ai s e detalha do s para qu e um a máquin a possa e n t endê-I os e ex e c u -Ios. As pe ssoas que p e n sa m qu e o códi go u m dia d esa parec erá s ão c omo matem á tic o s q ue

esperam algum dia d esco bri r u ma mate m áti c a qu e n ão pr e ci se ser form al. E las e spera m q ue

u m dia desc u bra m os

do que mandamos. Tais má q uinas terão de ser c a pa z es de nos ente nd e r tão bem d e mo do q ue

possam tr ad u zir ex i gências vagamente especi ficada s e m pr ogramas e xec u táve i s p erfe i tos p ara sat i sfaz er nossas ne cess i d ade s.

u ma form a de criar máq u i na s q ue p o ssa m fazer o qu e d ese j a m os em vez

Iss o jam a i s acont e c e r á.

N em m esmo o s sere s hum a nos, com to d a sua intuição e c r i a tivid ade,

têm s id o c a pazes d e cri ar s i stemas b e m- suce did os a partir d as carên c i as confu sas d e s e u s

c li entes . Na verda d e, se a m atéria so br e espec i f i cação

porque os requisitos bem especificad os são tão fo r m ais q uan to os c ó d igos e pod em agir como

tes t es execu t áveis d e ta i s có d igos!

de re qui s ito s n ão no s e n s i no u na d a , é

Lembr e - se d e qu e o có d i g o é a lingua gem n a qu a l ex pr e s sam os no s s os r e quisito s. P ode mos

c r i ar lingu a g e n s que se j a m mai s p róxim as a eles. Podemos criar ferramenta s que nos ajud em

a ana lisar a si nt ax e e un i r tai s re qui s itos em estrutura s forma i s . Mas j a mais elimin ar emo s

a

C ódigo ruim

R ec enteme nt e l i o pr efá cio do l i vr o Implementation

P a t t erns 1 d e Kent Beck, . a s e ia-se numa premissa

u n p o rta

no qual e l e diz "

este l i v ro

frágil de que um bom cód i go

" . Uma premissafrágil ? Não concordo ! A c h o

" u e essa premissa é uma das mais ro bu stas, apo i adas

~ p lenas do que todas as out r as em nossa área (e sei

: : ;:u eKent sabe disso). Estamos cientes de que u m bom

d i go importa , pois ti v emos de li dar com a falta dele ;x> r muito tempo. Le mbro que no final da d é ca d a d e 1980 u ma empresa :n o u um aplicati v o e x traordinário que se tomou muito ~

~ p u lar e muitos profis s ionai s o compraram e usaram .

_ I a s , então , o intervalo entre os lançamentos das no v as ~ - - t r i buições começou a aumentar . Os bug s não eram

:o n ser tados na distribuição

. :a r re g amento do aplicativo e o núm e ro d e travamentos

seguinte. E o tempo de

m n e ntaram . Lembro - me

do d i a em que , f r ustrado ,

mais o u s e i . A e mpre s a s aiu

_

: ~ h e i o programa e nunca

::o m e rcado logo depois . D uas décadas depoi s encontrei um do s func i onários d e tal e mpres a n a é poca e o p e rgunte i o e ha via acontec i do , e o que eu temia fora confirmado . E le s t i v eram d e a pr es sar o lançamen t o

~ p ro du t o e , devido a i s so , o código ficou uma zona . E nt ã o , c onforme foram adicion a ndo mais ~ m a is re cursos , o código piorava cada v e z ma i s até que simp l esmente nã o er a mai s po s v el

~cr e nc - lo. Foi o código ruim que a cabou com a empre s a. A lguma vez u m código r uim já l he atra s ou con s idera v e l mente ? Se v ocê for um programador ,

d e p endente de sua experiência , então já se deparou v árias vez es com e sse ob s tác u lo . A liás , é

: : or n o se caminhássemos penosamente por um lamaçal de arbustos e maranhados c om armadilhas

u l t as. Isso é o que fazemos num código ruim.

Pelejamos para encontrar nos s o caminho , do q u e e s tá aconte ce ndo ; mas tudo o que

; ; p e ra ndo avis t ar alg u ma dica , alguma in di cação

em os é um código cada ve z mais sem sen t ido. É c laro que um código ruim já lh e atrasou . M as, então , por que v ocê o esc r eveu des s a forma ?

: = ' :'- - m vtentandoa ser rápido? Es t a v a com pressa ? P ro v a ve lmente. Talvez v ocê penso u que não

- es s e tempo para fazer um bom t rabalho ; que seu ch e fe ficaria com raiv a se v ocê d e morass e po uco mais para li mpar se u cód i go . Tal v e z v ocê esta v a apena s cansado d e traba l har neste

;ro g r ama e que r ia terminá -I o l ogo. O u verificou a li sta d e coisas q u e h a v ia prometido fa z er e

: ; : êI c e beu q u e precisava finalizar este mód u lo de uma v ez , de modo que pudesse passar para o

: ; - : Ú x i mo. Todos j á fi z emos isso , j á vimos a b ag u nça que f i zemos e , então , optamos por arrumá - ~- o utro dia . Todos j á nos sent i mos a l iv i ados ao v ermos nosso programa conf u so f u ncionar e

~ i d imo s q ue u m a b agunça q u e fu n cio n a é me l hor do que nada . Todos nós já d i ssemos que

-e\i s a ríamos e l i m paríamos o código d epois. É claro q u e naq u ela época n ão conhecíamos a l e i

o Custo de Ter um Código Confuso

Se você é programador a mais de dois ou três anos, provavelmente o código confuso de outra pessoa já fez com que v ocê trabalhasse mais lentamente e provavelmente seu próprio código já lhe trouxe problemas.

de um ou dois anos, as equipes que

trabalharam rapidamente no início de um projeto podem perceber mais tarde que estão indo a passos de tartaruga. Cada alteração feita no código causa uma falha em outras duas ou três partes do mesmo código. Mudança alguma é trivial . Cada adição ou modificação ao sistema exige

que restaurações , amarrações e remendos sejam " entendidas" de modo que outras possam ser

inc l uídas. Com o tempo, a bagunça se toma tão grande e p rofunda que não dá para arrumá-Ia. Não há absolutamente solução alguma. Conforme a confusão aumenta, a produtividade da equipe diminui, assintoticamente

a gerência faz a única coisa que ela

aproximando - se de zero. Com a redução da produtividade,

pode ; adiciona mais membros ao projeto na esperança de aumentar a produtividade. Mas esses novos membros não conhecem o projeto do sistema, não sabem a diferença entre uma mudança

q u e altera o propósito do projeto e aquela que o at r apal h a. Ademais , eles, e todo o resto da

equipe , estão sobre tremenda pressão

e mais confusões, le v ando a produtividade mais perto ainda de zero (veja a Figura 1 . 1).

O ní v el de retardo pode ser significativo. Ao longo

para aumentar a prod u tividade. Com isso todos criam mais

100

~ 80

~ 60

-il 40

20

E

Q

O

Figura 1 . 1 Produtividade v. tempo

o Grande Replanejamento

~ o final , a equipe se rebela. Todos informam à gerência que não con s eguem mai s t rabalhar neste

i rr i t ante código - fonte e e x igem um r e plane j amen t o do projeto. Ap es ar de a ger ê ncia não querer

g as tar recu r so s e m uma no v a r e modela çã o , ela não pode negar que a p ro d ut i v idad e

~ o final da s cont as, ela acaba cedend o às ex i n cias do s desen v o lved or es e a ut or iza o grande

es tá p é ssima.

re

p lanejament o de se jado . É, ent ão, for m a d a uma no v a equip e esp e ci a li za d a. Por s er um pro j e t o in tei ra mente no v o ,

to

d os querem f a z er p a rt e de s sa equipe . El es d esej am co m ar do ze r o e c ria r algo b e l o d e ve rdade .

~ as apen a s o s melhores e mai s brilhant es são s eleci o nados e os o ut ros d everã o con t inuar n a

m a nuten ç ã o do si s tema atual . A gora ambo s os times estão numa co rrid a. A no v a equipe prec i s a co n str uir um no v o sistema

q u e faça o mesmo qu e o ant i go , al é m de ter de s e manter atuali z ada em r e laç ão à s mudanças

f e itas constant e m e nt e no sist e ma ant i go . Es t e, a ger ê n c ia não substituirá a té que o no v o possa

f a zer tudo tamb é m. Essa corrida pode durar um bom tempo . Já vi umas levarem 10 anos. E , quando ela termina ,

o membros originais da nova equ i pe já f oram embora há muito t e mpo, e os atu ais exigem o

r e p l a nejamento de um no v o sistema, pois está tudo um a zona novamente . Se você j á vi v enciou pelo menos um p o uco dessa situação , então sab e que d e dicar

t e m po para limpar seu código não é ap e n as ef i caz e m t ermos de cus t o , mas u ma questão de :o brev i ncia pro f is s i o na l .

o t eve de trabal har pe n osa m ente por u ma conf u o t ão grave que levou sema n as o q u e

- lev eria ter levado h o r as? Você já p r esenciou o que de v er i a ser uma alteração única e direta , m as

0' e em vez disso foi feita em diversos módulos dist i ntos ? Todos esses s i ntomas são bas t a n te :o m uns . Por q u e isso ocorre em um có d igo? Por que um código bom se decompõe tão ráp i do em

. :m ruim? Temos d i versas expl i cações para i sso . Reclamamos que os requisitos mudaram de

1 fo rma q u e estragaram o p roje t o original . Criticamos os prazos por serem curtos de m a i s para

:àz e rmos as coisas cert as. Resm un gamos sobre gerente s to l os e c l ientes i n tolerantes e tip os de

~

~

po de r i a essa zona ser nossa c ulpa? E os

: - eq uisitos? E o pr azo? E o s tol os ge r e n tes e t ipos d e mark etin g i n ú tei s? Eles não ca rregam

g u ma par c e l a da c ulpa ? N ão. Os ge r en t es e marketeir o s bu s c a m e m n ós as in f o r ma ç õ es qu e pr ecisam para fazer prome s sa s ;: fi r ma r em comp ro m iss os ; e mesmo qua n d o n ão nos procuram , n ã o d evemos dar uma d e tímidos ao

.

k eting

inúteis

e téc ni cos d e te l efone . Mas o padrão, q u er i do Di l bert", não está em nossas

m e las, mas s i m e m nós m esm os . Somos p rofissiona i s .

I sso po d e ser a lgo di f ícil d e en g o li r. Mas co m o

5

ze r - l h es n ossa op i ni ão . Os usuário s esper a m qu e va lid e mos as man e i r a s p e l as qu ais o s r equisitos se

a

ixar ão no s i s t e ma. Os gerentes e s peram qu e os a judemos a cumprir o pr azo. Noss a cump l icidad e

-

p la nej a ment o do projeto é tamanha que co mp ar tilh a mo s de uma grand e p a r ce la d a r e sp on s abilidad e

~

c

aso de f a lh as; e s peciah nente s e est as f ore m e m r e l ação a um c ó di go ruim.

"Mas , es p ere! ", v o cê d i z . "E se e u n ão fize r o q ue meu ge r e nt e qu er, se rei d emi t ido " . É

pr ov á ve l qu e o .

A m a i o r ia d os g eren tes qu er a v erd a d e, m esmo qu e demon s t re m o c ontrá rio. A maior i a d e l es quer um cód i go bo m , mesmo estour a ndo o p razo. E l es po d e m pro t eger co m pa i o o praz o e os

re quisitos , mas e s sa é a função de l es. A s ua é proteger o có d igo c om essa m esma pa i xão. Para fina l izar ess a q uestão , e se você fosse mé dic o e um p a cient e ex igisse q u e você p a rasse

co m tod a a quela l av açã o d as m ã o s n a pr e para ção p a ra a c i r urgi a s ó porqu e isso l e v a muito temp o?2

É ó b v i o q u e o c h efe nes t e c a so é o pa ciente; m as, me s m o a ssi m , o m é d i co d eve r á tota lmen te se rec u s a r obedec ê - lo . P o r q u ê ? Porque o mé di co sab e mais d o q u e o pacie n te so b r e os r i s co s de doenças e infecções. Não ser i a profiss i onal ( sem me n ciona r c ri m i noso) q ue o di c o o b e de cesse ao pa c iente n este c enário. Da mes m a for ma q ue n ã o é p r o fi ssiona l qu e p r o g r a m a do res ce d am à

vo n ta d e dos g ere nt es qu e n ão e nt e nd e m os risc os de se g e rar digos co nfusos .

o Principal Dilema

Os p r ogram ad ores se d epar am com um d i lem a de va l ores b ás i c os . Tod o s os d es en vo l ve d o r es

co m al g un s ano s a mai s d e exper iên c i a s ab e m que ba g un ç a s antig as redu ze m o r e n di men to .

Mes m o assi m to d os eles s e sente m pressi o n ados a co m e t er essa s b ag un ças p ara cumprir os prazos. Resumindo , e l es não se esfo r çam pa r a . Os profissionais sérios sabem que a segunda pa rt e d o dil e m a es t á erra d a. Você não c um pr i

o prazo se fizer bag un ça no cód i go . De fat o , t al de sorg ani zação r e du zir á in s t a ntan eamente s u a

ve lo c id a d e d e tr a balho , e v o cê per der á o p ra z o. A ú ni ca man e ira de isso n ão ac ontece r - a ú nica

m a n e i ra de ir mais r á pid o - é semp r e m a n te r o có di g o l i mp o .

A Arte do Código Limpo?

D i gamos q u e você acre d ite qu e um di go con f uso sej a um o b s tácul o r ele van t e . Di ga mo s que

você aceite q ue a ún i ca forma de tra b a l har ma i s rá pid o é m anter se u di g o l imp o . Então, você deve se perguntar: "Como escre v er um có d igo l impo ?" Não va l e de na d a tenta r escrever um código limpo se v ocê não sou b er o que isso s i g n if i ca . As más no t í c i as são q u e escreve r u m cód i go limp o é como p intar um qu a d ro . A maiori a de

n ós s ab e q u a nd o a f ig ur a fo i b em ou m a l pint ad a. Mas ser capa z d e dist i ngui r um a b oa arte de

uma r ui m não sign i f i ca que você sai b a p i ntar . Assi m com o saber d i sti ngu i r u m có di go lim p o de um r ui m não q u er d izer que saibamos escrev er um có di go li mpo. Escre v e r u m có di go l impo exige o uso d iscipli nado de u ma m iriade d e pe qu enas téc n icas

ap lic a d as p or meio d e u m a sens ibil i d a de

"sensibilid a d e a o c ódi go " é o segr edo. A l g un s d e s j á nasc emos co m e la. O utros p re cisam se esforça r para a dq uiri -I a . Ela n ão só n o s per mi te perc eb e r se o d igo é bom o u ru i m, c om o tam b ém nos m ostra a estratégia e disciplina de como trans f ormar um d ig o ru i m e m u m limpo. Um programado r sem " sensib i l i da d e ao có di go " po d e visu a lizar u m módulo co n fuso e rec onh ecer a ba gunça , mas n ão sab e r á o q u e f azer a r esp e ito d e l a. Já u m c om essa s ensibili dade

m et icul os ament e a dqu iri da sob re " lim pe za " . A

o lhará um m ó d ulo con f u s o e verá a lt er nati v as. A " s e nsibilid a de a o código " ajud a r á a esse

r og ra m ad or a esco l he r a m e lhor a l terna t iva e o or i enta r á na cr i ação d e um a seq u ê n cia de o m por t ame n tos para proteger as alterações feitas aqui e ali.

que escrev e um código limpo é um arti sta que pode pegar

u ma te la e m b ra nc o e s u bmetê -I a a um a sér i e de t ransfor m ações a t é que se t orn e um sis t ema gr ac iosame n te p r ogramado.

E m suma , um programador

o que é um Código Limpo?

P rov a ve l ment e existem tantas definiçõ es como e x i s t e m programadore s . Portanto , pe r guntei a 3lgun s progra ma do res b em c o n hecidos e com muita e x per i ência o q ue achavam.

Bj a r ne Stroustrup, criado r do C++ e autor do livro A linguagem de

r ogramação C++

Go s to do meu código elegante e e f iciente. A lógica

d eve ser dir e ta p a ra dif ic ultar o en cobri men to d e bu g s,

a

s d e pend ê n c i as mi n imas para facilitar a manutenção ,

o

t r atamento

de en ' o completo d e acordo com uma

e st r at égia cl a ra e o desempenho próx i mo do mais

efi c i e n t e de mod o a nã o incit a r a s p ess oa s a t o rnarem o

códi g o con fus o co m ot i m i zações sorratei r as.

lim po f az bem apenas uma coisa .

O cód i go

jarne

B

u sa

a p a lavra

" elegante "

-

u m a

- " av ra e tanto! O dicionário possui a s seguintes

~ ç õe s : qu e s e ca ra cter i za p e l a na t uralidad e ha r monia, l e veza , simpli c idad e; na tu ralidad e m o do se dispor ; r e qu i ntado , fino , estiloso.

-

e rve a ênfase dada à pala v ra " natu r a l id a de " .

- ?< IT en tement e, Bja r ne acha qu e um código limpo proporcion a uma lei tu r a n a tura l ; e l ê - Io de v e ~ be lo como o u vir u m a sica num rád i o ou visual izar u m car r o de des i g n magníf i co.

B ja rne também menciona duas ve z es " efi c iência ". Tal ve z isso não de v e ss e no s surpreender

_d o do criador do C+ + , m as acho q u e el e qui s d i ze r m ais do que um s impl es d es ejo por ; : ' · d a de . A repeti ção de ciclos n ã o é elegante , não é be l o . E repare que Bjarn e usa a pa l avra i ta r" para descre v er a consequência de tal dese l eg â nc i a. A verdade aqui é que um cód i go in cita o cres cimento do cao s num digo. Qu a ndo o u t r as p essoa s a lteram um código ruim ,

_ - t e ndem a p i orá - lo .

Pr a gmáticos, Dave Tho m as e A n dy Hunt expressam i sso de outra fo rma . Eles usam a met áfo r a - j a n elas quebrada s. 3 Uma construção com jane l a s quebradas p a rece que ninguém cuida dela .

: - a

forma , out r as pes s oas d e i x am d e s e preocupar c om el a também. E l as permitem que as

s j ane la s se quebrem ta mbém . No fin al d a s contas, as próprias pessoas as q ue b ra m . Elas ga m a f achada com p i c h ações e de i x am acumu l ar lixo . Uma ún i c a janela inicia o processo

Bjame também menciona que o tra t amento d e erro deva ser co mpleto . Isso s i g n ifica pr es t ar atenção n os deta lh es. U m tratamento de erro re du zido é ap enas u m a das m a neir as p e l a qu al

os pr ogra m adores de i xam de notar os d eta lh es. Pe rdas d e m e m ó ria e co nd i çõ es d e c orrid a são outras. N om e n c la t ur as inc o n s i s t en t es são ai nda ou tras. A co nc lu o é q ue um c ó digo l i mp o req u er ba stante a t enção aos d eta lh es. Bja m e concl ui com a assev eração d e que um cód i go l impo fa z bem apenas u ma coisa. Não é por acaso que há inúmeros princípi os de desen v o l v i mento de softw are que podem ser resumidos

a es s a simpl e s afirmação . V ários escritores já tentaram passar essa i d eia. Um código ruim

tenta fazer co i sas demais , ele est á che i o de propós it os obscu ros e ambíg u os . O c ódigo lim po é ce n tra li zado. C ada f un ção , c ad a c l ass e , cada mó dul o exp õ e u m a ú nica t arefa qu e nu nc a sofre

i n terfe rên c i a de o utr os d e talh es ou fica r odea d a por e l es.

Grady Booch, autor do livro Object Oriented Ana/ysis and Design with Applications

Um c ó d i g o limpo é si mple s e di r et o. El e é tào

bem l egív e l

quant o u ma pro s a be m escrit a . Ele jamai s

o b je t i v o do de senvolvedo r ,

a b strações c / aras e linhas de co n trole objetivas .

torna conjil s o o

em vez d i sso , ele está repl e to d e

Gra dy fala de alguns dos me s mo s pontos que Bjame ,

v o l tan d o - se mais p ara q uestão da l eg i bil i da d e . Eu ,

parti c ul a rm ente , g o s t o d esse p onto d e v i sta de que l er u m ' l, l )~

código l im po d ev e se r co mo l e r uma p rosa b e m e scri t a . Pense nu m l i v ro mui to b om q ue você já leu. L embr e-se d e como as p a l avras e ra m su b stitu ídas por imagens ! Era como assistir a u m filme, não era ? Mel h or a ind a, v ocê via os perso n agens ,

ou v ia os son s, e nvol v ia - s e nas emoções e no humor . Ler um c ó digo limpo j amai s s erá como ler O senhor dos an é is. Mesmo assim , a analogia

co

m a l i teratura n ão é r uim . Como u m b om ro man ce, um cód i go l i mp o deve ex p or c l aramente

as

ques t õ e s do p rob lema a ser sol u ci onad o . E l e de ve d esen vo l vê- I as até u m c lím ax e, en t ã o , dar

ao l eit or aq u e l e "A h á! Mas é c l aro ! ", re v elação de uma solução ó b v i a.

Grad y faz da frase "abstrações c l aras " é um para d oxo fasc i nante!

Apesar d e tudo , a pala v ra " clara " é praticamente u m s i nôn im o para "exp l ícito". Meu dicionár i o

MacBook t e m a seguinte definição para "