Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Sat, 7 Aug 2021 17:02:17 -0400 Hendrik Boom wrote: > Wikis are often backed by revision management to make it asy for > administrators to bck out of spam. > To make sure they are backed up, use a distributed revivion management > system and make sure there are multiple repositories. The problem is that a huge amount of work ends up being foisted onto a sysadmin. Hosting aside, there are plugins for anti-spam, user management and all kinds of random things which shouldn't be left in the hands of random people. I still maintain that collaborative documentation is best done on a wiki maintained by a few dedicated people though. Also do note that it's possible to do wiki-like stuff using git wikis and flat files (likely markdown) at least on GitHub. I don't know if this sort of thing is reasonable with other systems. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Sat, Aug 07, 2021 at 04:36:31PM -0400, Steve Litt wrote: > spiralofhope said on Sat, 7 Aug 2021 10:37:58 -0700 > > >On Sat, 07 Aug 2021 16:21:47 +0930 > >dva...@internode.on.net wrote: > > > >> On 30.07.21 11:28, spiralofhope wrote:> > >> > I also mean that if there are any complex ideas or words, those can > >> > be explained in separate specific-documentation in the same way > >> > that code does it. > > > >> My preferred method for nesting descriptive prose, and presenting > >> the whole on one page, is to use folding in vim. > > > >I understand this method. > > > >However, I disagree with it because it introduces a software dependency > >and something like a new workflow. > > > >Breaking out specific blocks of documentation to a new file is similar > >to splitting out a chunk of code and putting it in a new file. It has > >side benefits like allowing a specialist to work on that chunk of text > >separately. > > > >All of this, including collaboration to improve it, reminds me of a > >wiki, but I'm biased because I was very heavily interested in wikis at > >(and well before) their rise. > > Wikis are much harder to back up than tab indented outlines. Tab > indented outlines can pull in external files when used with VimOutliner. Wikis are often backed by revision management to make it asy for administrators to bck out of spam. To make sure they are backed up, use a distributed revivion management system and make sure there are multiple repositories. > > The essentials of VimOutliner is almost instantly usable by a person > familiar with Vim, although researching ":help vo" is necessary for most > efficient use. > > Unfortunately, VimOutliner has been, in my opinion, been left in a sad > state by the maintainers who followed myself and Noel Henson. Within a > few days I'll put up a working and efficient, if a couple versions > behind, tgz for VimOutliner. > > WARNING: Don't use the Debian VimOutliner package. This package has > autocratically replaced the comma comma command prefix with something > much, much slower and more keyboard dependent. VimOutliner is simple > enough to install via tgz plus a few copy commands: Noel and I found > distro packages to be counter productive. > > Within a few days I'll post vimoutliner-0.3.5 or vimoutliner-0.3.4, > which are the final two TRUE VimOutliner versions, having all the most > used features intact. > > 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
spiralofhope said on Sat, 7 Aug 2021 10:37:58 -0700 >On Sat, 07 Aug 2021 16:21:47 +0930 >dva...@internode.on.net wrote: > >> On 30.07.21 11:28, spiralofhope wrote:> >> > I also mean that if there are any complex ideas or words, those can >> > be explained in separate specific-documentation in the same way >> > that code does it. > >> My preferred method for nesting descriptive prose, and presenting >> the whole on one page, is to use folding in vim. > >I understand this method. > >However, I disagree with it because it introduces a software dependency >and something like a new workflow. > >Breaking out specific blocks of documentation to a new file is similar >to splitting out a chunk of code and putting it in a new file. It has >side benefits like allowing a specialist to work on that chunk of text >separately. > >All of this, including collaboration to improve it, reminds me of a >wiki, but I'm biased because I was very heavily interested in wikis at >(and well before) their rise. Wikis are much harder to back up than tab indented outlines. Tab indented outlines can pull in external files when used with VimOutliner. The essentials of VimOutliner is almost instantly usable by a person familiar with Vim, although researching ":help vo" is necessary for most efficient use. Unfortunately, VimOutliner has been, in my opinion, been left in a sad state by the maintainers who followed myself and Noel Henson. Within a few days I'll put up a working and efficient, if a couple versions behind, tgz for VimOutliner. WARNING: Don't use the Debian VimOutliner package. This package has autocratically replaced the comma comma command prefix with something much, much slower and more keyboard dependent. VimOutliner is simple enough to install via tgz plus a few copy commands: Noel and I found distro packages to be counter productive. Within a few days I'll post vimoutliner-0.3.5 or vimoutliner-0.3.4, which are the final two TRUE VimOutliner versions, having all the most used features intact. 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
dva...@internode.on.net said on Sat, 07 Aug 2021 16:21:47 +0930 >On 30.07.21 11:28, spiralofhope wrote:> I also mean that if there are >any complex ideas or words, those can be >> explained in separate specific-documentation in the same way that >code >> does it. >My preferred method for nesting descriptive prose, and presenting the >whole on one page, is to use folding in vim. Check out the VimOutliner outline processor. It uses Vim as an engine and it's all about indent-level folding. The current DNG software guides was created with VimOutliner. 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Sat, 07 Aug 2021 16:21:47 +0930 dva...@internode.on.net wrote: > On 30.07.21 11:28, spiralofhope wrote:> > > I also mean that if there are any complex ideas or words, those can > > be explained in separate specific-documentation in the same way that > > code does it. > My preferred method for nesting descriptive prose, and presenting the > whole on one page, is to use folding in vim. I understand this method. However, I disagree with it because it introduces a software dependency and something like a new workflow. Breaking out specific blocks of documentation to a new file is similar to splitting out a chunk of code and putting it in a new file. It has side benefits like allowing a specialist to work on that chunk of text separately. All of this, including collaboration to improve it, reminds me of a wiki, but I'm biased because I was very heavily interested in wikis at (and well before) their rise. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On 30.07.21 11:28, spiralofhope wrote:> I also mean that if there are
any complex ideas or words, those can be
> explained in separate specific-documentation in the same way that
code
> does it.
My preferred method for nesting descriptive prose, and presenting the
whole on one page, is to use folding in vim. Over the decades, I've
accumulated around 420 pages of problem diagnoses and solutions,code
builds, toolchain builds, command options, little bits of howto, etc,
in defence against wetware RAM dropouts. (More frequent in my 60s.)
The initial view is a TOC:
UNIX USER ENVIRONMENT &
TOOLS 73 P
TEXT / OFFICE TOOLS &
PRINTING 63 P
DRAWING
TOOLS
19 L
LINUX SYSTEM
ADMINISTRATION 172 P
PROGRAMMING & EMBEDDED
TOOLS 120 P
CAD
1 P
LinuxCNC:
EMC2: CNC: 13
P
The fifth TOC line, for example, expands to:
PROGRAMMING &
EMBEDDED TOOLS {{{
GNU Manuals: http://www.gnu.org/manual/manual.html
ASSEMBLER:---GAS:ASM:AS:
5 P
BINUTILS:---
63 L
BISON:---YACC:--
4 P
BITSCOPE:---
1 P
BOOT: Debugging: |See BOOT
DEFAULTS:|
2 P
CONFIGURE:-CONF:
15 L
C:---CODE:--
16 L
CTAGS:--
29 L
ENDIAN:--ENDIANNESS:
29 L
FLEX:---
2 P
GCC:- G++
-COMPILER: 30 P
GNU:---CONTRIBUTING:--COPYRIGHT:
51 L
LIBRARIES:-ARCHIVES---AR:
1 P
LINKER: man ld
- LD: 14 P
Other
BINUTILS:
4 P
LINT:
40 L
MAKE:---makefile
2 P
MALLOC:-
4 P
DDD:DEBUGGER
22 L
GDB:DEBUGGER
5 P
DEJAGNU:-DejaGnu
46 L
...
And each of these expand further. The line/page counts are custom
scripted,so not obligatory. I've used folding markers, which contain
each fold, justlike a 'C' code block. There are other folding methods.
For quicker search hits, I just capitalise any keyword and follow it
with a colon.A search hit opens the containing fold, even if it is
seven levels down.There's a lot to like, I find. (Including no damn
GUI within cooee.)
Erik
P.S. To explain words as code does it, we could use ctags, but would
need an
awk script to generate the tags file, I figure. ;-)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Mon, Aug 02, 2021 at 02:03:09AM -0400, Steve Litt wrote:
> Josef Grosch via Dng said on Sun, 1 Aug 2021 14:58:18 -0700
>
> >On 8/1/21 12:50 PM, Steve Litt wrote:
> >> wirelessduck--- via Dng said on Sun, 1 Aug 2021 22:43:35 +1000
> >>
> On 1 Aug 2021, at 21:56, Hendrik Boom
> wrote:
>
> On Fri, Jul 30, 2021 at 01:49:46PM -0400, Steve Litt wrote:
> > Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
> >
> >
> >> Another suggestion I have is to use the variable and method
> >> naming convention that java uses. I like the way it looks and I
> >> think camel case is more readable than snake case.
> > This reminds me of something not yet in the outline. The
> > originating author should place, in comments, near the top, his
> > or her syntax conventions including naming conventions, brace
> > placements if not Python, spaces or tabs.
> >
> > I'm hidiously guilty of using violating my own conventions (or not
> > having any), so I should make that document at the start of a
> > project. Matter of fact, I should make it BEFORE my next project.
> > Naturally, one such stylesheet must be made for Python, another
> > for C, etc.
> >
> > In an ideal world, here's how I'd do C blocks:
> >
> > if(mybool)
> >{
> >do_my_stuff()
> >}
> I tend to use
> if(mybool)
> { do_my_stuff();
> do_other_stuff);
> }
>
> I really believe matching braces should be on the same line, or,
> failing that, at the same level of indentation; i.e., above one
> another.
>
> And I'd like the compile to warn me of deviations from that.
>
> -- hendrik
>
> > However, I do it the way Vim preformats for me, to make my life
> > easier:
> >
> > if(mybool){
> >do_my_stuff()
> > }
> >
> > #ifndef AUTHOR
> >char * AUTHOR = "SteveT"
> > #endif
> >
> > AUTHOR
> >
> > Steve Litt
> >>> Just use indent(1) and forget about all stying problems? I prefer
> >>> `indent -kr`, none of that GNU styling craziness!!
> >>>
> >>> https://manpages.debian.org/buster/indent/indent.1.en.html
> >> I just spent 2 hours trying out indent. As far as I can tell, -bli
> >> doesn't work, and I could find no way to put statements in block at
> >> the same level with the block's parentheses. So what I want is this:
> >>
> >> int myfunc()
> >> {
> >> do_something();
> >> do_more();
> >> if(mybool)
> >>{
> >>do_special()
> >>}
> >> }
>
> [snip]
>
>
> >> SteveT
> >>
> >
> >It looks like you are trying to get what was once called the
> >Whitesmiths style.
> >
> >
> >https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths_style
>
> It is indeed Whitesmith style. I learned it at Santa Monica College's
> Pascal course, and when I busted into programming professionally, I
> used Whitesmith Pascal so everyone used Whitesmith style, except with
> "begin" and "end" instead of braces.
>
> First time I saw the beginning brace at the end of the if() or
> declaration was in the Linux world, and I almost barfed. But because
> the beginning brace at the end of the if() or declartion was default
> for Vim, I started using beginning brace at end.
>
> I still think that for a language that has a begin and end for a block,
> Whitesmith is best. For a language that has stuff like "endwhile" or
> "endif" or "fi", beginning brace at end of if() is what I prefer.
As an old Algol 68 programmer who is accustoed to 'fi', the only layout
that makes sense to me is
IF condition
THEN do something
do more
ELSE do something else
do other stuff
FI
This assumes relatively short keywords.
-- hendrik
>
> >
> >
> >Back when the earth was still cooling, 1991 or so, I worked at
> >Motorola in Chicago and this was the preferred coding style for the
> >project I was a member of. Configuring indent was always a matter of
> >trail and error and the docs could be better. Using a config file,
> >~/.indent.pro made things easier. I might still have a copy of that
> >file somewhere, I'll look.
>
> I'd love to see it!
>
> 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
Josef Grosch via Dng said on Sun, 1 Aug 2021 14:58:18 -0700
>On 8/1/21 12:50 PM, Steve Litt wrote:
>> wirelessduck--- via Dng said on Sun, 1 Aug 2021 22:43:35 +1000
>>
On 1 Aug 2021, at 21:56, Hendrik Boom
wrote:
On Fri, Jul 30, 2021 at 01:49:46PM -0400, Steve Litt wrote:
> Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
>
>
>> Another suggestion I have is to use the variable and method
>> naming convention that java uses. I like the way it looks and I
>> think camel case is more readable than snake case.
> This reminds me of something not yet in the outline. The
> originating author should place, in comments, near the top, his
> or her syntax conventions including naming conventions, brace
> placements if not Python, spaces or tabs.
>
> I'm hidiously guilty of using violating my own conventions (or not
> having any), so I should make that document at the start of a
> project. Matter of fact, I should make it BEFORE my next project.
> Naturally, one such stylesheet must be made for Python, another
> for C, etc.
>
> In an ideal world, here's how I'd do C blocks:
>
> if(mybool)
>{
>do_my_stuff()
>}
I tend to use
if(mybool)
{ do_my_stuff();
do_other_stuff);
}
I really believe matching braces should be on the same line, or,
failing that, at the same level of indentation; i.e., above one
another.
And I'd like the compile to warn me of deviations from that.
-- hendrik
> However, I do it the way Vim preformats for me, to make my life
> easier:
>
> if(mybool){
>do_my_stuff()
> }
>
> #ifndef AUTHOR
>char * AUTHOR = "SteveT"
> #endif
>
> AUTHOR
>
> Steve Litt
>>> Just use indent(1) and forget about all stying problems? I prefer
>>> `indent -kr`, none of that GNU styling craziness!!
>>>
>>> https://manpages.debian.org/buster/indent/indent.1.en.html
>> I just spent 2 hours trying out indent. As far as I can tell, -bli
>> doesn't work, and I could find no way to put statements in block at
>> the same level with the block's parentheses. So what I want is this:
>>
>> int myfunc()
>> {
>> do_something();
>> do_more();
>> if(mybool)
>>{
>>do_special()
>>}
>> }
[snip]
>> SteveT
>>
>
>It looks like you are trying to get what was once called the
>Whitesmiths style.
>
>
>https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths_style
It is indeed Whitesmith style. I learned it at Santa Monica College's
Pascal course, and when I busted into programming professionally, I
used Whitesmith Pascal so everyone used Whitesmith style, except with
"begin" and "end" instead of braces.
First time I saw the beginning brace at the end of the if() or
declaration was in the Linux world, and I almost barfed. But because
the beginning brace at the end of the if() or declartion was default
for Vim, I started using beginning brace at end.
I still think that for a language that has a begin and end for a block,
Whitesmith is best. For a language that has stuff like "endwhile" or
"endif" or "fi", beginning brace at end of if() is what I prefer.
>
>
>Back when the earth was still cooling, 1991 or so, I worked at
>Motorola in Chicago and this was the preferred coding style for the
>project I was a member of. Configuring indent was always a matter of
>trail and error and the docs could be better. Using a config file,
>~/.indent.pro made things easier. I might still have a copy of that
>file somewhere, I'll look.
I'd love to see it!
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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On 8/1/21 12:50 PM, Steve Litt wrote:
wirelessduck--- via Dng said on Sun, 1 Aug 2021 22:43:35 +1000
On 1 Aug 2021, at 21:56, Hendrik Boom wrote:
On Fri, Jul 30, 2021 at 01:49:46PM -0400, Steve Litt wrote:
Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
Another suggestion I have is to use the variable and method naming
convention that java uses. I like the way it looks and I think
camel case is more readable than snake case.
This reminds me of something not yet in the outline. The originating
author should place, in comments, near the top, his or her syntax
conventions including naming conventions, brace placements if not
Python, spaces or tabs.
I'm hidiously guilty of using violating my own conventions (or not
having any), so I should make that document at the start of a
project. Matter of fact, I should make it BEFORE my next project.
Naturally, one such stylesheet must be made for Python, another for
C, etc.
In an ideal world, here's how I'd do C blocks:
if(mybool)
{
do_my_stuff()
}
I tend to use
if(mybool)
{ do_my_stuff();
do_other_stuff);
}
I really believe matching braces should be on the same line, or,
failing that, at the same level of indentation; i.e., above one
another.
And I'd like the compile to warn me of deviations from that.
-- hendrik
However, I do it the way Vim preformats for me, to make my life
easier:
if(mybool){
do_my_stuff()
}
#ifndef AUTHOR
char * AUTHOR = "SteveT"
#endif
AUTHOR
Steve Litt
Just use indent(1) and forget about all stying problems? I prefer
`indent -kr`, none of that GNU styling craziness!!
https://manpages.debian.org/buster/indent/indent.1.en.html
I just spent 2 hours trying out indent. As far as I can tell, -bli
doesn't work, and I could find no way to put statements in block at the
same level with the block's parentheses. So what I want is this:
int myfunc()
{
do_something();
do_more();
if(mybool)
{
do_special()
}
}
If you know a way to accomplish the preceding with indent, please let
me know. Closest I could get was
int myfunc()
{
do_something();
do_more();
if(mybool)
{
do_special()
}
}
Eeeeu, ugly, confusing, and inconsistent. I'd rather just keep
doing it Vim's way:
int myfunc(){
do_something();
do_more();
if(mybool){
do_special()
}
}
The preceding is at least consistent, and the ending brace is at the
level of the statement running the block, which at least is fathomable
if you get used to it.
SteveT
It looks like you are trying to get what was once called the Whitesmiths
style.
https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths_style
Back when the earth was still cooling, 1991 or so, I worked at Motorola
in Chicago and this was the preferred coding style for the project I was
a member of. Configuring indent was always a matter of trail and error
and the docs could be better. Using a config file, ~/.indent.pro made
things easier. I might still have a copy of that file somewhere, I'll look.
Josef
--
Josef Grosch| Another day closer |
jgro...@mooseriver.com | to Redwood Heaven | Berkeley, Ca.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
wirelessduck--- via Dng said on Sun, 1 Aug 2021 22:43:35 +1000
>> On 1 Aug 2021, at 21:56, Hendrik Boom wrote:
>>
>> On Fri, Jul 30, 2021 at 01:49:46PM -0400, Steve Litt wrote:
>>> Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
>>>
>>>
Another suggestion I have is to use the variable and method naming
convention that java uses. I like the way it looks and I think
camel case is more readable than snake case.
>>>
>>> This reminds me of something not yet in the outline. The originating
>>> author should place, in comments, near the top, his or her syntax
>>> conventions including naming conventions, brace placements if not
>>> Python, spaces or tabs.
>>>
>>> I'm hidiously guilty of using violating my own conventions (or not
>>> having any), so I should make that document at the start of a
>>> project. Matter of fact, I should make it BEFORE my next project.
>>> Naturally, one such stylesheet must be made for Python, another for
>>> C, etc.
>>>
>>> In an ideal world, here's how I'd do C blocks:
>>>
>>> if(mybool)
>>> {
>>> do_my_stuff()
>>> }
>>
>> I tend to use
>> if(mybool)
>> { do_my_stuff();
>>do_other_stuff);
>> }
>>
>> I really believe matching braces should be on the same line, or,
>> failing that, at the same level of indentation; i.e., above one
>> another.
>>
>> And I'd like the compile to warn me of deviations from that.
>>
>> -- hendrik
>>
>>>
>>> However, I do it the way Vim preformats for me, to make my life
>>> easier:
>>>
>>> if(mybool){
>>> do_my_stuff()
>>> }
>>>
>>> #ifndef AUTHOR
>>> char * AUTHOR = "SteveT"
>>> #endif
>>>
>>> AUTHOR
>>>
>>> Steve Litt
>
>Just use indent(1) and forget about all stying problems? I prefer
>`indent -kr`, none of that GNU styling craziness!!
>
>https://manpages.debian.org/buster/indent/indent.1.en.html
I just spent 2 hours trying out indent. As far as I can tell, -bli
doesn't work, and I could find no way to put statements in block at the
same level with the block's parentheses. So what I want is this:
int myfunc()
{
do_something();
do_more();
if(mybool)
{
do_special()
}
}
If you know a way to accomplish the preceding with indent, please let
me know. Closest I could get was
int myfunc()
{
do_something();
do_more();
if(mybool)
{
do_special()
}
}
Eeeeu, ugly, confusing, and inconsistent. I'd rather just keep
doing it Vim's way:
int myfunc(){
do_something();
do_more();
if(mybool){
do_special()
}
}
The preceding is at least consistent, and the ending brace is at the
level of the statement running the block, which at least is fathomable
if you get used to it.
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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
tito via Dng said on Sun, 1 Aug 2021 14:41:31 +0200
>Hi,
>I really prefer
>
>if (mybool) {
> do_my_stuff();
> do_other_stuff);
>}
Vim prefers it that way too, which is why (and the only reason) I use
the preceding brace placement.
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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
Hi,
On 1/8/21 14:41, tito via Dng wrote:
Hi,
I really prefer
if (mybool) {
do_my_stuff();
do_other_stuff);
}
for the rule of least vertical screen usage (same as yours)
and the brace and the if on the same indentation level
make it clear where the conditional block of code stops.
Me too. I tend to use the Linux Kernel coding style:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
Cheers,
Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
> On 1 Aug 2021, at 21:56, Hendrik Boom wrote:
>
> On Fri, Jul 30, 2021 at 01:49:46PM -0400, Steve Litt wrote:
>> Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
>>
>>
>>> Another suggestion I have is to use the variable and method naming
>>> convention that java uses. I like the way it looks and I think camel
>>> case is more readable than snake case.
>>
>> This reminds me of something not yet in the outline. The originating
>> author should place, in comments, near the top, his or her syntax
>> conventions including naming conventions, brace placements if not
>> Python, spaces or tabs.
>>
>> I'm hidiously guilty of using violating my own conventions (or not
>> having any), so I should make that document at the start of a project.
>> Matter of fact, I should make it BEFORE my next project. Naturally, one
>> such stylesheet must be made for Python, another for C, etc.
>>
>> In an ideal world, here's how I'd do C blocks:
>>
>> if(mybool)
>> {
>> do_my_stuff()
>> }
>
> I tend to use
> if(mybool)
> { do_my_stuff();
>do_other_stuff);
> }
>
> I really believe matching braces should be on the same line, or,
> failing that, at the same level of indentation; i.e., above one
> another.
>
> And I'd like the compile to warn me of deviations from that.
>
> -- hendrik
>
>>
>> However, I do it the way Vim preformats for me, to make my life easier:
>>
>> if(mybool){
>> do_my_stuff()
>> }
>>
>> #ifndef AUTHOR
>> char * AUTHOR = "SteveT"
>> #endif
>>
>> AUTHOR
>>
>> Steve Litt
Just use indent(1) and forget about all stying problems? I prefer `indent -kr`,
none of that GNU styling craziness!!
https://manpages.debian.org/buster/indent/indent.1.en.html___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Sun, 1 Aug 2021 07:56:18 -0400
Hendrik Boom wrote:
> On Fri, Jul 30, 2021 at 01:49:46PM -0400, Steve Litt wrote:
> > Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
> >
> >
> > >Another suggestion I have is to use the variable and method naming
> > >convention that java uses. I like the way it looks and I think camel
> > >case is more readable than snake case.
> >
> > This reminds me of something not yet in the outline. The originating
> > author should place, in comments, near the top, his or her syntax
> > conventions including naming conventions, brace placements if not
> > Python, spaces or tabs.
> >
> > I'm hidiously guilty of using violating my own conventions (or not
> > having any), so I should make that document at the start of a project.
> > Matter of fact, I should make it BEFORE my next project. Naturally, one
> > such stylesheet must be made for Python, another for C, etc.
> >
> > In an ideal world, here's how I'd do C blocks:
> >
> > if(mybool)
> >{
> >do_my_stuff()
> >}
>
> I tend to use
> if(mybool)
> { do_my_stuff();
> do_other_stuff);
> }
Hi,
I really prefer
if (mybool) {
do_my_stuff();
do_other_stuff);
}
for the rule of least vertical screen usage (same as yours)
and the brace and the if on the same indentation level
make it clear where the conditional block of code stops.
Also for one liners this form saves space
if (mybool) { do_my_stuff(); }
but keep the braces if you or others need to add more code
later.
Just my 2 cents
Tito
>
> I really believe matching braces should be on the same line, or,
> failing that, at the same level of indentation; i.e., above one
> another.
>
> And I'd like the compile to warn me of deviations from that.
>
> -- hendrik
>
> >
> > However, I do it the way Vim preformats for me, to make my life easier:
> >
> > if(mybool){
> >do_my_stuff()
> > }
> >
> > #ifndef AUTHOR
> >char * AUTHOR = "SteveT"
> > #endif
> >
> > AUTHOR
> >
> > 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Fri, Jul 30, 2021 at 01:49:46PM -0400, Steve Litt wrote:
> Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
>
>
> >Another suggestion I have is to use the variable and method naming
> >convention that java uses. I like the way it looks and I think camel
> >case is more readable than snake case.
>
> This reminds me of something not yet in the outline. The originating
> author should place, in comments, near the top, his or her syntax
> conventions including naming conventions, brace placements if not
> Python, spaces or tabs.
>
> I'm hidiously guilty of using violating my own conventions (or not
> having any), so I should make that document at the start of a project.
> Matter of fact, I should make it BEFORE my next project. Naturally, one
> such stylesheet must be made for Python, another for C, etc.
>
> In an ideal world, here's how I'd do C blocks:
>
> if(mybool)
>{
>do_my_stuff()
>}
I tend to use
if(mybool)
{ do_my_stuff();
do_other_stuff);
}
I really believe matching braces should be on the same line, or,
failing that, at the same level of indentation; i.e., above one
another.
And I'd like the compile to warn me of deviations from that.
-- hendrik
>
> However, I do it the way Vim preformats for me, to make my life easier:
>
> if(mybool){
>do_my_stuff()
> }
>
> #ifndef AUTHOR
>char * AUTHOR = "SteveT"
> #endif
>
> AUTHOR
>
> 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Fri, Jul 30, 2021 at 03:33:05PM +0200, Enrico Weigelt, metux IT consult wrote: > On 30.07.21 00:32, Josef Grosch via Dng wrote: > > > Global variables are a disaster looking for a place to happen, avoid at > > all cost. The scope of variables should be as small as possible. > > it depends ... for small programs where you really *know* (by > definition) there really may only be one instance of that data, it might > be actually the better solution - in that case you know the working set > for sure (size of .data). This is the kind of programming where you also > rely on the OS (kernel, supervisor, container, ...) doing all post > termination cleanups. > > Many Plan9 programs are written in that way - they're so damn small that > they just don't need much function local (or even dynamically allocated) > data. If the program is that small, global variables already satisfy the "as small as possible" convention. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Fri, 30 Jul 2021, Steve Litt wrote: > idea, although one screenfull sounds a little too short for prose, to "one screenfull" what's that. When I started interactive programming it was on an teletype with continuous scroll of paper - you tended to print one or teo lines at a time - just t6o save time! Then 24 (or 25) lines of 80 cols for alot of terminals. I always chaffed at the restriction of the number of lines of those screens, but I've always taken 80 cols os a sensible line length. Nowadays I have xtemrs set to be aprox 40 x 80. But lots of people I've worked with have one terminal screen filling the whole screen - with _far_ too much on the screen to digest sensibly. So what size is a screenfull? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On 30.07.21 00:32, Josef Grosch via Dng wrote: Global variables are a disaster looking for a place to happen, avoid at all cost. The scope of variables should be as small as possible. it depends ... for small programs where you really *know* (by definition) there really may only be one instance of that data, it might be actually the better solution - in that case you know the working set for sure (size of .data). This is the kind of programming where you also rely on the OS (kernel, supervisor, container, ...) doing all post termination cleanups. Many Plan9 programs are written in that way - they're so damn small that they just don't need much function local (or even dynamically allocated) data. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
spiralofhope said on Fri, 30 Jul 2021 11:28:27 -0700 >On Fri, 30 Jul 2021 13:40:30 -0400 >Steve Litt wrote: > >> g4sra via Dng said on Thu, 29 Jul 2021 21:16:31 + >> >> >> [...] >> >> O! >> >> Makes perfect sense now. Thanks g4sra and spiralofhope. That's a good >> idea, although one screenfull sounds a little too short for prose, to >> me. But that's just a spectrum judgment call type of thing. >> >> I have to think about that. It could revolutionize documentation. Let >> me give that some thought. > >I also mean that if there are any complex ideas or words, those can be >explained in separate specific-documentation in the same way that code >does it. Nice!! 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Fri, 30 Jul 2021 13:40:30 -0400 Steve Litt wrote: > g4sra via Dng said on Thu, 29 Jul 2021 21:16:31 + > > > [...] > > O! > > Makes perfect sense now. Thanks g4sra and spiralofhope. That's a good > idea, although one screenfull sounds a little too short for prose, to > me. But that's just a spectrum judgment call type of thing. > > I have to think about that. It could revolutionize documentation. Let > me give that some thought. I also mean that if there are any complex ideas or words, those can be explained in separate specific-documentation in the same way that code does it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
Josef Grosch via Dng said on Thu, 29 Jul 2021 15:32:05 -0700
>Another suggestion I have is to use the variable and method naming
>convention that java uses. I like the way it looks and I think camel
>case is more readable than snake case.
This reminds me of something not yet in the outline. The originating
author should place, in comments, near the top, his or her syntax
conventions including naming conventions, brace placements if not
Python, spaces or tabs.
I'm hidiously guilty of using violating my own conventions (or not
having any), so I should make that document at the start of a project.
Matter of fact, I should make it BEFORE my next project. Naturally, one
such stylesheet must be made for Python, another for C, etc.
In an ideal world, here's how I'd do C blocks:
if(mybool)
{
do_my_stuff()
}
However, I do it the way Vim preformats for me, to make my life easier:
if(mybool){
do_my_stuff()
}
#ifndef AUTHOR
char * AUTHOR = "SteveT"
#endif
AUTHOR
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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
g4sra via Dng said on Thu, 29 Jul 2021 21:16:31 + >If I correctly interpret spiralofhope's meaning > >Regard the document itself as if it was pseudocode. >Apply the rules of the document to the document e.g. > >1) keep the document as short as possible >... >3) all of a paragraph must fit on the screen >... >9) the document must be readable to others like a children's book O! Makes perfect sense now. Thanks g4sra and spiralofhope. That's a good idea, although one screenfull sounds a little too short for prose, to me. But that's just a spectrum judgment call type of thing. I have to think about that. It could revolutionize documentation. Let me give that some thought. 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
> On 7/28/21 1:12 PM, Steve Litt wrote: >> [ Beverity ] >> Does anyone have other list items to add? https://thedailywtf.com/ Is a good resource of what “not” to do.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On 7/28/21 1:12 PM, Steve Litt wrote:
[ Beverity ]
Does anyone have other list items to add?
Now that you got me thinking;
One should be explicit instead of implicit. I see this in code all the
time and it drives me crazy
// NO
if (condition)
doSomething();
// YES
if (condition) {
doSomething();
}
C and Java let you get away with this. The existence of real block
delimiters makes clear the intent.
Josef
--
Josef Grosch| Another day closer |
jgro...@mooseriver.com | to Redwood Heaven | Berkeley, Ca.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On 7/28/21 2:02 PM, tito via Dng wrote:
[ DELETED for brevity ]
That's bad... I love global variables ;-( as they avoid shuffling around
parameters in functions (KISS?)
Global variables are a disaster looking for a place to happen, avoid at
all cost. The scope of variables should be as small as possible.
OK, this is my private little hell but I am going to share. I dislike
long parameter list when calling a method. You have to remember the
order and the type. I prefer to pass in a struct / hash / class object /
associated array / dictionary / {whatever}. it makes things cleaner.
Depending on the language I prefer to pass the {whatever} in by
reference instead of pass by value.
Another suggestion I have is to use the variable and method naming
convention that java uses. I like the way it looks and I think camel
case is more readable than snake case.
Josef
--
Josef Grosch| Another day closer |
jgro...@mooseriver.com | to Redwood Heaven | Berkeley, Ca.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Thursday, July 29th, 2021 at 10:00 PM, Steve Litt wrote: > g4sra via Dng said on Thu, 29 Jul 2021 20:50:02 + > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, July 29th, 2021 at 9:19 PM, Steve Litt > > sl...@troubleshooters.com wrote: > > > > > spiralofhope said on Thu, 29 Jul 2021 11:00:48 -0700 > > > > Once this gets complex enough it'll need to be self-hosting in a > > > > sense; check the rules against the rules -- de-duplicate, > > > > simplify, add documentation, etc. :) > > > > > > Internal consistency? I don't know the correct term offhand. > > > > > Huh? > > > > Apply the whole document to each individual line sequentially ... > > Recursive Iteration ? > > I still don't understand. > If I correctly interpret spiralofhope's meaning Regard the document itself as if it was pseudocode. Apply the rules of the document to the document e.g. 1) keep the document as short as possible ... 3) all of a paragraph must fit on the screen ... 9) the document must be readable to others like a children's book > SteveT > > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
g4sra via Dng said on Thu, 29 Jul 2021 20:50:02 + >Sent with ProtonMail Secure Email. > >‐‐‐ Original Message ‐‐‐ > >On Thursday, July 29th, 2021 at 9:19 PM, Steve Litt > wrote: > >> spiralofhope said on Thu, 29 Jul 2021 11:00:48 -0700 >> > >> > Once this gets complex enough it'll need to be self-hosting in a >> > sense; check the rules against the rules -- de-duplicate, >> > simplify, add documentation, etc. :) >> > > >> > Internal consistency? I don't know the correct term offhand. >> > >> Huh? > >Apply the whole document to each individual line sequentially ... >Recursive Iteration ? I still don't understand. 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, July 29th, 2021 at 9:19 PM, Steve Litt wrote: > spiralofhope said on Thu, 29 Jul 2021 11:00:48 -0700 > > > Once this gets complex enough it'll need to be self-hosting in a sense; > > check the rules against the rules -- de-duplicate, simplify, add > > documentation, etc. :) > > > > Internal consistency? I don't know the correct term offhand. > > Huh? Apply the whole document to each individual line sequentially ... Recursive Iteration ? > > SteveT > publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
spiralofhope said on Thu, 29 Jul 2021 11:00:48 -0700 >Once this gets complex enough it'll need to be self-hosting in a sense; >check the rules against the rules -- de-duplicate, simplify, add >documentation, etc. :) > >Internal consistency? I don't know the correct term offhand. Huh? 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
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
Once this gets complex enough it'll need to be self-hosting in a sense; check the rules against the rules -- de-duplicate, simplify, add documentation, etc. :) Internal consistency? I don't know the correct term offhand. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Starting outline for the DNG Safe Programmer Certificate
On Wed, 28 Jul 2021 16:12:53 -0400 Steve Litt 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
