Crafting high quality code
0 likes753 views
The document provides guidance on writing high-quality code and functions. It recommends that functions should have a single well-described purpose, use meaningful naming conventions, limit their size and number of parameters, and handle errors. It also emphasizes the importance of testing code through test cases to ensure it works as intended.
Crafting high quality code
- 1. Writing High Quality Code Allan Spartacus Mangune PSIA Enablement Workshop Makati City August 29, 2019
- 4. 80 vCore CPU 256 GB RAM 56 Active Users
- 5. ONE FUNCTION CALL Get something from the database Call that cool function I need to assemble some data from that function Get something again from the database Verify correctness from another function When errors happen, can’t rollback
- 8. Fragmented SQL queries Database queries are doing table scan No database transactions Database calls are not explicitly closed Fragmented behaviors Function names are misleading
- 9. MEETING
- 10. Variablenames One character Abbreviated Inconsistent casing int i = 0; for(int x=0; x < y; x++){} String cust = “”; String Name_of_file; String waitOnDemandName;
- 11. Functionnames Does not begin with a verb Inconsistent casing Abbreviated void nextInQT(); int wtTillDn(); void TRY_LOADING(); int find_next; void STOP_find(); void parallel(); string name();
- 12. Hard to read code confuses us what exactly the code is doing
- 13. In the beginning, we design software
- 14. Software design is a wicked problem
- 16. Pseudo coding How algorithm is executed Interpreted by programmers Understood by layman
- 17. Advantages of Pseudo coding • One of the best ways to start implementing algorithm • Explain how lines of code are to be written
- 18. How do we write pseudo code?
- 19. • Arrange the tasks sequentially • Write the pseudo code for each task • Example: This code will allow the customer to checkout the product
- 20. • To increase the readability, indent your statements • Example: If a customer is new Create an new account Else Login with credentials
- 21. • Use appropriate naming convention • Naming must be simple
- 22. Sketch your code on paper Reference: https://www.thatsoftwaredude.com/content/ 6421/sketching-your-code-on-paper
- 23. Sketching with a tool
- 24. Reference: https://www.thatsoftwaredude.com/content/ 6421/sketching-your-code-on-paper Sketching is quick and easy
- 25. Pseudo coding helps visualize the algorithm
- 27. Initialize each variable as it is declared • Avoids initialization errors DON’T DO Reference: Code Complete 2 by Steve McConnell
- 28. Initialize variable close to where it is first used • Keep related actions together DON’T DO Reference: Code Complete 2 by Steve McConnell
- 29. Use final or const for variables that are intended not to be changed Reference: Code Complete 2 by Steve McConnell
- 30. Localize references to the variables • Keeping variable close together helps you read one section at a time Reference: Code Complete 2 by Steve McConnell
- 31. Keep variables Live for as Short as Time possible • Reduces the chance of initialization errors Short live Long live Reference: Code Complete 2 by Steve McConnell
- 32. Use each variable for one purpose only • Avoid using a variable in different places Reference: Code Complete 2 by Steve McConnell
- 33. Make sure all declared variables are used • Delete any unused variables Reference: Code Complete 2 by Steve McConnell
- 34. Make sure all declared variables are used • Delete any unused variables Reference: Code Complete 2 by Steve McConnell
- 35. Don’t name your variables as if you are naming your dogs DON’T DO Reference: Code Complete 2 by Steve McConnell
- 36. Use the appropriate casing and consistent • Use camel or Pascal casing or any appropriate casing and be consistent using that identifier casing Reference: Code Complete 2 by Steve McConnell
- 37. Optimum name length • theGoodOverdueAccount • overdueAccount • ovDuAcct
- 38. Naming Loops • Avoid single character of abbreviation DON’T DO
- 39. Status variables • Describe the state of program • Should not contain the word flag • Must be assigned with values • Must be tested with different conditions • Examples: • dataReady = true; • recalculationNeeded true; Reference: Code Complete 2 by Steve McConnell
- 40. Boolean names • Give names that imply true or false • Examples: • found • done • success • error Reference: Code Complete 2 by Steve McConnell
- 41. Use naming conventions • Allows you concentrate on writing code • Gives you a confidence to easily understand the code written by others • Learn code more quickly on a new projects • Reduce name proliferation (e.g. pointTotal and totalPoint) Reference: Code Complete 2 by Steve McConnell
- 42. Create short names that are readable • Using short names are remnants of Jurassic era of computing • Variable names like i, j, k are used in Mathematics that became favorites of some people in the past • Today programming languages allows you to write a variable of any length. JustDontMakeTheVariableNameVeryVeryLong
- 43. Avoid using keywords used by programming language • Examples: • this • type • void Reference: Code Complete 2 by Steve McConnell
- 44. Use thesaurus to resolve naming collisions Reference: Code Complete 2 by Steve McConnell
- 47. Avoid numerals in names
- 48. Avoid multiple natural languages • Use a single natural language for multinational projects Reference: Code Complete 2 by Steve McConnell
- 49. Don’t use names that are totally unrelated to what the variables represent Reference: Code Complete 2 by Steve McConnell
- 50. Avoid names that contains hard-to-read characters • hard2Read Reference: Code Complete 2 by Steve McConnell
- 51. Functions
- 52. Functions are software behaviors • Also known as methods, you can call them to do things • They respond to certain events
- 53. How to write high-quality functions?
- 54. A function must have a single purpose • Don’t make a function that does a lot of things
- 55. Functions reduce complexity in program • Hide the information about the behavior • Minimize code size • Avoid deep nested looping or conditions Reference: Code Complete 2 by Steve McConnell
- 56. Avoid duplicate code • Avoid copy and pasted code • This will greatly help but be careful when doing database operations • Too much reusing in database operations might result in a lot of nested loops and conditions
- 57. Improve performance • Troubleshooting for performance issues is easy when related codes are put in one place • Recode the routine to improve the performance
- 58. Design at routine level • Operations in a function are related to each other • A function must do only a single purpose Reference: Code Complete 2 by Steve McConnell
- 59. Naming Functions
- 60. Describe everything the function does • Describe the output and side effects • Examples: • CalculateTotals() • ProcessInput() • AddNumbers(int numberOne, int numberTwo)
- 61. Use a verb as the first word in a function name • Avoid starting the function name with a noun • Remember, a function is a behavior. It’s a verb. • Examples: • PrintDocuments() • CalculateMontlyRevenues()
- 62. Use a function name that describe the return value • When a function has a return value, use a name that describes the value it returns • Examples: • IsPrinterReady() • GetCustomerRecords(int customerId) Reference: Code Complete 2 by Steve McConnell
- 63. Establish conventions for common operations • For write operations, you can use Add, Edit, Delete plus the object name • For read operations, you can use Get, Find, Load plus the object name
- 64. How long can a function be • 50-100 lines of code
- 65. Use all function parameters • Remove any unused function parameters to avoid confusions and errors
- 66. Limit the number of function parameters • A maximum of 5-7 maybe acceptable
- 67. Handle all possible errors inside the function • Don’t just let the function throws an exception • Do a test for nulls and values and return the appropriate error description • Use try/catch statements
- 68. Test cases
- 70. Software engineers should test their program • Write a test case to test your own code
- 71. Write your test cases manually Reference: https://www.wikihow.com/Write-a-Test-Case
- 72. Write a code that tests your code • This will ensure that the expected output is correct
- 73. Q & A
- 74. Thank You
- 75. References • Code Complete by Steve MacConnell • Graphics lifted from www.freepik.com and Wikihow • Please always acknowledge the sources mentioned here when using these decks