:: [DNG] Starting outline for the DNG …
Página Principal
Delete this message
Reply to this message
Autor: Steve Litt
Data:  
Para: dng
Assunto: [DNG] Starting outline for the DNG Safe Programmer Certificate
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
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").

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