Deleting commented out code

This is a ru­le I alwa­ys en­cou­ra­ge in so­ftwa­re de­ve­lo­p­men­t. Mo­reo­ve­r, I con­si­der it to be so­me­thing that ha­s ­to be in­clu­ded in eve­ry co­ding gui­de­li­ne of a good pro­jec­t.

The­re are se­ve­ral rea­sons for this, but pro­ba­bly the best ex­pla­na­tion can be found in the book “Clean Co­de”1 by un­cle ­Bo­b, on whi­ch ex­plains that the co­de, ge­ts ou­tdated (ro­tten) wi­th the rest of the su­rroun­ding co­de, and hen­ce it makes a pla­ce for con­fu­sio­n, lea­ding to an erro­r-­pro­ne spo­t.

The­re are, ho­we­ve­r, peo­ple that seem to find so­me ar­gu­men­ts for co­m­men­ting out co­de, or lea­ving it. ­So­me co­m­mon ar­gu­men­ts/­rea­sons usua­lly are:

  • I mi­­ght need this fun­c­­tio­­­na­­li­­ty la­­te­­r..”

We ha­ve sour­ce con­trol sys­te­ms (for exam­ple gi­t) for this. In gi­t, an­y­thing can be res­to­red from a pre­vious poin­t. If ­the so­ftwa­re is pro­per­ly un­der ver­sion con­tro­l, the­re is no rea­son to fear da­ta lo­ss. Trust gi­t, co­de fear­le­ss­l­y.

  • This is te­m­­po­­­ra­­ry di­s­a­­ble­­d… It wi­­ll be res­­to­­­red la­­te­­r”.

Agai­n, sa­me prin­ci­ple, re­ly on the ver­sion con­trol sys­te­m. Save a pa­tch, and then res­to­re la­te­r, or stash the chan­ges, re­vert the co­m­mi­t, etc. As you see, the­re are plen­ty of be­tter op­tions for sol­ving this sce­na­rio.

  • Co­­­de that was le­­ft from the fist ve­r­­sion

Pro­ba­bly de­bu­gging le­fto­ver­s. No doubt he­re: seek, lo­ca­te, des­tro­y.

The­re is, a clear pro­blem wi­th co­de that is un­der co­m­men­t, whi­ch is that it is “fro­zen” in ti­me: it was good at so­me poin­t, but then it was le­ft the­re whi­le the rest of the co­de around it, evol­ve­d, so this old co­de ­mi­ght not cer­tain­ly wo­rk (hen­ce it is “ro­tten”), so un-­co­m­men­ting it is a bad idea be­cau­se it wi­ll pro­ba­bly cras­h.

Ano­ther pro­blem is that it can be a sour­ce of bias for so­me other de­ve­lo­pe­r, who wan­ts to main­tain that co­de at a fu­tu­re poin­t in ti­me. The one who le­ft the ro­tten co­de, mi­ght ha­ve thou­ght that it was a sour­ce of ins­pi­ra­tion for when this func­tio­na­li­ty wa­s ­going to be applie­d, but ins­tea­d, it is just bia­sing the new de­ve­lo­per wi­th this ske­le­to­n, pre­ven­ting from a brand new, fres­h i­dea for that co­de.

The­re­fo­re, for the­se main rea­sons (an pro­ba­bly mu­ch mo­re), ha­ving co­de that is co­m­men­ted in a co­de ba­se, is a poor prac­ti­ce, (not to­ ­men­tion a co­de sme­ll). If you are a sea­so­ned de­ve­lo­pe­r, who ca­res about co­de qua­li­ty, and best prac­ti­ce­s, you must not doubt when ­de­le­ting it. De­le­te co­m­men­ted out co­de mer­ci­le­ss­l­y: seek, lo­ca­te and des­tro­y.


A book I hi­gh­ly re­co­m­men­d: http­s://www.a­ma­zo­n.­co­m/­Clean-­Co­de-Han­dbook-­So­ftwa­re-­Cra­fts­mans­hi­p/­dp/0132350882