7 Mar
2021
7 Mar
'21
5:43 a.m.
John Cowan wrote in
<CAD2gp_Qv7pO6P_LyZ=5zXm78GpBK4sUE2f8_4BBfyqJP7OSAJA(a)mail.gmail.com>:
|On Fri, Mar 5, 2021 at 9:14 AM Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote:
|> But, not important. A real change to my coding style came when
|> i looked around Plan9 source code, the pragmatism to simply not
|> use spaces in language constructs aka statements at all, for
|> example "if(a){" instead of "if(a) {" or "if (a) {",
and let alone
|> "if (a)\nALIGN{\nALIGN" and whatever else.
|
|That way lies APL madness. To exemplify, Kona is an open-source
|interpreter for Arthur Whitney's K version 3 language, which is closely
|related to APL, but crams almost all of the APL operators onto single ASCII
|characters with massive overloading. For example, monadic ! is APL "iota",
|but dyadic ! is "modulo" if both arguments are numbers and "rotate"
if the
|right argument is a number and the left argument is a vector. What any of
|these has to do with the rest is beyond me: I had to create a set of flash
|cards to help me learn them all.
|
|Well, here's a procedure definition from the Kona source, in a file
|helpfully named kc.c (almost all of the source files have 1-2 character
|names):
|
|I wds_(K*a,FILE*f,I l)
|{ S s=0,t=0; I b=0,c=0,m=0,n=0,v=0; K z=0; PDA p=0;
| I o=isatty(STDIN)&&f==stdin;
| if(-1==(c=getline_(&s,&n,f)))GC;
| appender(&t,&m,s,n);
| while(1==(v=complete(t,m,&p,0)))
| { b=parsedepth(p);
| if(o)prompt(b+l);
| if(-1==(c=getline_(&s,&n,f)))GC;
| appender(&t,&m,s,n); }
| SW(v){CS(2,show(kerr("unmatched"));GC) CS(3,show(kerr("nest"));
GC)}
| z=newK(-3,m-1);
| strncpy(kC(z),t,m-1);
| cleanup:
| free(s); free(t);
| if(p)pdafree(p);
| if((v||c==-1)&&z){cd(z); *a=0;}
| else *a=z;
| R v?-v:c; } // -1 EOF, -2 unmatched, -3 nest
|
|If you want that sort of thing, you can certainly have it. Note the
|single-space ident and the cuddled right braces. Note also the label
|"cleanup:"; presumably a "goto cleanup;" is hidden somewhere in the
|single-letter (of course) macros.
I do not, no. The above has maybe the advantage that you really
really have to sit down and understand it as a whole before you
change anything, or apply patches. This is very different to the
style that sometimes can be seen in projects with many people and
many patches, where code is packed in what-the-writer-thinks-is-a-
logical-block. I (unfortunately) do it like that too, very
unfortunately with diverging positions of what a logical block is.
Just from a single pick, take Linux 5.10 ipc/sem.c. You see
sma = sem_alloc(nsems);
if (!sma)
return -ENOMEM;
sma->sem_perm.mode = (semflg & S_IRWXUGO);
sma->sem_perm.key = key;
1
sma->sem_perm.security = NULL;
2 retval = security_sem_alloc(&sma->sem_perm);
if (retval) {
kvfree(sma);
return retval;
}
and i know that i would sometimes remove the newline 1 to finish
init of sem_perm, and instead introduce a newline before
2 instead. I have no idea of kernel of course, here .security
depends on a special config and security_sem_alloc() just does
nothing without it (returning 0), not even setting .security to
NULL, whereas otherwise .security is definetely set by
lsm_ipc_alloc(), so maybe i understand 1, .. sometimes. But
i would think about it. And all of this just cannot happen with
the code above, i could use this style to fool myself into just
not thinking about just useless thoughts!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)