4 ms·

Hi, OP here. Interesting list. I think I would approve most of your points, but never worked (or created) such a "proper" environments in my various teams. Coul

Hi, OP here. Interesting list. I think I would approve most of your points, but never worked (or created) such a "proper" environments in my various teams. Could you share the kind of checklist you use? Or give an idea of the kind of "checks" you have there? Thanks!

atsaloli 13y ago
See six steps to success section of my write-up of Dr. Holzmann's talk on how JPL builds reliable software. http://www.verticalsysadmin.com/making_robust_software/ http://www.verticalsysadmin.com/making_robust_software/ The clever idea is to make your coding standard mechanically verifiable.
- martinvanaken 13y ago
  Thanks, nice list, summarize a good part of the best practices in a short form. Will quote.
  - atsaloli 13y ago
    Excellent, you are most welcome. I need to write a shorter version, to make the data more broadly accessible.
edw519 13y ago
Hi, OP. Thanks for the interesting post. Off the top of my head: 1. Variables declared or assigned, but never referenced again 2. Improper variable scope (local/global) 3. Reserved words (by language, framework, industry, app) used as variables 4. Improperly reused variable names 5. Improperly named variables (1 or 2 characters, contained in another variable name) 6. Too difficult to understand variable or function names 7. Function names must be Verb-Adjective-Noun 8. Variable names must be Adjective-Noun 9. Improper data type 10. Repeated (in one or more programs) code for which reusable code should be written. (Any future maintenance must only be done in one place.) 11. Fresh code rolled instead of using existing reusable code meant for that purpose. 12. Partially complete data base updates 13. Improper data base locking 14. Non-standard UI widgets 15. Version control problems (didn't start with current production version) 16. Not all changes documented with ticket# 17. Case/switch statements without fall-through clause (case 1) 18. Improperly structured if...then statements 19. if...then statements too long (according to published standard) 20. Improper indenting/spacing (according to published standard) 21. Comments don't match code 22. Comments inaccurate 23. Calling/using obsolete/deprecated code 24. Not backward compatible 25. Obviously works under only certain conditions (which will be caught in testing) 26. New code inserted in wrong place (if...then, case, function, etc.) 27. Obviously missing data base updates 28. Obviously missing API calls 29. What else?
- martinvanaken 13y ago
  Great list (especially "off the top of your head"). Thanks a lot for sharing. Several of those can actually be implemented in an automated tool (styles, short variables, spacing, unused variables even). What's your take on automated tools? (Disclaimer: my company built one - pulreview.com).

atsaloli 13y ago

See six steps to success section of my write-up of Dr. Holzmann's talk on how JPL builds reliable software. http://www.verticalsysadmin.com/making_robust_software/ http://www.verticalsysadmin.com/making_robust_software/ The clever idea is to make your coding standard mechanically verifiable.

martinvanaken 13y ago
Thanks, nice list, summarize a good part of the best practices in a short form. Will quote.
- atsaloli 13y ago
  Excellent, you are most welcome. I need to write a shorter version, to make the data more broadly accessible.

edw519 13y ago

Hi, OP. Thanks for the interesting post. Off the top of my head: 1. Variables declared or assigned, but never referenced again 2. Improper variable scope (local/global) 3. Reserved words (by language, framework, industry, app) used as variables 4. Improperly reused variable names 5. Improperly named variables (1 or 2 characters, contained in another variable name) 6. Too difficult to understand variable or function names 7. Function names must be Verb-Adjective-Noun 8. Variable names must be Adjective-Noun 9. Improper data type 10. Repeated (in one or more programs) code for which reusable code should be written. (Any future maintenance must only be done in one place.) 11. Fresh code rolled instead of using existing reusable code meant for that purpose. 12. Partially complete data base updates 13. Improper data base locking 14. Non-standard UI widgets 15. Version control problems (didn't start with current production version) 16. Not all changes documented with ticket# 17. Case/switch statements without fall-through clause (case 1) 18. Improperly structured if...then statements 19. if...then statements too long (according to published standard) 20. Improper indenting/spacing (according to published standard) 21. Comments don't match code 22. Comments inaccurate 23. Calling/using obsolete/deprecated code 24. Not backward compatible 25. Obviously works under only certain conditions (which will be caught in testing) 26. New code inserted in wrong place (if...then, case, function, etc.) 27. Obviously missing data base updates 28. Obviously missing API calls 29. What else?

martinvanaken 13y ago
Great list (especially "off the top of your head"). Thanks a lot for sharing. Several of those can actually be implemented in an automated tool (styles, short variables, spacing, unused variables even). What's your take on automated tools? (Disclaimer: my company built one - pulreview.com).