On Tuesday, July 27th, 2021 at 7:26 AM, tito via Dng <dng@???> wrote:
> On Mon, 26 Jul 2021 22:53:02 -0400
> Steve Litt slitt@??? wrote:
> > Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
> > > On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> > > > Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> > > >

> > > > > My feeling is, that you can not simply teach someone how to write safe software.
> > > >

> > > > Why not? You can teach a person to do anything else. But maybe not in
> > > > college, because college is built to make money, not to teach.
> > > > Consider the average textbook and compare to the average "For
> > > > Dummies" book. The former makes the subject matter look incredibly
> > > > complex, justifying the professor. The latter makes it easy to learn.
> > > > What is needed is a curated document explaining the five or ten or
> > > > twenty things you need to do to be secure, and then how to achieve
> > > > them in a practical world. Let's start with input field cleansing and
> > > > protection from errant pointers and buffer overflow. There are many
> > > > more:
> > >

> > > Knowing you, you probably already have a draft of such a document lying around.
> >

> > Not that I know of. That's why I'm starting at the level of a simple list.
> >

> > SteveT
>

> Hi,
>

> 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)
>

>     these are the few rules I used when I did a little programming in the past
>     So tell me yours...

>

>     Ciao,     

>     Tito

Applying all those rules to all programming languages for all situations will not be a guarantee of a quality software product.
Also as Tito would probably admit that list is far from complete.
The issue is determining what rules to apply and when.


If anyone here is interested in learning programming and does not know where to start...my suggestion would be as follows

Look up the definition of each word of the Software Developer's Mantra below in relation to software development
(they are in alphabetical order purely for the mnemonic effect and are all of equal importance).

Consider and apply that definition to the use of the *programming language* and the *specific application being developed*.
This should be done iteratively during authoring, line by line, first to the expression, the whole function, then the module, throughout the whole program.

Software Developer's Mantra
~~~~~~~~~~~~~~~~~~~~~~~~~~~
completeness conciseness
high-cohesion low-coupling
resilience robustness
validation verification

This will still work with whatever design methodology you have been forced to work under, be it Agile, Scrum, Waterfall, Bohemes Spiral, etc. etc.

For example .. look up high-cohesion
https://en.wikipedia.org/wiki/Cohesion_(computer_science)
Apply the concept to every line as you write it.

NB. There is a lot more to software development than this, but following the mantra can help you produce significantly better code.