[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"sanity-wyULzhLhUAVQCOzUvTERYb3WrMdJCCGT1Hrubsok1ao":3,"sanity-1pufYcFbCHcAMxsuHMUzUO1vnQKEh9TOHN_RuCLXm1c":1647},{"data":4,"sourceMap":-1},{"latestPodcast":5,"latestReleases":14,"post":39,"recent":1622},[6],{"_id":7,"publishedAt":8,"slug":9,"sponsored":12,"title":13},"7ebd76d2-cebc-4b88-82f9-3dfb2c8bc5ca","2026-07-08T04:40:00.000Z",{"_type":10,"current":11},"slug","what-s-left-for-infrastructure-as-code-after-ai-moves-in",true,"What's left for infrastructure-as-code after AI moves in?",[15,21,27,33],{"_id":16,"publishedAt":17,"slug":18,"title":20},"eb5b66eb-9410-4329-83bb-22bbff39402a","2026-04-28T13:00:00.000Z",{"_type":10,"current":19},"turn-scattered-knowledge-into-trusted-intelligence","Turning scattered knowledge into trusted intelligence: Stack Internal 2026.3",{"_id":22,"publishedAt":23,"slug":24,"title":26},"369c2401-b62e-4a37-8ff8-bf603023ecad","2026-03-02T15:03:00.988Z",{"_type":10,"current":25},"what-s-new-at-stack-overflow-march-2026","What’s new at Stack Overflow: March 2026",{"_id":28,"publishedAt":29,"slug":30,"title":32},"5e9053a4-07ea-447c-91ea-29e0b6228537","2026-02-02T15:00:00.000Z",{"_type":10,"current":31},"what-s-new-at-stack-overflow-february-2026","What’s new at Stack Overflow: February 2026",{"_id":34,"publishedAt":35,"slug":36,"title":38},"a1b538eb-a8a6-46d0-80a1-ac70ec9bb935","2026-01-05T10:00:00.000-05:00",{"_type":10,"current":37},"what-s-new-at-stack-overflow-january-2026","What’s new at Stack Overflow: January 2026",{"_createdAt":40,"_id":41,"_rev":42,"_system":43,"_type":46,"_updatedAt":47,"author":48,"body":64,"comments":12,"dateUrl":1583,"excerpt":1584,"image":1585,"legacyBody":1588,"product":96,"publishedAt":1591,"slug":1592,"sponsored":96,"tags":1594,"title":1621,"visible":12},"2023-05-24T12:28:24Z","wp-post-21633","OuLxq6F1ZwNJHk6WTUNy9c",{"base":44},{"id":41,"rev":45},"Soh4zwnVSgD0IUkr57K2oR","blogPost","2026-05-11T18:31:18Z",[49],{"_createdAt":50,"_id":51,"_rev":52,"_type":53,"_updatedAt":54,"avatar":55,"employee":60,"name":61,"slug":62},"2023-05-23T16:27:18Z","wp-author-225","dgl3SCUzppW3U2LvCoP35A","blogAuthor","2023-06-20T15:05:08Z",{"_type":56,"asset":57},"image",{"_ref":58,"_type":59},"image-6b50d301dd962a6ae761cd6a3a0eb79f5e9cc70d-1024x1024-jpg","reference","none","Max Pekarsky",{"current":63},"maxpekarsky",[65,76,98,106,136,144,152,160,169,188,196,215,223,231,239,247,255,263,271,279,296,306,314,322,330,338,346,354,362,370,386,394,413,425,437,449,469,484,524,532,540,559,567,705,763,847,862,960,987,999,1015,1023,1047,1055,1063,1094,1097,1112,1120,1132,1135,1150,1162,1165,1173,1181,1189,1192,1224,1232,1235,1243,1262,1265,1281,1312,1320,1328,1336,1352,1355,1363,1382,1390,1393,1416,1424,1432,1440,1448,1451,1454,1462,1486,1494,1497,1527,1535,1543,1551,1559,1567,1575],{"_key":66,"_type":67,"children":68,"markDefs":74,"style":75},"7f23d4b8af25","block",[69],{"_key":70,"_type":71,"marks":72,"text":73},"7f23d4b8af250","span",[],"We’re all coders now",[],"h2",{"_key":77,"_type":67,"children":78,"markDefs":92,"style":97},"48bc5739f706",[79,83,88],{"_key":80,"_type":71,"marks":81,"text":82},"48bc5739f7060",[],"In the 1980s, personal computers ",{"_key":84,"_type":71,"marks":85,"text":87},"48bc5739f7061",[86],"9775fa84cd1b","became common",{"_key":89,"_type":71,"marks":90,"text":91},"48bc5739f7062",[]," in the workplace. With the release of the Apple II in 1977 and the IBM PC four years later, a tool once reserved for scientists and the military proliferated in accounting offices, universities, and hospitals. You no longer had to be an engineer to use a computer.",[93],{"_key":86,"_type":94,"href":95,"reference":96},"link","https:\u002F\u002Fwww.bbc.com\u002Fnews\u002Fmagazine-23509153",null,"normal",{"_key":99,"_type":67,"children":100,"markDefs":105,"style":97},"3898464f0abe",[101],{"_key":102,"_type":71,"marks":103,"text":104},"3898464f0abe0",[],"Something similar has happened with programming over the past decade. In everyday offices, classrooms, and laboratories, code is now being written and maintained by people who don’t think of themselves as programmers.",[],{"_key":107,"_type":67,"children":108,"markDefs":131,"style":97},"696772d4e560",[109,113,118,122,127],{"_key":110,"_type":71,"marks":111,"text":112},"696772d4e5600",[],"The good news is that it’s easier than ever to write code that works. There’s no shortage of beginner-friendly programming tutorials, and high-level languages today are more readable than ever. So, if someone at work hands you a Python script to run over some data, between ",{"_key":114,"_type":71,"marks":115,"text":117},"696772d4e5601",[116],"00553e124701","Stack Overflow",{"_key":119,"_type":71,"marks":120,"text":121},"696772d4e5602",[]," and ",{"_key":123,"_type":71,"marks":124,"text":126},"696772d4e5603",[125],"fceea6f4ee73","Codecademy",{"_key":128,"_type":71,"marks":129,"text":130},"696772d4e5604",[]," you can probably figure out how to get it to work.",[132,134],{"_key":116,"_type":94,"href":133,"reference":96},"https:\u002F\u002Fstackoverflow.com\u002F",{"_key":125,"_type":94,"href":135,"reference":96},"https:\u002F\u002Fwww.codecademy.com\u002F",{"_key":137,"_type":67,"children":138,"markDefs":143,"style":97},"6f4dd7632199",[139],{"_key":140,"_type":71,"marks":141,"text":142},"6f4dd76321990",[],"The bad news is that after you write the code you just learned to write, someone is going to have to read it (that someone might be you in six months). To a beginner, getting a working solution is the finish line. To a developer, it’s only the starting line. And since more of us are writing and collaborating on code than ever before, it’s becoming crucial to write better code.",[],{"_key":145,"_type":67,"children":146,"markDefs":151,"style":97},"851e42555b51",[147],{"_key":148,"_type":71,"marks":149,"text":150},"851e42555b510",[],"There’s a lot to learn about basic programming beyond “making it work.” For professional developers, writing maintainable code is fundamental to the job. But these practices aren’t usually discussed in “Coding 101”. Beginner tutorials usually focus on syntax.",[],{"_key":153,"_type":67,"children":154,"markDefs":159,"style":97},"07a45771b177",[155],{"_key":156,"_type":71,"marks":157,"text":158},"07a45771b1770",[],"So we’ll assume you already know how to pull together a working solution — it’s time to level up to Coding 102: writing code with and for other humans.",[],{"_key":161,"_type":67,"children":162,"markDefs":167,"style":168},"5d0a6070b3ab",[163],{"_key":164,"_type":71,"marks":165,"text":166},"5d0a6070b3ab0",[],"Prerequisites",[],"h3",{"_key":170,"_type":67,"children":171,"markDefs":185,"style":97},"04118700fd6b",[172,176,181],{"_key":173,"_type":71,"marks":174,"text":175},"04118700fd6b0",[],"We’ll keep our examples short and simple and write them in ",{"_key":177,"_type":71,"marks":178,"text":180},"04118700fd6b1",[179],"3bddaf1b099d","pseudocode",{"_key":182,"_type":71,"marks":183,"text":184},"04118700fd6b2",[]," (which should seem familiar if you’ve written in a popular language). This post is aimed at people who’ve spent time writing code, but don’t write it professionally full-time. It helps if you are familiar with variables, functions, and if\u002Felse statements.",[186],{"_key":179,"_type":94,"href":187,"reference":96},"https:\u002F\u002Fwww.hackterms.com\u002Fpseudocode",{"_key":189,"_type":67,"children":190,"markDefs":195,"style":75},"c21b61b6dcf5",[191],{"_key":192,"_type":71,"marks":193,"text":194},"c21b61b6dcf50",[],"Why writing better code matters",[],{"_key":197,"_type":67,"children":198,"markDefs":212,"style":97},"22b06d210030",[199,203,208],{"_key":200,"_type":71,"marks":201,"text":202},"22b06d2100300",[],"There’s an adage in programming that ",{"_key":204,"_type":71,"marks":205,"text":207},"22b06d2100301",[206],"7df4355696fd","maintaining code is 75% of its total cost",{"_key":209,"_type":71,"marks":210,"text":211},"22b06d2100302",[],". Once you write the code, other people (including future you) will invest two to three times as much time, on average, in reading, updating, and fixing it. This doesn’t mean your code was badly written or buggy! Requirements evolve, other parts of the code change, and sometimes… well, yeah, sometimes there are bugs.",[213],{"_key":206,"_type":94,"href":214,"reference":96},"https:\u002F\u002Fweb.archive.org\u002Fweb\u002F20120313070806\u002Fhttp:\u002F\u002Fusers.jyu.fi\u002F~koskinen\u002Fsmcosts.htm",{"_key":216,"_type":67,"children":217,"markDefs":222,"style":97},"82712f7ca330",[218],{"_key":219,"_type":71,"marks":220,"text":221},"82712f7ca3300",[],"At one of my first (non-programming) jobs, I wrote a script that switched between browser tabs with user accounts and pasted in discount codes. At the time, this task was done by hand for hundreds of users each month.",[],{"_key":224,"_type":67,"children":225,"markDefs":230,"style":97},"39e5acdec577",[226],{"_key":227,"_type":71,"marks":228,"text":229},"39e5acdec5770",[],"I hacked the script together in a few hours, and, to my manager’s delight, it pasted hundreds of codes in a few minutes. But the following week, the script went haywire and applied the code to 300 wrong accounts. It took me two hours to code the script, but eight hours to undo the damage it caused and fix my convoluted code. That's the maintenance cost.",[],{"_key":232,"_type":67,"children":233,"markDefs":238,"style":97},"acd30c906a9b",[234],{"_key":235,"_type":71,"marks":236,"text":237},"acd30c906a9b0",[],"Good design “reduces the cost of future changes.” Let’s say my company changed the layout of the discount code page. How long would it take someone to update my script to work with the new layout? If another developer offered to help, how long would it take them to get up to speed on my work? That depends on how well the code was designed.",[],{"_key":240,"_type":67,"children":241,"markDefs":246,"style":97},"5e3d15b22022",[242],{"_key":243,"_type":71,"marks":244,"text":245},"5e3d15b220220",[],"In order to make code easy to maintain, update, and fix, it should be modular, easy to follow, and easy to reason about. Writing “clean” code (as it’s often called) will help you think through the problem. If other people you work with can embrace these practices, you’ll spend less time struggling and more time collaborating productively.",[],{"_key":248,"_type":67,"children":249,"markDefs":254,"style":75},"e7ef0213f724",[250],{"_key":251,"_type":71,"marks":252,"text":253},"e7ef0213f7240",[],"Coding 102",[],{"_key":256,"_type":67,"children":257,"markDefs":262,"style":97},"b9c84f36234b",[258],{"_key":259,"_type":71,"marks":260,"text":261},"b9c84f36234b0",[],"Now that we understand why maintainable, clean code matters, let’s talk about how to write it.",[],{"_key":264,"_type":67,"children":265,"markDefs":270,"style":168},"57c3499d0b0f",[266],{"_key":267,"_type":71,"marks":268,"text":269},"57c3499d0b0f0",[],"1. Write small functions",[],{"_key":272,"_type":67,"children":273,"markDefs":278,"style":97},"c8e25932ac05",[274],{"_key":275,"_type":71,"marks":276,"text":277},"c8e25932ac050",[],"Aim to write small functions that do one thing. Let’s say you’re writing a function that takes a list of widget prices and returns some text with the average of those prices. For example, you give it [13, 28, 17, 143, 184, 72.3] and it should return “The average price for 6 widgets is $72.22.”",[],{"_key":280,"_type":67,"children":281,"markDefs":295,"style":97},"da23fb83c449",[282,286,291],{"_key":283,"_type":71,"marks":284,"text":285},"da23fb83c4490",[],"A first attempt at this code might be a function called ",{"_key":287,"_type":71,"marks":288,"text":290},"da23fb83c4491",[289],"code","get_price_average(data)",{"_key":292,"_type":71,"marks":293,"text":294},"da23fb83c4492",[]," that:",[],{"_key":297,"_type":67,"children":298,"level":303,"listItem":304,"markDefs":305,"style":97},"e51976430d94",[299],{"_key":300,"_type":71,"marks":301,"text":302},"e51976430d940",[],"Takes some data",1,"number",[],{"_key":307,"_type":67,"children":308,"level":303,"listItem":304,"markDefs":313,"style":97},"3cad1d979cc2",[309],{"_key":310,"_type":71,"marks":311,"text":312},"3cad1d979cc20",[],"Gets the length of the number list",[],{"_key":315,"_type":67,"children":316,"level":303,"listItem":304,"markDefs":321,"style":97},"e4355057c745",[317],{"_key":318,"_type":71,"marks":319,"text":320},"e4355057c7450",[],"Gets the sum of the prices",[],{"_key":323,"_type":67,"children":324,"level":303,"listItem":304,"markDefs":329,"style":97},"b3bb1df1633c",[325],{"_key":326,"_type":71,"marks":327,"text":328},"b3bb1df1633c0",[],"Divides the sum by the number of widgets to get the average",[],{"_key":331,"_type":67,"children":332,"level":303,"listItem":304,"markDefs":337,"style":97},"6ae90f2d405e",[333],{"_key":334,"_type":71,"marks":335,"text":336},"6ae90f2d405e0",[],"Rounds the average",[],{"_key":339,"_type":67,"children":340,"level":303,"listItem":304,"markDefs":345,"style":97},"caea0b095c2a",[341],{"_key":342,"_type":71,"marks":343,"text":344},"caea0b095c2a0",[],"Assembles all the stats into a string of text and prints it",[],{"_key":347,"_type":67,"children":348,"markDefs":353,"style":97},"75aa2b491eb7",[349],{"_key":350,"_type":71,"marks":351,"text":352},"75aa2b491eb70",[],"Depending on the language, some of these operations might be built in. You put these steps in one function, and it works. This is a fine, typical first version.",[],{"_key":355,"_type":67,"children":356,"markDefs":361,"style":97},"d0ecb5d36d9c",[357],{"_key":358,"_type":71,"marks":359,"text":360},"d0ecb5d36d9c0",[],"On the plus side, the code is cohesive: everything we’re doing related to the stats text is in one place. So if you need to change anything having to do with this text, you know where to look.",[],{"_key":363,"_type":67,"children":364,"markDefs":369,"style":97},"799a00bc2491",[365],{"_key":366,"_type":71,"marks":367,"text":368},"799a00bc24910",[],"The problem is that if you do need to make a change (add a stat, clarify which numbers should be averaged, or change the decimal points on the average), you’ll need to read and understand the whole function. And adding the change will just balloon it further.",[],{"_key":371,"_type":67,"children":372,"markDefs":385,"style":97},"4794923dc66f",[373,377,381],{"_key":374,"_type":71,"marks":375,"text":376},"4794923dc66f0",[],"The solution is to break our oversized ",{"_key":378,"_type":71,"marks":379,"text":380},"4794923dc66f1",[289],"get_price_average()",{"_key":382,"_type":71,"marks":383,"text":384},"4794923dc66f2",[],", which does many things, into several small functions that each do one thing. A good guideline is:\n\n> A function should be small, do just one thing, and ideally shouldn’t impact anything outside the function",[],{"_key":387,"_type":67,"children":388,"markDefs":393,"style":97},"f9e7a4270106",[389],{"_key":390,"_type":71,"marks":391,"text":392},"f9e7a42701060",[],"Let’s try to see this by example. Here’s how we might break the function up.",[],{"_key":395,"_type":67,"children":396,"level":303,"listItem":304,"markDefs":412,"style":97},"eac46596a1b5",[397,401,405,408],{"_key":398,"_type":71,"marks":399,"text":400},"eac46596a1b50",[289],"get_widget_price_stats(data)",{"_key":402,"_type":71,"marks":403,"text":404},"eac46596a1b51",[],": we’re renaming our wrapper function, ",{"_key":406,"_type":71,"marks":407,"text":380},"eac46596a1b52",[289],{"_key":409,"_type":71,"marks":410,"text":411},"eac46596a1b53",[],". It now takes some data, extracts the relevant stat and returns texts with that stat. We’ll talk about names shortly!",[],{"_key":414,"_type":67,"children":415,"level":303,"listItem":304,"markDefs":424,"style":97},"edb6f30a4ad6",[416,420],{"_key":417,"_type":71,"marks":418,"text":419},"edb6f30a4ad60",[289],"get_max(list_of_numbers)",{"_key":421,"_type":71,"marks":422,"text":423},"edb6f30a4ad61",[],": gets the largest number in a list. Depending on the language you use, this might be part of the standard library.",[],{"_key":426,"_type":67,"children":427,"level":303,"listItem":304,"markDefs":436,"style":97},"576da4dc2989",[428,432],{"_key":429,"_type":71,"marks":430,"text":431},"576da4dc29890",[289],"get_min(list_of_numbers)",{"_key":433,"_type":71,"marks":434,"text":435},"576da4dc29891",[],": gets the smallest number in a list. Depending on the language you use, this might be part of the standard library.",[],{"_key":438,"_type":67,"children":439,"level":303,"listItem":304,"markDefs":448,"style":97},"6f4b19a0c37c",[440,444],{"_key":441,"_type":71,"marks":442,"text":443},"6f4b19a0c37c0",[289],"get_sum(list_of_numbers)",{"_key":445,"_type":71,"marks":446,"text":447},"6f4b19a0c37c1",[],": gets the sum in a list of numbers.",[],{"_key":450,"_type":67,"children":451,"level":303,"listItem":304,"markDefs":468,"style":97},"2cad786f8712",[452,456,460,464],{"_key":453,"_type":71,"marks":454,"text":455},"2cad786f87120",[289],"get_average(list_of_numbers, decimal_points)",{"_key":457,"_type":71,"marks":458,"text":459},"2cad786f87121",[],": takes a list of numbers and returns the average, rounded to ",{"_key":461,"_type":71,"marks":462,"text":463},"2cad786f87122",[289],"decimal_points",{"_key":465,"_type":71,"marks":466,"text":467},"2cad786f87123",[],".",[],{"_key":470,"_type":67,"children":471,"markDefs":483,"style":97},"6c07dc9dd467",[472,476,479],{"_key":473,"_type":71,"marks":474,"text":475},"6c07dc9dd4670",[],"Did you find some of those function descriptions obvious? For example, it might be pretty clear that ",{"_key":477,"_type":71,"marks":478,"text":419},"6c07dc9dd4671",[289],{"_key":480,"_type":71,"marks":481,"text":482},"6c07dc9dd4672",[]," gets the largest number in a list. Good! That’s by design. When you write small functions that have clear single responsibilities, you can give them names that clearly convey what they do. Then, your future readers don’t have to read all the code in the function to understand what it does.",[],{"_key":485,"_type":67,"children":486,"markDefs":523,"style":97},"4152b22fb98f",[487,491,495,499,503,507,511,515,519],{"_key":488,"_type":71,"marks":489,"text":490},"4152b22fb98f0",[],"How does this design respond to changes? Let’s say instead of the average, you need to return the standard deviation. In the initial version, we’d need to find the section of the code that calculates the average and overwrite it with a standard deviation calculation.\n\nIn the small-function version, we could create a new function, ",{"_key":492,"_type":71,"marks":493,"text":494},"4152b22fb98f1",[289],"get_standard_deviation(list)",{"_key":496,"_type":71,"marks":497,"text":498},"4152b22fb98f2",[],", then go into ",{"_key":500,"_type":71,"marks":501,"text":502},"4152b22fb98f3",[289],"get_widget_price_stats()",{"_key":504,"_type":71,"marks":505,"text":506},"4152b22fb98f4",[]," and replace the call to ",{"_key":508,"_type":71,"marks":509,"text":510},"4152b22fb98f5",[289],"get_average()",{"_key":512,"_type":71,"marks":513,"text":514},"4152b22fb98f6",[]," to ",{"_key":516,"_type":71,"marks":517,"text":518},"4152b22fb98f7",[289],"get_standard_deviation()",{"_key":520,"_type":71,"marks":521,"text":522},"4152b22fb98f8",[],".\n\nTo recap, the functions we break out should be small, self-contained, and do one thing. This makes it much easier to read and change your code. This practice alone will improve your code significantly.\n",[],{"_key":525,"_type":67,"children":526,"markDefs":531,"style":75},"cbc61b071e4a",[527],{"_key":528,"_type":71,"marks":529,"text":530},"cbc61b071e4a0",[],"2. Pick names carefully",[],{"_key":533,"_type":67,"children":534,"markDefs":539,"style":97},"620f07816a89",[535],{"_key":536,"_type":71,"marks":537,"text":538},"620f07816a890",[],"There’s a running joke that “there are two hard things in computer science: cache invalidation and naming things.” We’re going to leave cache invalidation for another post and focus on naming things.",[],{"_key":541,"_type":67,"children":542,"markDefs":556,"style":97},"766deff43de9",[543,547,552],{"_key":544,"_type":71,"marks":545,"text":546},"766deff43de90",[],"A related idea is that “",{"_key":548,"_type":71,"marks":549,"text":551},"766deff43de91",[550],"11cae5b00c56","good code is self-documenting",{"_key":553,"_type":71,"marks":554,"text":555},"766deff43de92",[],".” In essence, this means that good code conveys what it does. Names are a big part of this: a good name is precise, easy to understand, and gives the code context without having to read every line.",[557],{"_key":550,"_type":94,"href":558,"reference":96},"https:\u002F\u002Fstackoverflow.com\u002Fa\u002F209065\u002F3434304",{"_key":560,"_type":67,"children":561,"markDefs":566,"style":97},"bb236d30e13a",[562],{"_key":563,"_type":71,"marks":564,"text":565},"bb236d30e13a0",[],"Here are some good naming practices:",[],{"_key":568,"_type":67,"children":569,"level":303,"listItem":304,"markDefs":704,"style":97},"ba90d351fdb6",[570,575,579,583,587,591,595,598,602,606,610,615,619,623,627,631,634,638,641,645,649,652,656,660,663,666,669,673,676,679,682,686,690,693,696,700],{"_key":571,"_type":71,"marks":572,"text":574},"ba90d351fdb60",[573],"strong","Describe intent",{"_key":576,"_type":71,"marks":577,"text":578},"ba90d351fdb61",[],": Try to describe the variable or function you’re naming as specifically as you can. For example, the function we looked at above was called ",{"_key":580,"_type":71,"marks":581,"text":582},"ba90d351fdb62",[289],"get_price_average",{"_key":584,"_type":71,"marks":585,"text":586},"ba90d351fdb63",[],". However, since the string we’re returning is actually an average of widget prices, we could name the function more precisely: ",{"_key":588,"_type":71,"marks":589,"text":590},"ba90d351fdb64",[289],"get_widget_price_average()",{"_key":592,"_type":71,"marks":593,"text":594},"ba90d351fdb65",[],". Later, we wanted it to serve as a wrapper function that returned some stat, so we renamed it to ",{"_key":596,"_type":71,"marks":597,"text":502},"ba90d351fdb66",[289],{"_key":599,"_type":71,"marks":600,"text":601},"ba90d351fdb67",[]," From this function, we extracted a general ",{"_key":603,"_type":71,"marks":604,"text":605},"ba90d351fdb68",[289],"average",{"_key":607,"_type":71,"marks":608,"text":609},"ba90d351fdb69",[]," function that takes a list of ",{"_key":611,"_type":71,"marks":612,"text":614},"ba90d351fdb610",[613],"em","any",{"_key":616,"_type":71,"marks":617,"text":618},"ba90d351fdb611",[]," numbers and returns the average.\n\nTry to avoid general names like ",{"_key":620,"_type":71,"marks":621,"text":622},"ba90d351fdb612",[289],"date",{"_key":624,"_type":71,"marks":625,"text":626},"ba90d351fdb613",[],", ",{"_key":628,"_type":71,"marks":629,"text":630},"ba90d351fdb614",[289],"slice",{"_key":632,"_type":71,"marks":633,"text":626},"ba90d351fdb615",[],{"_key":635,"_type":71,"marks":636,"text":637},"ba90d351fdb616",[289],"part",{"_key":639,"_type":71,"marks":640,"text":626},"ba90d351fdb617",[],{"_key":642,"_type":71,"marks":643,"text":644},"ba90d351fdb618",[289],"numbers",{"_key":646,"_type":71,"marks":647,"text":648},"ba90d351fdb619",[],". Instead, depending on context, ",{"_key":650,"_type":71,"marks":651,"text":622},"ba90d351fdb620",[289],{"_key":653,"_type":71,"marks":654,"text":655},"ba90d351fdb621",[]," might become ",{"_key":657,"_type":71,"marks":658,"text":659},"ba90d351fdb622",[289],"created_at",{"_key":661,"_type":71,"marks":662,"text":626},"ba90d351fdb623",[],{"_key":664,"_type":71,"marks":665,"text":630},"ba90d351fdb624",[289],{"_key":667,"_type":71,"marks":668,"text":655},"ba90d351fdb625",[],{"_key":670,"_type":71,"marks":671,"text":672},"ba90d351fdb626",[289],"outdated_prices",{"_key":674,"_type":71,"marks":675,"text":626},"ba90d351fdb627",[],{"_key":677,"_type":71,"marks":678,"text":637},"ba90d351fdb628",[289],{"_key":680,"_type":71,"marks":681,"text":655},"ba90d351fdb629",[],{"_key":683,"_type":71,"marks":684,"text":685},"ba90d351fdb630",[289],"part_to_be_fixed",{"_key":687,"_type":71,"marks":688,"text":689},"ba90d351fdb631",[],", and ",{"_key":691,"_type":71,"marks":692,"text":644},"ba90d351fdb632",[289],{"_key":694,"_type":71,"marks":695,"text":655},"ba90d351fdb633",[],{"_key":697,"_type":71,"marks":698,"text":699},"ba90d351fdb634",[289],"current_row",{"_key":701,"_type":71,"marks":702,"text":703},"ba90d351fdb635",[],".\n",[],{"_key":706,"_type":67,"children":707,"level":303,"listItem":304,"markDefs":762,"style":97},"eef6b4316f26",[708,712,716,720,724,728,732,736,739,743,747,751,755,758],{"_key":709,"_type":71,"marks":710,"text":711},"eef6b4316f260",[573],"Be consistent",{"_key":713,"_type":71,"marks":714,"text":715},"eef6b4316f261",[],": Whichever convention you decide to use, stick with it. If the codebase uses ",{"_key":717,"_type":71,"marks":718,"text":719},"eef6b4316f262",[289],"get_",{"_key":721,"_type":71,"marks":722,"text":723},"eef6b4316f263",[]," for functions that return values, each function should be ",{"_key":725,"_type":71,"marks":726,"text":727},"eef6b4316f264",[289],"get_[stat]",{"_key":729,"_type":71,"marks":730,"text":731},"eef6b4316f265",[],": ",{"_key":733,"_type":71,"marks":734,"text":735},"eef6b4316f266",[289],"get_average",{"_key":737,"_type":71,"marks":738,"text":626},"eef6b4316f267",[],{"_key":740,"_type":71,"marks":741,"text":742},"eef6b4316f268",[289],"get_max",{"_key":744,"_type":71,"marks":745,"text":746},"eef6b4316f269",[],", etc. If you name a function that returns standard deviation ",{"_key":748,"_type":71,"marks":749,"text":750},"eef6b4316f2610",[289],"standard_deviation",{"_key":752,"_type":71,"marks":753,"text":754},"eef6b4316f2611",[],", another dev will wonder how it’s different from all the ",{"_key":756,"_type":71,"marks":757,"text":727},"eef6b4316f2612",[289],{"_key":759,"_type":71,"marks":760,"text":761},"eef6b4316f2613",[]," functions.\n",[],{"_key":764,"_type":67,"children":765,"level":303,"listItem":304,"markDefs":846,"style":97},"aa02ac0b0655",[766,770,774,778,782,786,790,794,798,802,806,810,814,818,822,826,830,834,838,842],{"_key":767,"_type":71,"marks":768,"text":769},"aa02ac0b06550",[573],"Give the right amount of information",{"_key":771,"_type":71,"marks":772,"text":773},"aa02ac0b06551",[],". A variable called ",{"_key":775,"_type":71,"marks":776,"text":777},"aa02ac0b06552",[289],"first_name",{"_key":779,"_type":71,"marks":780,"text":781},"aa02ac0b06553",[]," conveys a good amount of information. The alternative, ",{"_key":783,"_type":71,"marks":784,"text":785},"aa02ac0b06554",[289],"name",{"_key":787,"_type":71,"marks":788,"text":789},"aa02ac0b06555",[]," is too vague (first? last? middle? full?) and ",{"_key":791,"_type":71,"marks":792,"text":793},"aa02ac0b06556",[289],"n",{"_key":795,"_type":71,"marks":796,"text":797},"aa02ac0b06557",[]," or ",{"_key":799,"_type":71,"marks":800,"text":801},"aa02ac0b06558",[289],"fn",{"_key":803,"_type":71,"marks":804,"text":805},"aa02ac0b06559",[]," is downright indecipherable. These are examples of under-explaining; it’s not clear what the variable does.\n\nIt’s also possible to over-explain: ",{"_key":807,"_type":71,"marks":808,"text":809},"aa02ac0b065510",[289],"user_first_name",{"_key":811,"_type":71,"marks":812,"text":813},"aa02ac0b065511",[]," doesn’t offer any additional information, since ",{"_key":815,"_type":71,"marks":816,"text":817},"aa02ac0b065512",[289],"user",{"_key":819,"_type":71,"marks":820,"text":821},"aa02ac0b065513",[]," is fairly generic, and it’s not clear what the alternative is (does the app have ",{"_key":823,"_type":71,"marks":824,"text":825},"aa02ac0b065514",[289],"bots",{"_key":827,"_type":71,"marks":828,"text":829},"aa02ac0b065515",[]," with first names?) Similarly, ",{"_key":831,"_type":71,"marks":832,"text":833},"aa02ac0b065516",[289],"first_name_for_user_record",{"_key":835,"_type":71,"marks":836,"text":837},"aa02ac0b065517",[],", or ",{"_key":839,"_type":71,"marks":840,"text":841},"aa02ac0b065518",[289],"get_price_average_by_dividing_prices_by_quantity",{"_key":843,"_type":71,"marks":844,"text":845},"aa02ac0b065519",[]," offer redundant information.\n\nDeciding on the right level of specificity is a skill you’ll build over time. It requires you step back and think deeply about what the variable is doing. This’ll make your code better in the long run and make you a better developer with it.",[],{"_key":848,"_type":67,"children":849,"markDefs":861,"style":97},"2e70b14d7c22",[850,854,857],{"_key":851,"_type":71,"marks":852,"text":853},"2e70b14d7c220",[],"Speaking of how you shouldn’t call your variable ",{"_key":855,"_type":71,"marks":856,"text":801},"2e70b14d7c221",[289],{"_key":858,"_type":71,"marks":859,"text":860},"2e70b14d7c222",[],", here’s a list of naming practices to avoid:",[],{"_key":863,"_type":67,"children":864,"level":303,"listItem":304,"markDefs":957,"style":97},"601661349758",[865,869,873,877,880,884,887,891,894,898,901,905,909,913,917,921,924,928,932,937,941,945,949,953],{"_key":866,"_type":71,"marks":867,"text":868},"6016613497580",[573],"Don’t include type",{"_key":870,"_type":71,"marks":871,"text":872},"6016613497581",[],": Focus on the purpose of the variable, not its implementation. Common names that break this rule are ",{"_key":874,"_type":71,"marks":875,"text":876},"6016613497582",[289],"array",{"_key":878,"_type":71,"marks":879,"text":626},"6016613497583",[],{"_key":881,"_type":71,"marks":882,"text":883},"6016613497584",[289],"number\u002Fnum",{"_key":885,"_type":71,"marks":886,"text":626},"6016613497585",[],{"_key":888,"_type":71,"marks":889,"text":890},"6016613497586",[289],"list",{"_key":892,"_type":71,"marks":893,"text":626},"6016613497587",[],{"_key":895,"_type":71,"marks":896,"text":897},"6016613497588",[289],"word",{"_key":899,"_type":71,"marks":900,"text":626},"6016613497589",[],{"_key":902,"_type":71,"marks":903,"text":904},"60166134975810",[289],"string",{"_key":906,"_type":71,"marks":907,"text":908},"60166134975811",[],". Syntax is usually clear from the code, so you don’t need to add ",{"_key":910,"_type":71,"marks":911,"text":912},"60166134975812",[289],"function",{"_key":914,"_type":71,"marks":915,"text":916},"60166134975813",[]," or the type to the variable name: ",{"_key":918,"_type":71,"marks":919,"text":920},"60166134975814",[289],"get_average_function",{"_key":922,"_type":71,"marks":923,"text":797},"60166134975815",[],{"_key":925,"_type":71,"marks":926,"text":927},"60166134975816",[289],"array_of_prices",{"_key":929,"_type":71,"marks":930,"text":931},"60166134975817",[],". As a general rule, your name shouldn’t include the type of the variable (this is called “",{"_key":933,"_type":71,"marks":934,"text":936},"60166134975818",[935],"a897ce8db7eb","Hungarian notation",{"_key":938,"_type":71,"marks":939,"text":940},"60166134975819",[],"”). If you need to say ",{"_key":942,"_type":71,"marks":943,"text":944},"60166134975820",[289],"admission_numbers",{"_key":946,"_type":71,"marks":947,"text":948},"60166134975821",[],", keep looking for a better name (",{"_key":950,"_type":71,"marks":951,"text":952},"60166134975822",[289],"daily_admissions",{"_key":954,"_type":71,"marks":955,"text":956},"60166134975823",[],".)",[958],{"_key":935,"_type":94,"href":959,"reference":96},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FHungarian_notation",{"_key":961,"_type":67,"children":962,"level":303,"listItem":304,"markDefs":986,"style":97},"604e7de166e8",[963,967,971,975,979,982],{"_key":964,"_type":71,"marks":965,"text":966},"604e7de166e80",[573],"Don’t use abbreviations",{"_key":968,"_type":71,"marks":969,"text":970},"604e7de166e81",[],": Is ",{"_key":972,"_type":71,"marks":973,"text":974},"604e7de166e82",[289],"det",{"_key":976,"_type":71,"marks":977,"text":978},"604e7de166e83",[]," “detail”, “detrimental”, “deterministic”, “Detroit”, or something else? Our earlier ",{"_key":980,"_type":71,"marks":981,"text":801},"604e7de166e84",[289],{"_key":983,"_type":71,"marks":984,"text":985},"604e7de166e85",[]," falls into this category.",[],{"_key":988,"_type":67,"children":989,"level":303,"listItem":304,"markDefs":998,"style":97},"83b29a698160",[990,994],{"_key":991,"_type":71,"marks":992,"text":993},"83b29a6981600",[573],"Don’t use one-letter names",{"_key":995,"_type":71,"marks":996,"text":997},"83b29a6981601",[],": These are abbreviations on steroids—they’re completely incomprehensible! Instead, describe what the variable’s purpose is.\n\nThere are a few uncommon exceptions to this: ",[],{"_key":1000,"_type":67,"children":1001,"level":1013,"listItem":304,"markDefs":1014,"style":97},"4fb629aae1dc",[1002,1006,1010],{"_key":1003,"_type":71,"marks":1004,"text":1005},"4fb629aae1dc0",[],"Loops, where it’s common to refer to the index as ",{"_key":1007,"_type":71,"marks":1008,"text":1009},"4fb629aae1dc1",[289],"i",{"_key":1011,"_type":71,"marks":1012,"text":467},"4fb629aae1dc2",[],2,[],{"_key":1016,"_type":67,"children":1017,"level":1013,"listItem":304,"markDefs":1022,"style":97},"df1a31204e41",[1018],{"_key":1019,"_type":71,"marks":1020,"text":1021},"df1a31204e410",[],"Scientific and mathematical conventions, as long as you’re certain they’ll be clear to other developers.",[],{"_key":1024,"_type":67,"children":1025,"level":1013,"listItem":304,"markDefs":1046,"style":97},"d1cfb9235bd5",[1026,1030,1034,1038,1042],{"_key":1027,"_type":71,"marks":1028,"text":1029},"d1cfb9235bd50",[],"Domain-specific conventions (for example, in JavaScript, webpage events are often referred to as ",{"_key":1031,"_type":71,"marks":1032,"text":1033},"d1cfb9235bd51",[289],"e",{"_key":1035,"_type":71,"marks":1036,"text":1037},"d1cfb9235bd52",[]," instead of ",{"_key":1039,"_type":71,"marks":1040,"text":1041},"d1cfb9235bd53",[289],"event",{"_key":1043,"_type":71,"marks":1044,"text":1045},"d1cfb9235bd54",[],").",[],{"_key":1048,"_type":67,"children":1049,"markDefs":1054,"style":97},"e98e92152029",[1050],{"_key":1051,"_type":71,"marks":1052,"text":1053},"e98e921520290",[],"These are exceptions—99% of your variables should have descriptive, multi-letter names!",[],{"_key":1056,"_type":67,"children":1057,"markDefs":1062,"style":75},"9bf72d2c1c72",[1058],{"_key":1059,"_type":71,"marks":1060,"text":1061},"9bf72d2c1c720",[],"3. Avoid reassigning variables",[],{"_key":1064,"_type":67,"children":1065,"markDefs":1093,"style":97},"ff8810ce35e1",[1066,1070,1074,1078,1082,1086,1090],{"_key":1067,"_type":71,"marks":1068,"text":1069},"ff8810ce35e10",[],"The following problematic function takes some ",{"_key":1071,"_type":71,"marks":1072,"text":1073},"ff8810ce35e11",[289],"input",{"_key":1075,"_type":71,"marks":1076,"text":1077},"ff8810ce35e12",[],", transforms it with ",{"_key":1079,"_type":71,"marks":1080,"text":1081},"ff8810ce35e13",[289],"seasonal_multiplier",{"_key":1083,"_type":71,"marks":1084,"text":1085},"ff8810ce35e14",[],", adds a mystical 14, and returns ",{"_key":1087,"_type":71,"marks":1088,"text":1089},"ff8810ce35e15",[289],"result",{"_key":1091,"_type":71,"marks":1092,"text":467},"ff8810ce35e16",[],[],{"_key":1095,"_type":289,"code":1096,"markDefs":96},"4c7b59015fe9","function get_result(list, seasonal_multiplier) {\n\tint result = list;\n\tresult = list.sum \u002F list.length;\n\tresult = result * seasonal_multiplier;\n\tresult = result + 14;\n\t\n\treturn result;\n}",{"_key":1098,"_type":67,"children":1099,"markDefs":1111,"style":97},"491c366de4be",[1100,1104,1107],{"_key":1101,"_type":71,"marks":1102,"text":1103},"491c366de4be0",[],"Putting aside the opaque variable names, ",{"_key":1105,"_type":71,"marks":1106,"text":1089},"491c366de4be1",[289],{"_key":1108,"_type":71,"marks":1109,"text":1110},"491c366de4be2",[]," represents four different things during the course of this function. It starts out as the input, then becomes input per participant, then input per participant adjusted for the seasonal multiplier, and is then finally returned with a magical 14 tacked on. It’s doing too much work!\n\nMost languages allow you to assign a new value to a new variable. In practice, this is usually not a great idea. A variable should represent one thing, and change its identity during its lifespan. When you look at a variable name, you should have a good sense for what its purpose is.",[],{"_key":1113,"_type":67,"children":1114,"markDefs":1119,"style":97},"e3bc09d76a7a",[1115],{"_key":1116,"_type":71,"marks":1117,"text":1118},"e3bc09d76a7a0",[],"There are two ways to clear up this code:",[],{"_key":1121,"_type":67,"children":1122,"markDefs":1131,"style":97},"118a1b53299d",[1123,1127],{"_key":1124,"_type":71,"marks":1125,"text":1126},"118a1b53299d0",[573],"1. Be clear about what the changes are. ",{"_key":1128,"_type":71,"marks":1129,"text":1130},"118a1b53299d1",[],"A better way is to be explicit about what each transformation is, declaring a new variable at each step. This might seem like over-explaining at first, but it makes the function much easier to comprehend.",[],{"_key":1133,"_type":289,"code":1134,"markDefs":96},"c9e6658b54e8","function get_result(list, seasonal_multiplier) {\n\toutput_per_participant = list.sum \u002F list.length;\n\tseasonal_output_per_participant = output_per_participant * seasonal_multiplier;\n\tadjusted_seasonal_output_per_participant = seasonal_output_per_participant + 14;\n\t\n\treturn adjusted_seasonal_output_per_participant;\n}",{"_key":1136,"_type":67,"children":1137,"markDefs":1149,"style":97},"0a036aad2508",[1138,1142,1146],{"_key":1139,"_type":71,"marks":1140,"text":1141},"0a036aad25080",[],"As a final step, I’d probably rename the function ",{"_key":1143,"_type":71,"marks":1144,"text":1145},"0a036aad25081",[289],"get_adjusted_seasonal_output_per_participant()",{"_key":1147,"_type":71,"marks":1148,"text":703},"0a036aad25082",[],[],{"_key":1151,"_type":67,"children":1152,"markDefs":1161,"style":97},"2ed4ffa69821",[1153,1157],{"_key":1154,"_type":71,"marks":1155,"text":1156},"2ed4ffa698210",[573],"2. Combine the math into one line. ",{"_key":1158,"_type":71,"marks":1159,"text":1160},"2ed4ffa698211",[],"You can avoid this problem altogether by combining all the steps into one calculation. The reader then has to follow a lot of math at once, but at least the intent of the variable is clear, and one variable has one meaning throughout the function",[],{"_key":1163,"_type":289,"code":1164,"markDefs":96},"7d9bd091193f","function list, seasonal_multiplier(input) {\n\tadjusted_seasonal_output_per_participant = list.sum \u002F list.length *  seasonal_multiplier + 14;\n\treturn adjusted_seasonal_output_per_participant;\n}",{"_key":1166,"_type":67,"children":1167,"markDefs":1172,"style":97},"1f1f52468684",[1168],{"_key":1169,"_type":71,"marks":1170,"text":1171},"1f1f524686840",[],"You might also wonder what that 14 represents. That’s what we call a magic number.",[],{"_key":1174,"_type":67,"children":1175,"markDefs":1180,"style":75},"975735e96e95",[1176],{"_key":1177,"_type":71,"marks":1178,"text":1179},"975735e96e950",[],"4. Avoid magic numbers",[],{"_key":1182,"_type":67,"children":1183,"markDefs":1188,"style":97},"07889a1c96c1",[1184],{"_key":1185,"_type":71,"marks":1186,"text":1187},"07889a1c96c10",[],"A number used without any context is called a “magic number,” and it makes the code harder to comprehend. Here’s a bit of incomprehensible code:",[],{"_key":1190,"_type":289,"code":1191,"markDefs":96},"38a3e01f7064","int yearly_total = monthly_average * 12 + 67.3;",{"_key":1193,"_type":67,"children":1194,"markDefs":1223,"style":97},"692dc754bfbe",[1195,1199,1203,1207,1211,1215,1219],{"_key":1196,"_type":71,"marks":1197,"text":1198},"692dc754bfbe0",[],"\n",{"_key":1200,"_type":71,"marks":1201,"text":1202},"692dc754bfbe1",[289],"monthly_average * 12",{"_key":1204,"_type":71,"marks":1205,"text":1206},"692dc754bfbe2",[]," ",{"_key":1208,"_type":71,"marks":1209,"text":1210},"692dc754bfbe3",[613],"probably",{"_key":1212,"_type":71,"marks":1213,"text":1214},"692dc754bfbe4",[]," refers to the number of months in a year (we deduce from the better named ",{"_key":1216,"_type":71,"marks":1217,"text":1218},"692dc754bfbe5",[289],"yearly_total",{"_key":1220,"_type":71,"marks":1221,"text":1222},"692dc754bfbe6",[],"). But we shouldn’t have to deduce. And what the heck is 67.3? It might have made perfect sense to the code’s author, but we’re left to scratch our heads.",[],{"_key":1225,"_type":67,"children":1226,"markDefs":1231,"style":97},"5588c5bf7a03",[1227],{"_key":1228,"_type":71,"marks":1229,"text":1230},"5588c5bf7a030",[],"A better approach is to assign numbers to well-named variables, then use those in calculations.",[],{"_key":1233,"_type":289,"code":1234,"markDefs":96},"1a89a9f1c9ee","int total_at_beginning_of_year = 67.3;\nint months_per_year = 12;\nint yearly_total = monthly_average * months_per_year + total_at_beginning_of_year;",{"_key":1236,"_type":67,"children":1237,"markDefs":1242,"style":75},"a252771e3608",[1238],{"_key":1239,"_type":71,"marks":1240,"text":1241},"a252771e36080",[],"5. Use few parameters",[],{"_key":1244,"_type":67,"children":1245,"markDefs":1259,"style":97},"17aa91161f07",[1246,1250,1255],{"_key":1247,"_type":71,"marks":1248,"text":1249},"17aa91161f070",[],"Functions take inputs (",{"_key":1251,"_type":71,"marks":1252,"text":1254},"17aa91161f071",[1253],"1a7572b9c857","referred to",{"_key":1256,"_type":71,"marks":1257,"text":1258},"17aa91161f072",[]," as “parameters” and “arguments”). In most languages, the order of the inputs matters. Let’s say you have a function that takes a fruit, a country, and a year, and tells you the average price for this fruit in that country and year.",[1260],{"_key":1253,"_type":94,"href":1261,"reference":96},"https:\u002F\u002Fstackoverflow.com\u002Fquestions\u002F156767\u002Fwhats-the-difference-between-an-argument-and-a-parameter",{"_key":1263,"_type":289,"code":1264,"markDefs":96},"4ecf83253a8b","function getAverageFruitPrice(fruit, country, year) {\n    \u002F\u002F get and return the price\n}",{"_key":1266,"_type":67,"children":1267,"markDefs":1280,"style":97},"5a2298e1e3d0",[1268,1272,1276],{"_key":1269,"_type":71,"marks":1270,"text":1271},"5a2298e1e3d00",[],"This seems good so far. To get a price, you can call ",{"_key":1273,"_type":71,"marks":1274,"text":1275},"5a2298e1e3d01",[289],"get_average_fruit_price(“peach”, “Albania”, 2007)",{"_key":1277,"_type":71,"marks":1278,"text":1279},"5a2298e1e3d02",[],". But what if we want to narrow the price further by adding an option to only count fruit sold industrially (for example, to juice companies)?",[],{"_key":1282,"_type":67,"children":1283,"markDefs":1311,"style":97},"497eff999780",[1284,1288,1292,1296,1300,1303,1307],{"_key":1285,"_type":71,"marks":1286,"text":1287},"497eff9997800",[],"No problem! We can just add a new boolean parameter, function ",{"_key":1289,"_type":71,"marks":1290,"text":1291},"497eff9997801",[289],"get_average_fruit_price(fruit, country, year, sold_to_industry)",{"_key":1293,"_type":71,"marks":1294,"text":1295},"497eff9997802",[],". But remember, we’ll need to pass in the arguments in the right order, and that’s an easy thing to mess up. We’ll need to check the function definition every time we want to call it! If you mess up and write ",{"_key":1297,"_type":71,"marks":1298,"text":1299},"497eff9997803",[289],"get_average_fruit_price(“peach”, 2007, “Albania”, false)",{"_key":1301,"_type":71,"marks":1302,"text":626},"497eff9997804",[],{"_key":1304,"_type":71,"marks":1305,"text":1306},"497eff9997805",[289],"year",{"_key":1308,"_type":71,"marks":1309,"text":1310},"497eff9997806",[]," is now “Albania”!",[],{"_key":1313,"_type":67,"children":1314,"markDefs":1319,"style":97},"df3763ad3105",[1315],{"_key":1316,"_type":71,"marks":1317,"text":1318},"df3763ad31050",[],"A good general rule is to keep your input count to two to three at the most. This way, developers building on top of your code don’t have to constantly check for the correct orders, and are less likely to make mistakes.",[],{"_key":1321,"_type":67,"children":1322,"markDefs":1327,"style":97},"510cb4f5e820",[1323],{"_key":1324,"_type":71,"marks":1325,"text":1326},"510cb4f5e8200",[],"There are two ways to improve a function that takes too many inputs:",[],{"_key":1329,"_type":67,"children":1330,"level":303,"listItem":304,"markDefs":1335,"style":97},"2ed3334c4121",[1331],{"_key":1332,"_type":71,"marks":1333,"text":1334},"2ed3334c41210",[],"Break it up into smaller functions. Too many parameters could be an indicator that your function is doing too much.",[],{"_key":1337,"_type":67,"children":1338,"level":303,"listItem":304,"markDefs":1351,"style":97},"0d93b8521396",[1339,1343,1347],{"_key":1340,"_type":71,"marks":1341,"text":1342},"0d93b85213960",[],"Use an options object. If you can pass the parameters in an object (called a hash or a dictionary in some languages), you don’t have to worry about property order. This object is often called ",{"_key":1344,"_type":71,"marks":1345,"text":1346},"0d93b85213961",[289],"options",{"_key":1348,"_type":71,"marks":1349,"text":1350},"0d93b85213962",[]," and referred to an “options object.” The downside to this approach is that it’s less explicit about the expected parameters. Here’s how this looks in practice:",[],{"_key":1353,"_type":289,"code":1354,"markDefs":96},"14aade8747a0","function get_average_fruit_price(options) {\n    \u002F\u002F use options.fruit, options.country, options.year, options.sold_to_industry\n}",{"_key":1356,"_type":67,"children":1357,"markDefs":1362,"style":75},"b7292f4033fb",[1358],{"_key":1359,"_type":71,"marks":1360,"text":1361},"b7292f4033fb0",[],"6. Write good comments",[],{"_key":1364,"_type":67,"children":1365,"markDefs":1379,"style":97},"f9b6c6d56839",[1366,1370,1375],{"_key":1367,"_type":71,"marks":1368,"text":1369},"f9b6c6d568390",[],"There are a lot of ",{"_key":1371,"_type":71,"marks":1372,"text":1374},"f9b6c6d568391",[1373],"b4b3536e7a76","great, thorough rules",{"_key":1376,"_type":71,"marks":1377,"text":1378},"f9b6c6d568392",[]," around code comments, but we’ll focus on the low-hanging fruit…",[1380],{"_key":1373,"_type":94,"href":1381,"reference":96},"https:\u002F\u002Fstackoverflow.blog\u002F2021\u002F12\u002F23\u002Fbest-practices-for-writing-code-comments\u002F",{"_key":1383,"_type":67,"children":1384,"markDefs":1389,"style":97},"a7ec0a47bb9c",[1385],{"_key":1386,"_type":71,"marks":1387,"text":1388},"a7ec0a47bb9c0",[],"Use comments sparingly to explain code that’s not otherwise clear. If you can improve the code instead, do that! Here’s an example of a bad comment covering up for unclear code:",[],{"_key":1391,"_type":289,"code":1392,"markDefs":96},"b3d68d75cdb6"," int f = 75; \u002F\u002F f is the temperature in Fahrenheit",{"_key":1394,"_type":67,"children":1395,"markDefs":1415,"style":97},"0023c5fefe97",[1396,1400,1404,1407,1411],{"_key":1397,"_type":71,"marks":1398,"text":1399},"0023c5fefe970",[],"Let the code speak for itself by renaming ",{"_key":1401,"_type":71,"marks":1402,"text":1403},"0023c5fefe971",[289],"f",{"_key":1405,"_type":71,"marks":1406,"text":514},"0023c5fefe972",[],{"_key":1408,"_type":71,"marks":1409,"text":1410},"0023c5fefe973",[289],"temp_in_farenheit",{"_key":1412,"_type":71,"marks":1413,"text":1414},"0023c5fefe974",[],"!",[],{"_key":1417,"_type":67,"children":1418,"markDefs":1423,"style":97},"b6830710b1bb",[1419],{"_key":1420,"_type":71,"marks":1421,"text":1422},"b6830710b1bb0",[],"You won’t always have time to improve the hard-to-comprehend code you see. You might also write code you’re not thrilled with due to time constraints. Consider whether the code will need to be “touched” (read or modified) by someone else. Be honest — you don’t want to pass on code that’s hard to maintain!",[],{"_key":1425,"_type":67,"children":1426,"markDefs":1431,"style":97},"ede5ba3a594a",[1427],{"_key":1428,"_type":71,"marks":1429,"text":1430},"ede5ba3a594a0",[],"If the code isn’t likely to be modified by anyone else, you can leave a comment explaining what a particularly challenging bit of code does. Ideally, your function and variable names should already do this. But when the functions contain logic that’s hard to comprehend and the function name doesn’t help, leave a comment!",[],{"_key":1433,"_type":67,"children":1434,"markDefs":1439,"style":75},"e34e79b52317",[1435],{"_key":1436,"_type":71,"marks":1437,"text":1438},"e34e79b523170",[],"7. Don’t repeat yourself",[],{"_key":1441,"_type":67,"children":1442,"markDefs":1447,"style":97},"3468127ec604",[1443],{"_key":1444,"_type":71,"marks":1445,"text":1446},"3468127ec6040",[],"The DRY principle stands for “don’t repeat yourself.” If you find yourself using the same code in multiple places, see if you can pull it out into a variable or a function.",[],{"_key":1449,"_type":289,"code":1450,"markDefs":96},"8d86740b4c7d","string company_description = “Fruit Trucking & Shipping International ships fruit on our modern fleet of trucks and ships, anywhere in the world!”\nstring company_slogan = “Fruit Trucking & Shipping International: where the best fruits get on the best ships”",{"_key":1452,"_type":289,"code":1453,"markDefs":96},"6da7b92c7dfe","string company_name = “Fruit Trucking & Shipping International”\nstring company_description = company_name + “ ships fruit on our modern fleet of trucks and ships, anywhere in the world!”\nstring company_slogan = company_name + “: where the best fruit gets on the best ships”",{"_key":1455,"_type":67,"children":1456,"markDefs":1461,"style":97},"fd1a73c8dd50",[1457],{"_key":1458,"_type":71,"marks":1459,"text":1460},"fd1a73c8dd500",[],"If the company ever changes its name (for example, if it decides to only ship apples…) we can now do this in one place. Conversely, if you don’t follow DRY, you’ll need to find all the places you have duplicated code and remember to make changes in each of them.",[],{"_key":1463,"_type":67,"children":1464,"markDefs":1485,"style":97},"0a68e202e691",[1465,1469,1473,1477,1481],{"_key":1466,"_type":71,"marks":1467,"text":1468},"0a68e202e6910",[],"Here’s another example: let’s say all your input temperatures are in Farenheit, but you need your output values to be in Celsius. Everytime you work with a temperature, you’ll need to ",{"_key":1470,"_type":71,"marks":1471,"text":1472},"0a68e202e6911",[289],"F - 32 * 5\u002F9",{"_key":1474,"_type":71,"marks":1475,"text":1476},"0a68e202e6912",[],". If you find out your organization now uses Kelvin , you’ll have to update this to ",{"_key":1478,"_type":71,"marks":1479,"text":1480},"0a68e202e6913",[289],"F - 32 * 5\u002F9 + 273.15",{"_key":1482,"_type":71,"marks":1483,"text":1484},"0a68e202e6914",[]," every place you reference a temperature.",[],{"_key":1487,"_type":67,"children":1488,"markDefs":1493,"style":97},"bd9f3ab156f9",[1489],{"_key":1490,"_type":71,"marks":1491,"text":1492},"bd9f3ab156f90",[],"A better solution is to pull this conversion into a function:",[],{"_key":1495,"_type":289,"code":1496,"markDefs":96},"fdfd41e6c145","function fahrenheit_to_celsius(temp_in_farenheit) {\n   return temp_in_farenheit - 32 * 5\u002F9;\n}\n",{"_key":1498,"_type":67,"children":1499,"markDefs":1526,"style":97},"024b435a6523",[1500,1504,1508,1512,1516,1519,1522],{"_key":1501,"_type":71,"marks":1502,"text":1503},"024b435a65230",[],"Now to switch to Kelvin, you can update the calculation in one place. In this particular example, you could probably just create a new (small, single-purpose) function called ",{"_key":1505,"_type":71,"marks":1506,"text":1507},"024b435a65231",[289],"fahrenheit_to_kelvin()",{"_key":1509,"_type":71,"marks":1510,"text":1511},"024b435a65232",[],", and all the calls to ",{"_key":1513,"_type":71,"marks":1514,"text":1515},"024b435a65233",[289],"fahrenheit_to_celsius()",{"_key":1517,"_type":71,"marks":1518,"text":514},"024b435a65234",[],{"_key":1520,"_type":71,"marks":1521,"text":1507},"024b435a65235",[289],{"_key":1523,"_type":71,"marks":1524,"text":1525},"024b435a65236",[],". Now it’s very clear where you’re updating (you don’t have to look for mentions of “temperature” all throughout your code.)",[],{"_key":1528,"_type":67,"children":1529,"markDefs":1534,"style":97},"35399d3ba05d",[1530],{"_key":1531,"_type":71,"marks":1532,"text":1533},"35399d3ba05d0",[],"It’s possible to overdo DRY. You don’t want to over-optimize too early, so a good alternative to DRY is WET, or “write everything twice”. If you need to write some code a third time, it’s probably a good idea to try and pull this out into its own function or variable. Over time, you’ll develop judgment for when to reuse the same piece of code over and over (like the example above) and when a few repeated lines are a part of separate processes.",[],{"_key":1536,"_type":67,"children":1537,"markDefs":1542,"style":75},"b184dc978516",[1538],{"_key":1539,"_type":71,"marks":1540,"text":1541},"b184dc9785160",[],"Next steps",[],{"_key":1544,"_type":67,"children":1545,"markDefs":1550,"style":97},"a347dd2767ed",[1546],{"_key":1547,"_type":71,"marks":1548,"text":1549},"a347dd2767ed0",[],"Reading about good coding practices is like reading about working out. You have to follow the practices to reap the benefits!",[],{"_key":1552,"_type":67,"children":1553,"markDefs":1558,"style":97},"43fffc4ab71c",[1554],{"_key":1555,"_type":71,"marks":1556,"text":1557},"43fffc4ab71c0",[],"Just because you learned about all the muscles doesn’t mean you need to exercise them all right away. Start small: the next time you code, try to be precise with your names. Then, try to write smaller functions. Then, reference this article to see what else you might have missed! Think of it like starting your fitness regimen with a few exercises a week.",[],{"_key":1560,"_type":67,"children":1561,"markDefs":1566,"style":97},"c39296dd1895",[1562],{"_key":1563,"_type":71,"marks":1564,"text":1565},"c39296dd18950",[],"Remember, we’re writing code for our future colleagues, and, importantly, our future selves. We don’t need to be dogmatic about the rules; we just need to focus on being as clear as we can.",[],{"_key":1568,"_type":67,"children":1569,"markDefs":1574,"style":97},"db399fd99c3b",[1570],{"_key":1571,"_type":71,"marks":1572,"text":1573},"db399fd99c3b0",[],"You’ll quickly find that writing clean code involves making tradeoffs. For example, if you’re under time pressure writing a one-off script to parse some data and are confident nobody will see the script again, you can invest less time into writing clear code. But over time, thinking about code maintainability and readability will empower you to solve problems more effectively and will set you apart from many beginner developers..",[],{"_key":1576,"_type":67,"children":1577,"markDefs":1582,"style":97},"779a3ab9b92e",[1578],{"_key":1579,"_type":71,"marks":1580,"text":1581},"779a3ab9b92e0",[],"By implementing some basic software dev principles, you’re leveling up from someone hacking through code to someone maintaining and building software. And that’s something to be proud of!",[],"2023\u002F02\u002F13","That bootcamp may have taught you to write code that works. But the next level is to write code that works with other people. ",{"_type":56,"asset":1586},{"_ref":1587,"_type":59},"image-fb5b6974753c66ad9c51da025e715370a09f6531-2560x1344-jpg",{"code":1589,"language":1590},"\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-we-re-all-coders-now\">We’re all coders now\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>In the 1980s, personal computers \u003Ca href=\"https:\u002F\u002Fwww.bbc.com\u002Fnews\u002Fmagazine-23509153\">became common\u003C\u002Fa> in the workplace. With the release of the Apple II in 1977 and the IBM PC four years later, a tool once reserved for scientists and the military proliferated in accounting offices, universities, and hospitals. You no longer had to be an engineer to use a computer.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Something similar has happened with programming over the past decade. In everyday offices, classrooms, and laboratories, code is now being written and maintained by people who don’t think of themselves as programmers.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The good news is that it’s easier than ever to write code that works. There’s no shortage of beginner-friendly programming tutorials, and high-level languages today are more readable than ever. So, if someone at work hands you a Python script to run over some data, between \u003Ca href=\"https:\u002F\u002Fstackoverflow.com\u002F\">Stack Overflow\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fwww.codecademy.com\u002F\">Codecademy\u003C\u002Fa> you can probably figure out how to get it to work.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The bad news is that after you write the code you just learned to write, someone is going to have to read it (that someone might be you in six months). To a beginner, getting a working solution is the finish line. To a developer, it’s only the starting line. And since more of us are writing and collaborating on code than ever before, it’s becoming crucial to write better code.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There’s a lot to learn about basic programming beyond “making it work.” For professional developers, writing maintainable code is fundamental to the job. But these practices aren’t usually discussed in “Coding 101”. Beginner tutorials usually focus on syntax.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>So we’ll assume you already know how to pull together a working solution — it’s time to  level up to Coding 102: writing code with and for other humans.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-prerequisites\">Prerequisites\u003C\u002Fh3>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>We’ll keep our examples short and simple and write them in \u003Ca href=\"https:\u002F\u002Fwww.hackterms.com\u002Fpseudocode\">pseudocode\u003C\u002Fa> (which should seem familiar if you’ve written in a popular language). This post is aimed at people who’ve spent time writing code, but don’t write it professionally full-time. It helps if you are familiar with variables, functions, and if\u002Felse statements.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-why-writing-better-code-matters\">Why writing better code matters\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There’s an adage in programming that \u003Ca href=\"https:\u002F\u002Fweb.archive.org\u002Fweb\u002F20120313070806\u002Fhttp:\u002F\u002Fusers.jyu.fi\u002F~koskinen\u002Fsmcosts.htm\">maintaining code is 75% of its total cost\u003C\u002Fa>. Once you write the code, other people (including future you) will invest two to three times as much time, on average, in reading, updating, and fixing it. This doesn’t mean your code was badly written or buggy! Requirements evolve, other parts of the code change, and sometimes… well, yeah, sometimes there are bugs.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>At one of my first (non-programming) jobs, I wrote a script that switched between browser tabs with user accounts and pasted in discount codes. At the time, this task was done by hand for hundreds of users each month.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>I hacked the script together in a few hours, and, to my manager’s delight, it pasted hundreds of codes in a few minutes. But the following week, the script went haywire and applied the code to 300 wrong accounts. It took me two hours to code the script, but eight hours to undo the damage it caused and fix my convoluted code. That's the maintenance cost.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Good design “reduces the cost of future changes.” Let’s say my company changed the layout of the discount code page. How long would it take someone to update my script to work with the new layout? If another developer offered to help, how long would it take them to get up to speed on my work? That depends on how well the code was designed.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>In order to make code easy to maintain, update, and fix, it should be modular, easy to follow, and easy to reason about. Writing “clean” code (as it’s often called) will help you think through the problem. If other people you work with can embrace these practices, you’ll spend less time struggling and more time collaborating productively.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-coding-102\">Coding 102\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Now that we understand why maintainable, clean code matters, let’s talk about how to write it.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-1-write-small-functions\">1. Write small functions\u003C\u002Fh3>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Aim to write small functions that do one thing. Let’s say you’re writing a function that takes a list of widget prices and returns some text with the average of those prices. For example, you give it [13, 28, 17, 143, 184, 72.3] and it should return “The average price for 6 widgets is $72.22.”\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A first attempt at this code might be a function called \u003Ccode>get_price_average(data)\u003C\u002Fcode> that:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003C!-- wp:list-item -->\n\u003Cli>Takes some data\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Gets the length of the number list\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Gets the sum of the prices\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Divides the sum by the number of widgets to get the average\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Rounds the average\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Assembles all the stats into a string of text and prints it\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Depending on the language, some of these operations might be built in. You put these steps in one function, and it works. This is a fine, typical first version.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>On the plus side, the code is cohesive: everything we’re doing related to the stats text is in one place. So if you need to change anything having to do with this text, you know where to look.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The problem is that if you do need to make a change (add a stat, clarify which numbers should be averaged, or change the decimal points on the average), you’ll need to read and understand the whole function. And adding the change will just balloon it further.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The solution is to break our oversized \u003Ccode>get_price_average()\u003C\u002Fcode>, which does many things, into several small functions that each do one thing. A good guideline is:\u003Cbr>\u003Cbr>> A function should be small, do just one thing, and ideally shouldn’t impact anything outside the function\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Let’s try to see this by example. Here’s how we might break the function up.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003C!-- wp:list-item -->\n\u003Cli>\u003Ccode>get_widget_price_stats(data)\u003C\u002Fcode>: we’re renaming our wrapper function, \u003Ccode>get_price_average()\u003C\u002Fcode>. It now takes some data, extracts the relevant stat and returns texts with that stat. We’ll talk about names shortly!\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Ccode>get_max(list_of_numbers)\u003C\u002Fcode>: gets the largest number in a list. Depending on the language you use, this might be part of the standard library.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Ccode>get_min(list_of_numbers)\u003C\u002Fcode>: gets the smallest number in a list. Depending on the language you use, this might be part of the standard library.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Ccode>get_sum(list_of_numbers)\u003C\u002Fcode>: gets the sum in a list of numbers.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Ccode>get_average(list_of_numbers, decimal_points)\u003C\u002Fcode>: takes a list of numbers and returns the average, rounded to \u003Ccode>decimal_points\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Did you find some of those function descriptions obvious? For example, it might be pretty clear that \u003Ccode>get_max(list_of_numbers)\u003C\u002Fcode> gets the largest number in a list. Good! That’s by design. When you write small functions that have clear single responsibilities, you can give them names that clearly convey what they do. Then, your future readers don’t have to read all the code in the function to understand what it does.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>How does this design respond to changes? Let’s say instead of the average, you need to return the standard deviation. In the initial version, we’d need to find the section of the code that calculates the average and overwrite it with a standard deviation calculation.\u003Cbr>\u003Cbr>In the small-function version, we could create a new function, \u003Ccode>get_standard_deviation(list)\u003C\u002Fcode>, then go into \u003Ccode>get_widget_price_stats()\u003C\u002Fcode> and replace the call to \u003Ccode>get_average()\u003C\u002Fcode> to \u003Ccode>get_standard_deviation()\u003C\u002Fcode>.\u003Cbr>\u003Cbr>To recap, the functions we break out should be small, self-contained, and do one thing. This makes it much easier to read and change your code. This practice alone will improve your code significantly.\u003Cbr>\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-2-pick-names-carefully\">2. Pick names carefully\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There’s a running joke that “there are two hard things in computer science: cache invalidation and naming things.” We’re going to leave cache invalidation for another post and focus on naming things.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A related idea is that “\u003Ca href=\"https:\u002F\u002Fstackoverflow.com\u002Fa\u002F209065\u002F3434304\">good code is self-documenting\u003C\u002Fa>.” In essence, this means that good code conveys what it does. Names are a big part of this: a good name is precise, easy to understand, and gives the code context without having to read every line.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Here are some good naming practices:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003C!-- wp:list-item -->\n\u003Cli>\u003Cstrong>Describe intent\u003C\u002Fstrong>: Try to describe the variable or function you’re naming as specifically as you can. For example, the function we looked at above was called \u003Ccode>get_price_average\u003C\u002Fcode>. However, since the string we’re returning is actually an average of widget prices, we could name the function more precisely: \u003Ccode>get_widget_price_average()\u003C\u002Fcode>. Later, we wanted it to serve as a wrapper function that returned some stat, so we renamed it to \u003Ccode>get_widget_price_stats()\u003C\u002Fcode> From this function, we extracted a general \u003Ccode>average\u003C\u002Fcode> function that takes a list of \u003Cem>any\u003C\u002Fem> numbers and returns the average.\u003Cbr>\u003Cbr>Try to avoid general names like \u003Ccode>date\u003C\u002Fcode>, \u003Ccode>slice\u003C\u002Fcode>, \u003Ccode>part\u003C\u002Fcode>, \u003Ccode>numbers\u003C\u002Fcode>. Instead, depending on context, \u003Ccode>date\u003C\u002Fcode> might become \u003Ccode>created_at\u003C\u002Fcode>, \u003Ccode>slice\u003C\u002Fcode> might become \u003Ccode>outdated_prices\u003C\u002Fcode>, \u003Ccode>part\u003C\u002Fcode> might become \u003Ccode>part_to_be_fixed\u003C\u002Fcode>, and \u003Ccode>numbers\u003C\u002Fcode> might become \u003Ccode>current_row\u003C\u002Fcode>.\u003Cbr>\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Cstrong>Be consistent\u003C\u002Fstrong>: Whichever convention you decide to use, stick with it. If the codebase uses \u003Ccode>get_\u003C\u002Fcode> for functions that return values, each function should be \u003Ccode>get_[stat]\u003C\u002Fcode>: \u003Ccode>get_average\u003C\u002Fcode>, \u003Ccode>get_max\u003C\u002Fcode>, etc. If you name a function that returns standard deviation \u003Ccode>standard_deviation\u003C\u002Fcode>, another dev will wonder how it’s different from all the \u003Ccode>get_[stat]\u003C\u002Fcode> functions.\u003Cbr>\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Cstrong>Give the right amount of information\u003C\u002Fstrong>. A variable called \u003Ccode>first_name\u003C\u002Fcode> conveys a good amount of information. The alternative, \u003Ccode>name\u003C\u002Fcode> is too vague (first? last? middle? full?) and \u003Ccode>n\u003C\u002Fcode> or \u003Ccode>fn\u003C\u002Fcode> is downright indecipherable. These are examples of under-explaining; it’s not clear what the variable does.\u003Cbr>\u003Cbr>It’s also possible to over-explain: \u003Ccode>user_first_name\u003C\u002Fcode> doesn’t offer any additional information, since \u003Ccode>user\u003C\u002Fcode> is fairly generic, and it’s not clear what the alternative is (does the app have \u003Ccode>bots\u003C\u002Fcode> with first names?)  Similarly, \u003Ccode>first_name_for_user_record\u003C\u002Fcode>, or \u003Ccode>get_price_average_by_dividing_prices_by_quantity\u003C\u002Fcode> offer redundant information.\u003Cbr>\u003Cbr>Deciding on the right level of specificity is a skill you’ll build over time. It requires you step back and think deeply about what the variable is doing. This’ll make your code better in the long run and make you a better developer with it.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Speaking of how you shouldn’t call your variable \u003Ccode>fn\u003C\u002Fcode>, here’s a list of naming practices to avoid:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003C!-- wp:list-item -->\n\u003Cli>\u003Cstrong>Don’t include type\u003C\u002Fstrong>: Focus on the purpose of the variable, not its implementation. Common names that break this rule are \u003Ccode>array\u003C\u002Fcode>, \u003Ccode>number\u002Fnum\u003C\u002Fcode>, \u003Ccode>list\u003C\u002Fcode>, \u003Ccode>word\u003C\u002Fcode>, \u003Ccode>string\u003C\u002Fcode>. Syntax is usually clear from the code, so you don’t need to add \u003Ccode>function\u003C\u002Fcode> or the type to the variable name: \u003Ccode>get_average_function\u003C\u002Fcode> or \u003Ccode>array_of_prices\u003C\u002Fcode>. As a general rule, your name shouldn’t include the type of the variable (this is called “\u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FHungarian_notation\">Hungarian notation\u003C\u002Fa>”). If you need to say \u003Ccode>admission_numbers\u003C\u002Fcode>, keep looking for a better name (\u003Ccode>daily_admissions\u003C\u002Fcode>.)\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Cstrong>Don’t use abbreviations\u003C\u002Fstrong>: Is \u003Ccode>det\u003C\u002Fcode> “detail”, “detrimental”, “deterministic”, “Detroit”, or something else? Our earlier \u003Ccode>fn\u003C\u002Fcode> falls into this category.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>\u003Cstrong>Don’t use one-letter names\u003C\u002Fstrong>: These are abbreviations on steroids—they’re completely incomprehensible! Instead, describe what the variable’s purpose is.\u003Cbr>\u003Cbr>There are a few uncommon exceptions to this:\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003C!-- wp:list-item -->\n\u003Cli>Loops, where it’s common to refer to the index as \u003Ccode>i\u003C\u002Fcode>. \u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Scientific and mathematical conventions, as long as you’re certain they’ll be clear to other developers.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Domain-specific conventions (for example, in JavaScript, webpage events are often referred to as \u003Ccode>e\u003C\u002Fcode> instead of \u003Ccode>event\u003C\u002Fcode>).\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>These are exceptions—99% of your variables should have descriptive, multi-letter names!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-3-avoid-reassigning-variables\">3. Avoid reassigning variables\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The following problematic function takes some \u003Ccode>input\u003C\u002Fcode>, transforms it with \u003Ccode>seasonal_multiplier\u003C\u002Fcode>, adds a mystical 14, and returns \u003Ccode>result\u003C\u002Fcode>.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>function get_result(list, seasonal_multiplier) {\n\tint result = list;\n\tresult = list.sum \u002F list.length;\n\tresult = result * seasonal_multiplier;\n\tresult = result + 14;\n\t\n\treturn result;\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Putting aside the opaque variable names, \u003Ccode>result\u003C\u002Fcode> represents four different things during the course of this function. It starts out as the input, then becomes input per participant, then input per participant adjusted for the seasonal multiplier, and is then finally returned with a magical 14 tacked on. It’s doing too much work!\u003Cbr>\u003Cbr>Most languages allow you to assign a new value to a new variable. In practice, this is usually not a great idea. A variable should represent one thing, and change its identity during its lifespan. When you look at a variable name, you should have a good sense for what its purpose is.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There are two ways to clear up this code:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cstrong>1. Be clear about what the changes are. \u003C\u002Fstrong>A better way is to be explicit about what each transformation is, declaring a new variable at each step. This might seem like over-explaining at first, but it makes the function much easier to comprehend. \u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>function get_result(list, seasonal_multiplier) {\n\toutput_per_participant = list.sum \u002F list.length;\n\tseasonal_output_per_participant = output_per_participant * seasonal_multiplier;\n\tadjusted_seasonal_output_per_participant = seasonal_output_per_participant + 14;\n\t\n\treturn adjusted_seasonal_output_per_participant;\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>As a final step, I’d probably rename the function \u003Ccode>get_adjusted_seasonal_output_per_participant()\u003C\u002Fcode>.\u003Cbr>\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cstrong>2. Combine the math into one line. \u003C\u002Fstrong>You can avoid this problem altogether by combining all the steps into one calculation. The reader then has to follow a lot of math at once, but at least the intent of the variable is clear, and one variable has one meaning throughout the function\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>function list, seasonal_multiplier(input) {\n\tadjusted_seasonal_output_per_participant = list.sum \u002F list.length *  seasonal_multiplier + 14;\n\treturn adjusted_seasonal_output_per_participant;\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>You might also wonder what that 14 represents. That’s what we call a magic number.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-4-avoid-magic-numbers\">4. Avoid magic numbers\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A number used without any context is called a “magic number,” and it makes the code harder to comprehend. Here’s a bit of incomprehensible code:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>int yearly_total = monthly_average * 12 + 67.3;\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cbr>\u003Ccode>monthly_average * 12\u003C\u002Fcode> \u003Cem>probably\u003C\u002Fem> refers to the number of months in a year (we deduce from the better named \u003Ccode>yearly_total\u003C\u002Fcode>).  But we shouldn’t have to deduce. And what the heck is 67.3? It might have made perfect sense to the code’s author, but we’re left to scratch our heads.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A better approach is to assign numbers to well-named variables, then use those in calculations.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>int total_at_beginning_of_year = 67.3;\nint months_per_year = 12;\nint yearly_total = monthly_average * months_per_year + total_at_beginning_of_year;\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-5-use-few-parameters\">5. Use few parameters\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Functions take inputs (\u003Ca href=\"https:\u002F\u002Fstackoverflow.com\u002Fquestions\u002F156767\u002Fwhats-the-difference-between-an-argument-and-a-parameter\">referred to\u003C\u002Fa> as “parameters” and “arguments”). In most languages, the order of the inputs matters. Let’s say you have a function that takes a fruit, a country, and a year, and tells you the average price for this fruit in that country and year.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>function getAverageFruitPrice(fruit, country, year) {\n    \u002F\u002F get and return the price\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>This seems good so far. To get a price, you can call \u003Ccode>get_average_fruit_price(“peach”, “Albania”, 2007)\u003C\u002Fcode>. But what if we want to narrow the price further by adding an option to only count fruit sold industrially (for example, to juice companies)?\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>No problem! We can just add a new boolean parameter, function \u003Ccode>get_average_fruit_price(fruit, country, year, sold_to_industry)\u003C\u002Fcode>. But remember, we’ll need to pass in the arguments in the right order, and that’s an easy thing to mess up. We’ll need to check the function definition every time we want to call it! If you mess up and write \u003Ccode>get_average_fruit_price(“peach”, 2007, “Albania”, false)\u003C\u002Fcode>, \u003Ccode>year\u003C\u002Fcode> is now “Albania”!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A good general rule is to keep your input count to two to three at the most. This way, developers building on top of your code don’t have to constantly check for the correct orders, and are less likely to make mistakes.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There are two ways to improve a function that takes too many inputs:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003C!-- wp:list-item -->\n\u003Cli>Break it up into smaller functions. Too many parameters could be an indicator that your function is doing too much.\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Use an options object. If you can pass the parameters in an object (called a hash or a dictionary in some languages), you don’t have to worry about property order. This object is often called \u003Ccode>options\u003C\u002Fcode> and referred to an “options object.” The downside to this approach is that it’s less explicit about the expected parameters. Here’s how this looks in practice:\u003C\u002Fli>\n\u003C!-- \u002Fwp:list-item -->\u003C\u002Fol>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>function get_average_fruit_price(options) {\n    \u002F\u002F use options.fruit, options.country, options.year, options.sold_to_industry\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-6-write-good-comments\">6. Write good comments\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There are a lot of \u003Ca href=\"https:\u002F\u002Fstackoverflow.blog\u002F2021\u002F12\u002F23\u002Fbest-practices-for-writing-code-comments\u002F\">great, thorough rules\u003C\u002Fa> around code comments, but we’ll focus on the low-hanging fruit…\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Use comments sparingly to explain code that’s not otherwise clear. If you can improve the code instead, do that! Here’s an example of a bad comment covering up for unclear code:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode> int f = 75; \u002F\u002F f is the temperature in Fahrenheit\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Let the code speak for itself by renaming \u003Ccode>f\u003C\u002Fcode> to \u003Ccode>temp_in_farenheit\u003C\u002Fcode>!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>You won’t always have time to improve the hard-to-comprehend code you see. You might also write code you’re not thrilled with due to time constraints. Consider whether the code will need to be “touched” (read or modified) by someone else. Be honest — you don’t want to pass on code that’s hard to maintain!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>If the code isn’t likely to be modified by anyone else, you can leave a comment explaining what a particularly challenging bit of code does. Ideally, your function and variable names should already do this. But when the functions contain logic that’s hard to comprehend and the function name doesn’t help, leave a comment!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-7-don-t-repeat-yourself\">7. Don’t repeat yourself\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The DRY principle stands for “don’t repeat yourself.” If you find yourself using the same code in multiple places, see if you can pull it out into a variable or a function.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>string company_description = “Fruit Trucking & Shipping International ships fruit on our modern fleet of trucks and ships, anywhere in the world!”\u003Cbr>string company_slogan = “Fruit Trucking & Shipping International: where the best fruits get on the best ships”\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>string company_name = “Fruit Trucking & Shipping International”\u003Cbr>string company_description = company_name + “ ships fruit on our modern fleet of trucks and ships, anywhere in the world!”\u003Cbr>string company_slogan = company_name + “: where the best fruit gets on the best ships”\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>If the company ever changes its name (for example, if it decides to only ship apples…) we can now do this in one place. Conversely, if you don’t follow DRY, you’ll need to find all the places you have duplicated code and remember to make changes in each of them.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Here’s another example: let’s say all your input temperatures are in Farenheit, but you need your output values to be in Celsius. Everytime you work with a temperature, you’ll need to \u003Ccode>F - 32 * 5\u002F9\u003C\u002Fcode>. If you find out your organization now uses Kelvin , you’ll have to update this to \u003Ccode>F - 32 * 5\u002F9 + 273.15\u003C\u002Fcode> every place you reference a temperature.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A better solution is to pull this conversion into a function:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:code -->\n\u003Cpre class=\"wp-block-code\">\u003Ccode>function fahrenheit_to_celsius(temp_in_farenheit) {\n   return temp_in_farenheit - 32 * 5\u002F9;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C!-- \u002Fwp:code -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Now to switch to Kelvin, you can update the calculation in one place. In this particular example, you could probably just create a new (small, single-purpose) function called \u003Ccode>fahrenheit_to_kelvin()\u003C\u002Fcode>, and all the calls to \u003Ccode>fahrenheit_to_celsius()\u003C\u002Fcode> to \u003Ccode>fahrenheit_to_kelvin()\u003C\u002Fcode>. Now it’s very clear where you’re updating (you don’t have to look for mentions of “temperature” all throughout your code.)\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>It’s possible to overdo DRY. You don’t want to over-optimize too early, so a good alternative to DRY is WET, or “write everything twice”. If you need to write some code a third time, it’s probably a good idea to try and pull this out into its own function or variable. Over time, you’ll develop judgment for when to reuse the same piece of code over and over (like the example above) and when a few repeated lines are a part of separate processes.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-next-steps\">Next steps\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Reading about good coding practices is like reading about working out. You have to follow the practices to reap the benefits!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Just because you learned about all the muscles doesn’t mean you need to exercise them all right away. Start small: the next time you code, try to be precise with your names. Then, try to write smaller functions. Then, reference this article to see what else you might have missed!  Think of it like starting your fitness regimen with a few exercises a week.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Remember, we’re writing code for our future colleagues, and, importantly, our future selves. We don’t need to be dogmatic about the rules; we just need to focus on being as clear as we can.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>You’ll quickly find that writing clean code involves making tradeoffs. For example, if you’re under time pressure writing a one-off script to parse some data and are confident nobody will see the script again, you can invest less time into writing clear code. But over time, thinking about code maintainability and readability will empower you to solve problems more effectively and will set you apart from many beginner developers..\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>By implementing some basic software dev principles, you’re leveling up from someone hacking through code to someone maintaining and building software. And that’s something to be proud of!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->","html","2023-02-13T15:06:13.000Z",{"current":1593},"coding-102-writing-code-other-people-can-read",[1595,1603,1608,1612,1616],{"_createdAt":1596,"_id":1597,"_rev":1598,"_type":1599,"_updatedAt":1596,"slug":1600,"title":1602},"2023-05-23T16:43:21Z","wp-tagcat-career-development","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":1601},"career-development","career development",{"_createdAt":1596,"_id":1604,"_rev":1598,"_type":1599,"_updatedAt":1596,"slug":1605,"title":1607},"wp-tagcat-code-for-a-living",{"current":1606},"code-for-a-living","Code for a Living",{"_createdAt":1596,"_id":1609,"_rev":1598,"_type":1599,"_updatedAt":1596,"slug":1610,"title":1611},"wp-tagcat-coding",{"current":1611},"coding",{"_createdAt":1596,"_id":1613,"_rev":1598,"_type":1599,"_updatedAt":1596,"slug":1614,"title":1615},"wp-tagcat-comments",{"current":1615},"comments",{"_createdAt":1596,"_id":1617,"_rev":1598,"_type":1599,"_updatedAt":1596,"slug":1618,"title":1620},"wp-tagcat-dry",{"current":1619},"dry","DRY","Coding 102: Writing code other people can read",[1623,1629,1635,1641],{"_id":1624,"publishedAt":1625,"slug":1626,"sponsored":96,"title":1628},"76c9771b-34e6-4d98-8641-ecefc711f0ef","2026-07-06T15:23:34.559Z",{"_type":10,"current":1627},"when-the-sensor-starts-thinking-snortml-agentic-ai-and-the-evolving-architecture-of-intrusion-detection","When the sensor starts thinking: SnortML, agentic AI, and the evolving architecture of intrusion detection",{"_id":1630,"publishedAt":1631,"slug":1632,"sponsored":96,"title":1634},"28e560af-f0aa-4d46-bd90-f435ad604aa7","2026-06-26T14:00:27.102Z",{"_type":10,"current":1633},"paging-charity-how-can-engineering-leaders-avoid-becoming-bond-villains","Paging Charity! How can engineering leaders avoid becoming Bond villains?",{"_id":1636,"publishedAt":1637,"slug":1638,"sponsored":96,"title":1640},"4b22c2a3-3779-4966-93eb-5230391dbdce","2026-06-23T14:08:58.595Z",{"_type":10,"current":1639},"your-ai-shipped-a-backend-that-boots-that-is-the-whole-problem","Your AI shipped a backend that boots. That is the whole problem.",{"_id":1642,"publishedAt":1643,"slug":1644,"sponsored":96,"title":1646},"5cf362e1-fe7b-45af-b69c-914731c6a052","2026-06-23T14:00:00.000Z",{"_type":10,"current":1645},"the-2026-developer-survey-is-now-open-for-human-developers-only","The 2026 Developer Survey is now open (for human developers only)!",{"data":1648,"sourceMap":-1},{"count":1649,"lastTimestamp":1650},21,"2023-05-25T09:48:04Z"]