On Wed, 28 Jul 2021 16:12:53 -0400
Steve Litt <slitt@???> 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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng