- DO fix simple bugs
- DO NOT fix bugs that require extensive modification
- DO NOT fix exotic bugs that haven't bugged anyone
- DO make small enhancements if they are badly needed
- DO NOT let one user decide what is badly needed
- DO fix configuration for broken platforms
- DO NOT break functioning platforms in the process
- DO NOT fix things that are not broken
- DO NOT restructure code
- DO NOT add experimental code
- DO NOT modify the API (unless absolutely sure it is buggy)
- DO NOT change defaults without a *very* good reason
- DO clarify documentation
- ONLY add or modify examples if needed for clarification
- DO NOT reword messages
- DO NOT modify regression tests (except if they were buggy)
- DO NOT add code that cannot become reasonably complete by the next release.
Manager asks “but what if we only have crap developers”, default response is “well, in that situation, standard best practice is to fail”
November 13, 2008
Developer Guidelines
I found this in "Developer Guidelines" on R-Project developer page. This is something I was always followed during my work but never had it written and digested. So, thank you r-project people for this :) Here it goes:
Labels:
Software development
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment