For my blog post, I chose to use examples from Chapter 1 of Robert Martin’s book called Clean Code: A Handbook of Agile Software Craftsmanship 1st Edition. While the book is from 2008, It has applicable concepts and tips for the modern software developer.
One of the key aspects of the chapter lies in creating tests for your own code to test its functionality. The chapter describes how it is necessary for clean code, and this is noted on page 9 from Dave Thomas. This is due to having a standard to work along with, known by the team. I want to be able to create such tests for my development team as so far, other team members have been assisting in that area. While I am not as knowledgeable when it comes to unit testing, I think it plays an important role in maintaining standard, functional code. This idea is applicable to the NES emulator that my team is working on. Here is a possible example that could be implemented to test an opcode:
def test_example_opcode():
cpu = CPU()
cpu.Accumulator = 0x10
cpu.memory.write(0x200, 0x69) #Adc opcode
cpu.memory.write(0x201, 0x05) #operand
cpu.execute_instruction()
assert cpu.A == 0x15, “Expected 0x15”
assert not cpu.C, “Carry flag should not be set”#otherwise
If unit testing is already complete, there is also the possibility of testing using test ROM files to accurately measure the performance of the NES emulator.
What I do want to avoid doing is ignoring problems in the Codebase, such as code duplication. According to Chapter 1. of Robert Martin’s Clean Code: A Handbook of Agile Software Craftsmanship, ignoring a small issue such as code duplication seems fine but it could signal something is not being efficient in the way the system may have been designed. This is especially true for duplicate opcode implementation or even address handling for memory in the emulator. Avoiding duplication helps reduce complexity and improve readability as well.