Good code
- 2. Outlines ● Principles ● Readability ● DRY ● Naming ● Function ● Comments ● Keep Good Quality ● Demo ● Take Out
- 3. Principles ● What is good code? ○ Easy to read (and understand) ○ Easy to modify ○ Easy to extend ○ (If easy to ready, then) Easy to debug ○ Proven accuracy
- 4. Readability “Indeed, the ratio of time spent reading vs. writing is well over 10:1. ….. so making it easy to read actually makes it easier to write.” - Clean Code
- 5. Readability ● Abstraction can enhance readability ● Abstraction = Get big picture and hide details if (u32Year == 2016 && u8Month == 4 && u8Day == 11) { goodCode(); } if (dateIs(2016, 4, 11)) { goodCode(); }
- 6. Readability
- 7. ● Don’t Make Me Think: Avoid nested decision statement Readability if (A == u8Val) { if (B == u16Val) { if (C == u32Val) { if (D == iVal) { helloWorld(); } } } } if (checkABCD(A, B, C, D)) { helloWorld(); }
- 8. ● Don’t Make Me Think: Use straight-forward decision statement Readability if ( sheSayYes() != NO ) { soWhatDoYouMean(); } if ( sheSayYes() == YES } { bingo(); }
- 9. ● Don’t Make Me Think: Meaningful #define instead of numeric value Readability switch (u8Temperature) { case 1: fanSpeed(Low); break; case 2: fanSpeed(Mid); break; case 3: fanSpeed(High); break; case 4: fanSpeed(SuperHigh); break; default: fanSpeed(Low); break; } switch (u8Temperature) { case TEMP_LOW: fanSpeed(Low); break; case TEMP_MID: fanSpeed(Mid); break; case TEMP_HIGH: fanSpeed(High); break; case TEMP_OVERHEAT: fanSpeed(SuperHigh); break; default: fanSpeed(Low); break; }
- 10. DRY (Dont Repeat Yourself) ● Repeating in code is VERY VERY VERY EVIL! ○ Hard to debug ○ Hard to extend ○ Hard to maintain ○ Larger code size ○ Not well structured ● When feeling you are repeating something, be VERY AWARE! This is the right moment to refactor.
- 11. DRY (Dont Repeat Yourself) ● Avoid double-confirm comment ● Avoid same code pattern (by using function) // sdk init sdkInit(); // sdk init sdkInit(); if (u32Year == 2016 && u8Month == 4 && u8Day == 11) { goodCode(); } if (u32Year == 2016 && u8Month == 4 && u8Day == 32) { areYouOK(); } if (dateIs(2016, 4, 11)) { goodCode(); } if (dateIs(2016, 4, 32)) { areYouOK(); }
- 12. DRY (Dont Repeat Yourself) ● Create common utility ● Something else? linux # ./addImgaeHeader_ET6848 rtimg linux # ./addImgaeHeader_FJSRS rtimg linux # ./addImgaeHeader rtimg ET6848 linux # ./addImgaeHeader rtimg FJSRS linux # ./addImgaeHeader uboot FJSRS
- 13. Naming ● Naming is everything ○ variable ○ function ○ file ○ utility ○ directory ● Naming in consistent way, precisely! ○ easy to understand (ex: u8Val, u16Val, …) ○ easy to group (ex: bspCpuInit(), bspCpuI2cInit(), …) ○ easy to refactor ● Good naming implies logic correct code
- 14. Naming ● Good naming can help logic debug if ( u8Animal == ANIMAL_DOG } { bark(); } ICOS/bsp/cpu/webserver.c ICOS/bsp/cpu/i2c.c if ( u8Mode == VLAN_ENABLE ) { disableVlan(); } if ( u8Mode == VLAN_ENABLE } { enableVlan(); } if ( u8Animal == FRUIT_APPLE ) { areYouOK(); }
- 15. Function ● Function is a power tool for abstraction ● Function should do one thing at a time ● Function should have no side effect ● Function should be as small as possible int portDisableAll() { int port = 1; do { portDisableByPort(port); port++; } while (port <= PORT_COUNTS); vlanDisableAll(); } int portDisableAll() { int port = 1; do { portDisableByPort(port); port++; } while (port <= PORT_COUNTS); vlanDisableAll(); }
- 16. Comments ● Comment can be out-dated ● Documentation in code, not in comment ● Less comment is better!
- 17. Keep Good Quality ● Fix “Broken Window” ○ Broken window theory ● Prove your code by testing ○ “All code is guilty until proven innocent”
- 18. Demo ● Too many nested statement: tskpsaving.c, poeschedule.js ● Repeated code block: poeschedule.js ● Use #define instead of numeric value: poeplus.c ● Funtion power: firstbuild_ag7448.sh vs firstbuild_fjsrs.sh
- 19. Take Out ● Abstraction ● Don’t Make Me Think ● DRY ● Naming precisely, consistently ● Less comment is better ● Fix “Broken Window” ● Prove your code by testing
- 20. Reference 1. Clean Code: A Handbook of Agile Software Craftsmanship, 1st Edition, Robert C. Martin 2. The Pragmatic Programmer: From Journeyman to Master, 1st Edition, Dave Thomas, Andy Hunt 3. Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition, Steve Krug
- 21. Q&A || Share
- 22. Appendix
- 23. ● Applying the Linus Torvalds “Good Taste” Coding Requirement soso better