Week 15: CST 205

This week, we learned about lists. Lists are a sequence of values with elements or items. Lists can be changed so if there are unwanted values, they can be changed. Lists can be added together or concatenated with the '+' operator. Slice can be used on lists to remove values from the first to the last number. Append can be used to add a new element to the end of a list and extend is used to append more than one element. Pop can be used to delete an element if you know the index, and del can be used if you know the element but not the index. Split is used to break a string into words. A delimiter can be used to help split strings. 

A dictionary is like a list, it has keys and values associated with those keys. Its key-value pairs are called items. You can make an empty dictionary and add items to it. 

In the guide to identifying complexity, a few things were mentioned to do in order to increase understanding. Complex problems with sequential execution are probably not solving complex problems. Complex problems require a few self-created functions to be made and require more data variables to be tracked with test cases. They need to be broken down to be understood, then recombined and will take a long time to be completed. 

Code review is a systematic examination of computer code in order to find mistakes and improve the developer's skills. Code review ensures that the final project is good, allows practice in code review as a soft skill, allows team members to learn from each other, learning to read different styles of code, and learning to focus on details. A few tools to check out are Gerrit, Review Board, Rietveld, Codifferous. The best practices: reviewing 200-400 lines at a time at allowing yourself about an hour to do so but not more than 90 minutes. The author should annotate the source code establishing quantifiable goals and metrics to improve the process with a checklist for both parties. Then the reviewer verifies that the defects are fixed. 

Good programming practice is a good skill to learn. Start your journey with a plan which includes the data, functionalities described with pseudocode, communication between functions, and a diagram of the design of the program with the modules and how they connect. The program should be done and tested in small chunks or by lines. Programs should be indented correctly. The variable names should be clear and self-documenting in mixed case. For booleans, the word 'is' should be used to indicate boolean variables and methods. The functions should have a description of the preconditions and postcondition including the acceptable conditions where they will run. The comments should be a complete sentence with a capitalized letter on the first word unless it is the name of a variable. The header comment should be at the top of the file with the filename, author, date, version number and a description of what the file is for and what it contains as well as the course name, number, section, instructor, and assignment number. Testing data and plans should be done in the program and when testing, the boundary values should be indicated.