Reply-To: richard.harnden@invalid.com

On 21/03/2024 19:23, Keith Thompson wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

Yes I did :)

I use that sometimes, but one disadvantage is that if you're viewing the middle of a very large block of code, it can be hard to tell that it's
been "commented" out.

I have a script that applies "#if 0" and "#endif" to a block of code
*and* prepends "* " to each line in the block.

That's a good ideo. Can you share it?



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Richard Harnden <richard.nospam@gmail.invalid> writes:

On 21/03/2024 19:23, Keith Thompson wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

Yes I did :)

I use that sometimes, but one disadvantage is that if you're viewing
the
middle of a very large block of code, it can be hard to tell that it's
been "commented" out.
I have a script that applies "#if 0" and "#endif" to a block of code
*and* prepends "* " to each line in the block.

That's a good ideo. Can you share it?

Sure. It's a Perl script called "if0". It tries to deal with
variations in line endings (I sometimes work with code with LF and/or
CRLF line endings) and with tabs vs. spaces as indentation.

I don't have a script that undoes what if0 does. I might write one
one of these days, but usually I can just revert the change in source
control or change it back manually.

Complaints about Perl being write-only will be cheerfully ignored.

```
#!/usr/bin/perl

use strict;
use warnings;

my @lines = <>;
my $newline = "\n";
if (defined $lines[0] and $lines[0] =~ /\r$/) {
$newline = "\r\n";
}

print "#if 0$newline";
foreach my $line (@lines) {
if ($line =~ /^ /) {
$line =~ s/ /*/;
}
elsif ($line =~ /^\r?$/) {
$line =~ s/^/*/;
}
else {
$line =~ s/^/* /;
}
print $line;
}
print "#endif /* 0 */$newline";
```

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: None to speak of (3:633/280.2@fidonet)

Reply-To: richard.harnden@invalid.com

On 21/03/2024 19:48, Keith Thompson wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:

On 21/03/2024 19:23, Keith Thompson wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of >>>> code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

Yes I did :)

I use that sometimes, but one disadvantage is that if you're viewing
the
middle of a very large block of code, it can be hard to tell that it's
been "commented" out.
I have a script that applies "#if 0" and "#endif" to a block of code
*and* prepends "* " to each line in the block.

That's a good ideo. Can you share it?

Sure. It's a Perl script called "if0". It tries to deal with
variations in line endings (I sometimes work with code with LF and/or
CRLF line endings) and with tabs vs. spaces as indentation.

I don't have a script that undoes what if0 does. I might write one
one of these days, but usually I can just revert the change in source
control or change it back manually.

Complaints about Perl being write-only will be cheerfully ignored.

```
#!/usr/bin/perl

use strict;
use warnings;

my @lines = <>;
my $newline = "\n";
if (defined $lines[0] and $lines[0] =~ /\r$/) {
$newline = "\r\n";
}

print "#if 0$newline";
foreach my $line (@lines) {
if ($line =~ /^ /) {
$line =~ s/ /*/;
}
elsif ($line =~ /^\r?$/) {
$line =~ s/^/*/;
}
else {
$line =~ s/^/* /;
}
print $line;
}
print "#endif /* 0 */$newline";
```

Thank you


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Reply-To: slp53@pacbell.net

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

I use that sometimes, but one disadvantage is that if you're viewing the >middle of a very large block of code, it can be hard to tell that it's
been "commented" out.

Often syntax highlighting (e.g. vim) will solve that.

In projects with many fingers in the pie, I generally prefer either a descriptive (and undefined) macro name or a block comment in
the #if 0 region to indicate exactly _why_ it was not just removed
from the source file entirely.

Makes it easier for whomever is reading and/or maintaining the
code to follow it.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)

On 2024-03-21, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

I use that sometimes, but one disadvantage is that if you're viewing the middle of a very large block of code, it can be hard to tell that it's
been "commented" out.

FWIW; Vim colors #if 0 blocks as if they were comments.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2024-03-21, Scott Lurndal <scott@slp53.sl.home> wrote:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

I use that sometimes, but one disadvantage is that if you're viewing the >>middle of a very large block of code, it can be hard to tell that it's
been "commented" out.

Often syntax highlighting (e.g. vim) will solve that.

In projects with many fingers in the pie, I generally prefer either a descriptive (and undefined) macro name or a block comment in
the #if 0 region to indicate exactly _why_ it was not just removed
from the source file entirely.

Makes it easier for whomever is reading and/or maintaining the
code to follow it.

I have a simpler approach: commits which introduced commented-out
code, whether with #if 0, or any other means, shall not be merged.

I don't perpetrate that in my open source projects, and "-1" such
submissions at work.

When someone wants to remove code, I encourage them to actually
delete it. The comment about why it was deleted goes into the
commit log.

Usually people are relieved; deleting it was what they wanted, but they
weren't sure due the code not being their area or whatever.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Thu, 21 Mar 2024 19:46:29 +0100, fir wrote:

... mostly i use // coments becouse i nearly
exclusively use comments to comment out code and in editor i got it
under control+shift+c

1) You can comment out entire blocks at once with block comments
2) This is why we have version control; just delete the unneeded block,
since you can get it back from your commit history if you change your mind later anyway.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame, /*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

I prefer to put the argument names at the end of the line.

But putting them in front of the values looks more like the syntax in languages (like Ada and Python) that do allow specification of argument keywords.

And maybe, in future, if it becomes valid in C (or some successor), then updating the code should be as simple as removing the comment symbols.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Thu, 21 Mar 2024 12:48:53 -0700, Keith Thompson wrote:

It's a Perl script ...

Shame. I was hoping for something in, say, Emacs Lisp, that can be invoked from directly within the editor, operating on a selected region within the buffer, and bound to a keystroke.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Kaz Kylheku <433-929-6894@kylheku.com> writes:

On 2024-03-21, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

I use that sometimes, but one disadvantage is that if you're viewing the
middle of a very large block of code, it can be hard to tell that it's
been "commented" out.

FWIW; Vim colors #if 0 blocks as if they were comments.

Sure, but I don't always view code in a way that allows for
language-specific highlighting. (In fact I rarely do so, and I'm not
willing to assume that everyone else always does so.)

I developed my habits when syntax highlighting wasn't an option.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: None to speak of (3:633/280.2@fidonet)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Thu, 21 Mar 2024 12:48:53 -0700, Keith Thompson wrote:

It's a Perl script ...

Shame. I was hoping for something in, say, Emacs Lisp, that can be invoked from directly within the editor, operating on a selected region within the buffer, and bound to a keystroke.

Feel free to write it. (And an Emacs Lisp function doesn't help me in vim.)

Perhaps I should have mentioned that the Perl script I posted reads from
stdin and writes to stdout. It can also read from one or more files
named on its command line.

It slurps all its input into memory. I could have written it to stream
stdin to stdout, which could work better for large inputs, but the
current version works well enough for me.

#if 0
* Meanwhile, Emacs can invoke an external command on a region of text, and
* you can bind that to a keystroke if you like. I used it on this paragraph. #endif /* 0 */

"shell-command-on-region" is bound to "M-|" (Alt-| or Esc |).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: None to speak of (3:633/280.2@fidonet)

On 21/03/2024 22:16, Lawrence D'Oliveiro wrote:

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame, /*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

I prefer to put the argument names at the end of the line.

But putting them in front of the values looks more like the syntax in languages (like Ada and Python) that do allow specification of argument keywords.

Why would you want your C code to look like Python? That's as silly as wanting your Python code to look like C code. The languages are
significantly different - each with their strengths and weaknesses, and
each suitable for quite different kinds of programming tasks.

I can appreciate wanting to document what the parameters are in a
function that takes far too many parameters. I don't see any benefit in
doing so in a way that looks vaguely like an entirely different
programming language.

gdImageCopyResampled
(
ResizedFrame, // destination frame
Context.StillFrame, // source frame
0, 0, // destination x, y
0, 0, // source x, y
ResizedFrame->sx, // frame sizes
ResizedFrame->sy,
Context.StillFrame->sx,
Context.StillFrame->sy
);

That is simpler and more informative than your style (IMHO of course).

And maybe, in future, if it becomes valid in C (or some successor), then updating the code should be as simple as removing the comment symbols.

I am a fan of being able to name parameters in languages that allow it.
I am quite confident that this will never come to C. It /might/ make it
into C++, but as people have been writing proposals to do so for 20
years at least, I am not holding my breath.

In the meantime, you can use structs with parameters and use designated initialisers and compound literals to get a similar effect but with a
heavier and less flexible syntax. Or you can use specific types for
each parameter, along with macros (or constructors in C++), to ensure
that you can't get the parameters mixed up. Again, it's more boiler
plate and a heavier syntax than named parameters would be.



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 21/03/2024 17:32, Richard Harnden wrote:

On 21/03/2024 15:20, David Brown wrote:

On 21/03/2024 07:19, Lawrence D'Oliveiro wrote:

The original comment delimiters in C were copied from PL/I: everything
between “/*” and “*/” is a comment, even extending across multiple >>> lines.
Pascal had something similar, only the delimiters were “{” and “}”, or
“(*” and “*)” for compatibility with machines with restricted character
sets.

For some reason, the Ada folks decided block comments were not a good
idea, and so their rule was that anything after “--” up to the end of >>> the
line was a comment. And C++ adopted a similar rule, using “//” as their >>> to-end-of-line comment marker, though of course they also kept C-style
block comments. Java also keeps both these styles.

Since then, I’ve seen newer programmers gravitate towards the
rest-of-line
form in preference to the block form, and I’m not sure why. I’m fond of >>> writing things like

/*
     A very simple HTML/XML entity-escape function--why isn’t this >>> ���� part of the standard Java API?
*/

which involve less typing than

//
//  A very simple HTML/XML entity-escape function--why isn’t this
//� part of the standard Java API?
//

I use both - block comments when making a comment block, and line
comments when adding comments to the end of a line.� That seems pretty
obvious to me.

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0

"#if 0", presumably.

...
#endif

Yes, I do that too. But if it is more than just a fairly trivial amount
of code, and not just for quite tests during development, then I hugely
prefer to give the block a name:

// Explanation of EnableExtraChecks ...
#define EnableExtraChecks 1

....

#if EnableExtraChecks
....
#endif // #if EnableExtraChecks


Depending on the circumstances, the guard macro definition might be at
the start of the file, or it might be just before the commented-out
block. But even in the later case, giving it a name like this makes it
easier to match up when the #endif (and perhaps #else) has a comment.
It also makes it easier to get right if there are several blocks that
get commented out, whether they use the same or different guards.


Note that some coding standards (such as MISRA) do not allow this
technique, because it can be hard (without a good highlighting editor or
IDE) to see if code is active or disabled.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <86r0g3liii.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

The original comment delimiters in C were copied from PL/I: everything >>>

Cite?

Seen in the B language manual:

Comments are delimited as in PL/I by /* and */.

https://www.bell-labs.com/usr/dmr/www/kbman.html

Note that this style of commenting was not present in
B's precursor language, BCPL.

It would be appropriate to qualify this statement with some kind
of timeframe as BCPL is still used (albeit not widely, I assume).

The PL/I style of commenting was not present in BCPL at the time B
was being defined. My source is MIT Project Mac Memorandum-M-352
dated July 21, 1967. I expect this document can be found on the
net but I don't have a link for it.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

David Brown wrote:

Why would you want your C code to look like Python? That's as silly as wanting your Python code to look like C code. The languages are significantly different - each with their strengths and weaknesses, and
each suitable for quite different kinds of programming tasks.

Wrong. C is the only general-purpose language worth using for anything.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
You miss all the shoes you don't take!

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 3/21/24 15:23, Keith Thompson wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

I'm sure he did. However, I'd like to mention that I have occasionally
used #ifdef with a macro name that I haven't #defined, and have no plans
to #define, but which describes the reason why I'm commenting this
section out. This is purely to document my reason, but should I ever
change my mind, I can simply #define the corresponding macro.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

On 3/21/24 15:23, Keith Thompson wrote:

Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]

And sometimes, when it's not a really a comment, but rather a block of
code I don't want right now:

#ifdef 0
...
#endif

I think you mean "#if 0".

I'm sure he did. However, I'd like to mention that I have occasionally
used #ifdef with a macro name that I haven't #defined, and have no plans
to #define, but which describes the reason why I'm commenting this
section out. This is purely to document my reason, but should I ever
change my mind, I can simply #define the corresponding macro.

Just to be clear, the problem with "#ifdef 0" is that 0 is not an
identifier.

main.c:1:8: error: macro names must be identifiers
1 | #ifdef 0
| ^

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: None to speak of (3:633/280.2@fidonet)

On 21/03/2024 06:19, Lawrence D'Oliveiro wrote:

The original comment delimiters in C were copied from PL/I: everything between “/*” and “*/” is a comment, even extending across multiple lines.
Pascal had something similar, only the delimiters were “{” and “}”, or
“(*” and “*)” for compatibility with machines with restricted character
sets.

For some reason, the Ada folks decided block comments were not a good
idea, and so their rule was that anything after “--” up to the end of the line was a comment. And C++ adopted a similar rule, using “//” as their to-end-of-line comment marker, though of course they also kept C-style
block comments. Java also keeps both these styles.

Since then, I’ve seen newer programmers gravitate towards the rest-of-line form in preference to the block form, and I’m not sure why. I’m fond of writing things like

/*
A very simple HTML/XML entity-escape function--why isn’t this
part of the standard Java API?
*/

which involve less typing than

//
// A very simple HTML/XML entity-escape function--why isn’t this
// part of the standard Java API?
//

Also, the “block” form allows “interspersed” comments, where a short comment can be put in the middle of a line and followed by more program
text in the rest of the line. For example, as a way of keeping long
argument lists straight:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame,
/*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx,
/*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

Do you feel the same?

I don't have strong views about this. Block comments occasionally used
to fail to match up, but with modern syntax highlighting, that is less
of an issue. It's also slightly more natural to use // comments when commenting every line of a structure. The, as yiu say, if you want
comments interspersed with code in the same it, it must be the old
style, but it's very rare for that to be useful.

However until recently it wasn't unknown for the // comments to break.
So you couldn't use them in serious, portable C programming. I think
that's no longer the case.
--
Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

In article <86edc2l7lw.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <86r0g3liii.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

The original comment delimiters in C were copied from PL/I: everything >>>>

Cite?

Seen in the B language manual:

Comments are delimited as in PL/I by /* and */.

https://www.bell-labs.com/usr/dmr/www/kbman.html

Note that this style of commenting was not present in
B's precursor language, BCPL.

It would be appropriate to qualify this statement with some kind
of timeframe as BCPL is still used (albeit not widely, I assume).

The PL/I style of commenting was not present in BCPL at the time B
was being defined.

Correct.

- Dan C.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: PANIX Public Access Internet and UNIX, NYC (3:633/280.2@fidonet)

On Fri, 22 Mar 2024 12:20:16 -0400, James Kuyper wrote:

... I have occasionally
used #ifdef with a macro name that I haven't #defined, and have no plans
to #define, but which describes the reason why I'm commenting this
section out.

I’ve seen that. E.g.

#ifdef USE_STUPID_CODE
.... do things one way ...
#else
.... do things the better way ...
#endif

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

On 21/03/2024 22:16, Lawrence D'Oliveiro wrote:

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame, /*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

I prefer to put the argument names at the end of the line.

But putting them in front of the values looks more like the syntax in
languages (like Ada and Python) that do allow specification of argument
keywords.

And maybe, in future, if it becomes valid in C (or some successor),
then updating the code should be as simple as removing the comment
symbols.

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a switch clicks off in your brain, and you are incapable of focussing on anything else that was said?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 3/22/2024 7:58 PM, Lawrence D'Oliveiro wrote:

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

On 21/03/2024 22:16, Lawrence D'Oliveiro wrote:

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

[...]

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a switch clicks off in your brain, and you are incapable of focussing on anything else that was said?

Notice the name of the group?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Fri, 22 Mar 2024 21:15:45 -0700, Chris M. Thomasson wrote:

On 3/22/2024 7:58 PM, Lawrence D'Oliveiro wrote:

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

On 21/03/2024 22:16, Lawrence D'Oliveiro wrote:

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame, /*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a >> switch clicks off in your brain, and you are incapable of focussing on
anything else that was said?

Notice the name of the group?

Notice the code I posted?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 23/03/2024 03:58, Lawrence D'Oliveiro wrote:

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

On 21/03/2024 22:16, Lawrence D'Oliveiro wrote:

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame, /*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

I prefer to put the argument names at the end of the line.

But putting them in front of the values looks more like the syntax in
languages (like Ada and Python) that do allow specification of argument
keywords.

And maybe, in future, if it becomes valid in C (or some successor),
then updating the code should be as simple as removing the comment
symbols.

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a switch clicks off in your brain, and you are incapable of focussing on anything else that was said?

No, I am quite happy with Python, and use it regularly. It is simply
that Python and C are very different languages, and I see no benefit in
trying to make one look like the other. (And I talked more about Python
than Ada because my knowledge of Ada is a lot more limited compared to
my knowledge and experience with Python - and I expect that pattern is
common amongst other people in c.l.c.)


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 23/03/2024 15:24, David Brown wrote:

On 23/03/2024 03:58, Lawrence D'Oliveiro wrote:

On Fri, 22 Mar 2024 10:02:47 +0100, David Brown wrote:

On 21/03/2024 22:16, Lawrence D'Oliveiro wrote:

On Thu, 21 Mar 2024 13:37:57 +0200, Mikko wrote:

On 2024-03-21 06:19:13 +0000, Lawrence D'Oliveiro said:

����� gdImageCopyResampled
������� (
��������� /*dst =*/ ResizedFrame,
��������� /*src =*/ Context.StillFrame, /*dstX =*/ 0,
��������� /*dstY =*/ 0,
��������� /*srcX =*/ 0,
��������� /*srcY =*/ 0,
��������� /*dstW =*/ ResizedFrame->sx, /*dstH =*/ ResizedFrame->sy, >>>>>> ��������� /*srcW =*/ Context.StillFrame->sx,
��������� /*srcH =*/ Context.StillFrame->sy
������� );

I prefer to put the argument names at the end of the line.

But putting them in front of the values looks more like the syntax in
languages (like Ada and Python) that do allow specification of argument >>>> keywords.

And maybe, in future, if it becomes valid in C (or some successor),
then updating the code should be as simple as removing the comment
symbols.

Why would you want your C code to look like Python?

Is “Python” some kind of trigger word with you? Soon as you see that, a >> switch clicks off in your brain, and you are incapable of focussing on
anything else that was said?

No, I am quite happy with Python, and use it regularly.� It is simply
that Python and C are very different languages, and I see no benefit in trying to make one look like the other.� (And I talked more about Python than Ada because my knowledge of Ada is a lot more limited compared to
my knowledge and experience with Python - and I expect that pattern is common amongst other people in c.l.c.)

But a block in Python is either exactly or to all intents and purposes
the same thing as a block in C or many other programming languages. And
we already have perfectly good syntax for that. So why mess about?
Similarly comments are exactly the same in every programming language,
though to be fair C is a bit of an outlier and hashes are more conventional.
--
Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 3/21/2024 2:19 AM, Lawrence D'Oliveiro wrote:

I’m fond of writing things like

/*
A very simple HTML/XML entity-escape function--why isn’t this
part of the standard Java API?
*/

which involve less typing than

//
// A very simple HTML/XML entity-escape function--why isn’t this
// part of the standard Java API?
//

Get yourself some Notepad++.

Highlight a block of comments and hit Ctrl + Q.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)

On 2024-03-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

Also, the “block” form allows “interspersed” comments, where a short comment can be put in the middle of a line and followed by more program
text in the rest of the line. For example, as a way of keeping long
argument lists straight:

gdImageCopyResampled
(
/*dst =*/ ResizedFrame,
/*src =*/ Context.StillFrame,
/*dstX =*/ 0,
/*dstY =*/ 0,
/*srcX =*/ 0,
/*srcY =*/ 0,
/*dstW =*/ ResizedFrame->sx,
/*dstH =*/ ResizedFrame->sy,
/*srcW =*/ Context.StillFrame->sx,
/*srcH =*/ Context.StillFrame->sy
);

Do you feel the same?

A normal person won't compulsively comment very function argument,
but if they had to do it, here is what it might look like:

gdImageCopyResampled(ResizedFrame, // dst
Context.StillFrame, // src
0, 0, 0, 0, // {dst,src}{X,Y}
ResizedFrame->sx, // dstW
ResizedFrame->sy, // dstH
Context.StillFrame->sx, // srcW
Context.StillFrame->sy); // srcH

gdImageCopyResampled(ResizedFrame, /* dst */
Context.StillFrame, /* src */
0, 0, 0, 0, /* {dst,src}{X,Y} */
ResizedFrame->sx, /* dstW */
ResizedFrame->sy, /* dstH */
Context.StillFrame->sx, /* srcW */
Context.StillFrame->sy); /* srcH */

Using either kind of comment, it goes at the end of the line, with a
decent amount of space. The reader of the code who doesn't find
the comments helpful can easily ignore them.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the comments.
Even then, it would usually only be a concern for API-type functions,
which means a fairly small share of a typical codebase.

The original post is kind of weird, though, in that its author's idea of
what it easy to type seems to be based on writing code out on a
typewriter. Maybe a Teletype without a C-savvy editor program.

Be well.
--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the
comments.

The discussion was about function arguments in a call. Documentation
would, presumably, be generated from comments on (formal) parameters in
a function declaration.

--
Ben.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the
comments.

The discussion was about function arguments in a call. Documentation
would, presumably, be generated from comments on (formal) parameters in
a function declaration.

Fair enough. I drifted too far.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2024-04-23, Lowell Gilbert <lgusenet@be-well.ilk.org> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

A normal person won't compulsively comment very function argument,

Well, they might if they're generating documentation from the comments.
Even then, it would usually only be a concern for API-type functions,
which means a fairly small share of a typical codebase.

I think here you're thinking more of formal parameters, rather than
argument expressions in calls.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Tue, 23 Apr 2024 16:13:34 -0400, DFS wrote:

On 3/21/2024 2:19 AM, Lawrence D'Oliveiro wrote:

I’m fond of writing things like

/*
A very simple HTML/XML entity-escape function--why isn’t this part
of the standard Java API?
*/

which involve less typing than

//
// A very simple HTML/XML entity-escape function--why isn’t this
// part of the standard Java API?
//

Get yourself some Notepad++.

Highlight a block of comments and hit Ctrl + Q.

Get an inferior piece of software, available only on an inferior platform, just to turn a comment style that I like into one I don’t like?

What next: you want me to give up my car for a rickshaw, and move to a
village on top of a cliff?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text editor like that.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
“You know what that means.” “No i don't.”

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Sjouke Burry wrote:

On 24.04.24 14:36, Blue-Maned_Hawk wrote:

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text
editor like that.

BULSHIT.
I run notepad++ on a 20 year old xp pro machine, and never had a
problem.

I don't see how that refutes my claim instead of substantiating it.



--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
Bribe^WLoan^WCompensation

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 4/24/2024 8:36 AM, Blue-Maned_Troll wrote:

DFS wrote:

Get yourself some Notepad++.

Not everybody can afford a machine powerful enough for a fancy text editor like that.

Notepad++ will run on $25 dumpster hardware.







--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)