On Wed, 28 Jul 2021 16:12:53 -0400 Steve Litt <sl...@troubleshooters.com> wrote:
> Hi all, > > Here's the info we've collected so far on safe programming: > > ====================================================== > From Tito: > > Ten Commandments > > 1) use the least amount of code possible > 2) try harder and go to point 1 > 3) if the code doesn't fit into one screen go to point 2 > 4) always initialize your vars at declaration time > 5) always set your vars to NULL after freeing them Hi, Should be: 6) always check error codes of the functions you call and _do_ something appropriate > 6) always check error codes of the functions you call and something > appropriate > 7) add comments about what and why you did (that ugly > hack) > 8) use meaningful (to others) names for your functions and vars > 9) your code must be readable to others like a children's book > 10) if you don't know how to solve it, look what others did, then do > it your way (or forget Ctrl-C) > > EDITOR'S NOTE: #3 means all code *from one subroutine* fits on one > screen. > ====================================================== > > ====================================================== > From g4sra: > > Software Developer's Mantra > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > completeness conciseness > high-cohesion low-coupling > resilience robustness > validation verification > ====================================================== > > > ====================================================== > From Josef Grosch: > > 1) KISS (Keep It Simple Stupid) Clever code always comes back to bite > you in the ass. Simplicity is a beautiful thing. > > 2) White space is free, use it to make the code readable. > > 3) Pick a coding style and stick to it, I personally prefer the One > True coding style. Most languages have a tool like Beautify that can be > configured to format your code to your coding style. > > 4) If a block of code gets repeated 2 or more time break it out as a > function or a method. > > 5) Most languages have a Lint type tool, use it often. > > 6) Use the system and languages libraries. Never try to re-write them, > it will only lead to more bugs and rabbit holes. Same goes for > libraries from other projects, they have had the benefit of many eyes > looking at > their code. > > 7) Pay attention to the scope of variables and functions. > > 8) Use a revision control system like Git to check code in on a regular > basis into a branch for a coding session, not into the main branch. > Working in a branch lets you figure out what really works and only when > everything is correct then merge into the main branch. I usually do a > pull at the beginning of a coding session and a push at the end. > ====================================================== > > > ====================================================== > From Steve Litt: > > Cleanse and length-check any user input, or any data that comes in > externally. > > Avoid volleyball code. Use yo-yo code instead. > > Avoid global variables if at all possible. (See g4sra's "low coupling"). That's bad... I love global variables ;-( as they avoid shuffling around parameters in functions (KISS?) Ciao, Tito > Avoid software switchtracks (e.g. dbus) (See g4sra's "low coupling"). > > Use names instead of magic numbers. > > Name variables, functions and methods descriptively. > > Avoid parallel variables. > ====================================================== > > I wish I had had this list when I started programming professionally in > 1984. I'm sure glad to have it now. > > Does anyone have other list items to add? > > Thanks, > > SteveT > > Steve Litt > Spring 2021 featured book: Troubleshooting Techniques of the Successful > Technologist http://www.troubleshooters.com/techniques > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
