{"id":58,"date":"2024-01-31T21:23:29","date_gmt":"2024-01-31T21:23:29","guid":{"rendered":"https:\/\/permutationcity.co.uk\/bp\/?p=58"},"modified":"2024-04-28T09:13:36","modified_gmt":"2024-04-28T09:13:36","slug":"we-all-make-mistakes","status":"publish","type":"post","link":"https:\/\/permutationcity.co.uk\/bp\/2024\/01\/31\/we-all-make-mistakes\/","title":{"rendered":"We all make mistakes"},"content":{"rendered":"\n

In some ways I don’t trust other coders but, to be fair, I don’t trust myself either. What I mean is, everyone makes mistakes, we should be tolerant of this and plan for it. It’s important to have steps in place to catch mistakes before they become problems. If someone makes a mistake I understand. If someone keeps making the same mistake I worry. That could be a problem with learning from mistakes or it could be the systems being used makes mistakes easier. If it’s my<\/strong> mistake I own up and try to learn a lesson.<\/p>\n\n\n\n

Error tolerance and detection<\/h2>\n\n\n\n

Catching mistakes early is better than catching them late. Debugging tasks can take a long time even\nif the fix is just a single code change. assert<\/code> functions can be used to detect unexpected situations\nduring testing. While it’s annoying to have code fail at an assert<\/code> and it’s usually much faster\nto fix than if the program crashes at some random time afterwards. You might also be able to use\nstatic_assert<\/code> to check a condition during the build process before even getting to testing.<\/p>\n\n\n\n

An assert<\/code> doesn’t typically make it’s way into the final executable. However there can still be lots\nof circumstances when you want to check expectations. This is at it’s most obvious when dealing\nwith user input, files and network traffic. Each of these should<\/em> be read in expected formats.\nHowever they may not due to error, corruption or malicious intent. It can be useful to treat other parts\nof a codebase with some distrust as well. Your code may expect to receive a properly formatted record,\nwould it be that costly to check? I’ve created my own runtime_assert<\/code> in a similar situation and\nfound an out of bounds error as a result.<\/p>\n\n\n\n

If possible write code such that can’t be used incorrectly. If you have an object that needs to be\ncreated and separately initialised then someone in the future can forget to initialise the object.\nIf you have an object that is created and initialised in one step or is initialised automatically\nwhen it is first used then there is nothing that has to be remembered. If you make an API that is\nhard to use then it is likely to be used wrongly. Documenting the correct usage is great but may\nnot get read until a bug is found.<\/p>\n\n\n\n

Testing code<\/h2>\n\n\n\n

How many people out there expect their code to work first time? If I write a few hundred lines of code\nthen normally expect to find some sort of mistake before it gets checked in to mainline. That might\nbe a off-by-one error or it might be an aspect of the task that hadn’t fully been considered. I want to\nexercise all my code to see if it works rather than just assuming that it does. If something isn’t wrong\nthen it can feel suspicious.<\/p>\n\n\n\n

Recently I’ve been working with batch processing and rough testing involved running a script to test a typical\nexample. A lot was going on in each batch so it would exercise most of the code. I tended to categorise\ntests into two types:<\/p>\n\n\n\n

    \n
  1. My updated code should produce the same output as before. This is true for optimisation and refactoring\ntasks. If so I use an automatic check to see if the new output matches the old output.<\/li>\n\n\n\n
  2. My updated code can produce a different output from before. This is true for bug fixing and new features.\nIf so I have to check if the new output makes sense.<\/li>\n<\/ol>\n\n\n\n

    If you can make use of the first type of test it tends to be much faster. That means I can test more often\nand there is less code to search through to find the mistake. Even bug fixing and new features can take advantage\nof this. First use the simplest, slow, or certain solution. Once I’ve recorded that output it can be used\nfor comparison purposes for a better, faster, or less certain solution.<\/p>\n\n\n\n

    Exercising most of the code with a single typical example was useful but there were edge cases. I could also\nuse the same script to test multiple examples, even “the full set”. While small examples would take 30 seconds\nto run, large examples would take 5 minutes and the full set several hours. It was very useful to change\nbetween examples and to choose how many examples to run. I was able to run smaller tests when I thought my\nchanges were safer and larger tests when I thought they were more likely to cause problems. Running\na full set of tests could normally be left until I thought the task was finished, only running the test would\nshow if the task was actually finished.<\/p>\n\n\n\n

    Most of the projects I’ve worked out haven’t started out with significant unit testing. However whenever\nunit testing has been used it has helped me catch mistakes and often gives code a better structure as well.\nIn order to write unit tests it’s often necessary to break code up to separate functionality which tends\nto be better structurally as well. Ideally a single unit test should test a single aspects of the code.\nWhile this is a good goal I don’t worry to about it too much. It’s certainly easier to diagnose problems\nif you can write the tests that way. If you can’t write your tests that way then it’s still better to\nhave the test rather than not have it. A good set of tests can give you the confidence to make changes.\nThat means you can make you code faster, cleaner, more featured or all of them.<\/p>\n\n\n\n

    The developer should remember to run testing but, if at all possible, tests should run automatically.\nThis could be every day or every night or whenever something is checked in. The important thing is that\nit’s regular does and doesn’t require the developer to remember. Forgetting to run the tests is another\nmistake that anyone can make.<\/p>\n\n\n\n

    Code reviews<\/h2>\n\n\n\n

    I’ve had mostly positive experiences with code reviews but I don’t think this is universal.\nIdeally these happen promptly, help find mistakes in the code and spread knowledge in the team.\nIt doesn’t help if they take ages, devolve into arguments or are just box ticking exercises.<\/p>\n\n\n\n

    To get the best out of code reviews I’d recommend:<\/p>\n\n\n\n

      \n
    • Have them promptly – For pull requests on GitHub I tried to respond within 24 hours. If you’re in the middle\nof something you may not need to respond immediately but plan breaks where you can respond. I found\nfirst thing in the morning or after lunch a good excuse to switch tasks and look at a PR.<\/li>\n\n\n\n
    • Try to understand the code – While this seems obvious, you should ideally be able to understand all the\nchanges that are being made so you can give a real opinion on them. This can be made easier if code\nis written to be easily reviewed<\/em> but that’s a non-trivial task and a topic for another post.<\/li>\n\n\n\n
    • Ask questions and make suggestions rather than demands – You might think you see a bug or know a better\nway of doing things but maybe there is a good reason for it.<\/li>\n\n\n\n
    • If it’s coded differently from how you would do it, that doesn’t mean it’s wrong – I think it’s good to\nto have consistent techniques used in a project but variation is still possible. Again, suggestions\nrather than demands.<\/li>\n\n\n\n
    • If you don’t have time to do a review them let the developer know – Better to let someone know that\nyou’re busy and hopefully someone else has time.<\/li>\n<\/ul>\n\n\n\n

      On balance<\/h2>\n\n\n\n

      Remember, mistakes will happen but they don’t have to make it in to your release.<\/p>\n","protected":false},"excerpt":{"rendered":"

      In some ways I don’t trust other coders but, to be fair, I don’t trust myself either. What I mean is, everyone makes mistakes, we should be tolerant of this and plan for it. It’s important to have steps in place to catch mistakes before they become problems. If someone makes a mistake I understand. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[1],"tags":[12,13],"class_list":["post-58","post","type-post","status-publish","format-standard","hentry","category-general","tag-debugging","tag-testing"],"_links":{"self":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/58","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/comments?post=58"}],"version-history":[{"count":2,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/58\/revisions"}],"predecessor-version":[{"id":202,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/58\/revisions\/202"}],"wp:attachment":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/media?parent=58"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/categories?post=58"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/tags?post=58"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}