I used a style similar to this in school. Before that I used much the same. As for existing code bases I prefer to keep their style and add comments accordingly. That generally goes for any language.
Popularity of a style shouldn't be a goal. It should be consistantly readable and documented. We must write for ourselves as well as our future self and others.
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
1. GNU Style
---------
#include <stddef.h>
#include <stdbool.h>
#include "malloc_internals.h"
struct malloc_chunk
{
struct malloc_chunk *next; /* The next chunk. */
struct malloc_chunk *prev; /* The previous chunk. */
bool is_free; /* Whether this chunk is usable. */
size_t size; /* The size of this chunk. */
};
Ar Rakin <rakinar2@onesoftnet.eu.org> wrote in news:vpkmq0$21php$1@dont- >email.me:
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
1. GNU Style
---------
#include <stddef.h>
#include <stdbool.h>
#include "malloc_internals.h"
struct malloc_chunk
{
struct malloc_chunk *next; /* The next chunk. */
struct malloc_chunk *prev; /* The previous chunk. */
bool is_free; /* Whether this chunk is usable. */
size_t size; /* The size of this chunk. */
};
I used a style similar to this in school. Before that I used much the same. >As for existing code bases I prefer to keep their style and add comments >accordingly. That generally goes for any language.
Popularity of a style shouldn't be a goal. It should be consistantly >readable and documented. We must write for ourselves as well as our future >self and others.
On 2/25/25 9:23 PM, David LaRue wrote:
I used a style similar to this in school. Before that I used much the same. >> As for existing code bases I prefer to keep their style and add comments
accordingly. That generally goes for any language.
Agreed. For existing projects, the code style should be preserved.
Popularity of a style shouldn't be a goal. It should be consistantly
readable and documented. We must write for ourselves as well as our future >> self and others.
This is true. I just wanted to know which style most people seem to prefer.
Thanks for your response!
Ar Rakin <rakinar2@onesoftnet.eu.org> writes:
On 2/25/25 9:23 PM, David LaRue wrote:
I used a style similar to this in school. Before that I used much the same.
As for existing code bases I prefer to keep their style and add comments >>> accordingly. That generally goes for any language.
Agreed. For existing projects, the code style should be preserved.
Popularity of a style shouldn't be a goal. It should be consistantly
readable and documented. We must write for ourselves as well as our future >>> self and others.
This is true. I just wanted to know which style most people seem to prefer. >>
Thanks for your response!
I prefer the AT&T style (which you call GNU style, but which actually predates Stallman).
The vi(1) editor has several commands that are designed to support
the AT*T (or more properly, Bell Labs) style, such as the '[['
and ']]' commands. Starting a function definition with
the function name in column 1 enables the use of the VI
/^main
command to easily move the cursor to the start of a named function.
On 2/25/25 9:23 PM, David LaRue wrote:
I used a style similar to this in school. Before that I used much the
same.
As for existing code bases I prefer to keep their style and add comments
accordingly. That generally goes for any language.
Agreed. For existing projects, the code style should be preserved.
Popularity of a style shouldn't be a goal. It should be consistantly
readable and documented. We must write for ourselves as well as our
future
self and others.
This is true. I just wanted to know which style most people seem to prefer.
And for your own code, don't be afraid to find a better way of writing
your code. You don't have to be restricted to a C standard that was replaced a generation ago. You don't have to limit yourself to code
that was designed to work well with computers, software and screens from
four decades ago.
Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
GNU Style for me.
<snip>
3. Other Styles?
BSD ? Not sure how different it is from Linux, but OpenBSD
has a detail write up in manual style(9):
https://man.openbsd.org/style
FWIW, people really should learn to use indent(1), will help
with many of these arguments :) For example:
GNU Style for use with BSD indent(1), File .indent.pro, but
BSD indent(1) may format it a bit different that GNU indent(1).
-i2
-bl
-lp
-nce
GNU Style for use with GNU indent(1), File .indent.pro
--gnu-style
--dont-format-comments
--no-space-after-function-call-names
--dont-break-procedure-type
--line-length78
--case-indentation2
Thank you.your welcome
Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
GNU Style for me.
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
3. Other Styles?
Thank you.your welcome
On 2025-02-25, John McCue <jmccue@reddwf.jmcunx.com> wrote:
Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
GNU Style for me.
OP didn't properly characterize GNU style.
GNU style is actually something like this:
if (flag)
{
switch (state)
{
case 42:
{
state = 73;
break;
}
}
}
else
{
statement;
}
Four space indentation, but braces half-indent by two spaces.
On 2/25/25 10:28 PM, David Brown wrote:
And for your own code, don't be afraid to find a better way of writing
your code. You don't have to be restricted to a C standard that was
replaced a generation ago. You don't have to limit yourself to code
that was designed to work well with computers, software and screens
from four decades ago.
I agree! The C projects that I have built use latest C features. I
usually always use the `-std=gnu17` or `-std=gnu23` compiler flag. (Yes,
I do use the GNU C extensions often.)
On 2025-02-25, John McCue <jmccue@reddwf.jmcunx.com> wrote:
Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
GNU Style for me.
OP didn't properly characterize GNU style.
GNU style is actually something like this:
if (flag)
{
switch (state)
{
case 42:
{
state = 73;
break;
}
}
}
else
{
statement;
}
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-02-25, John McCue <jmccue@reddwf.jmcunx.com> wrote:
Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Hello there,GNU Style for me.
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all >>>> about that question. Which one of the following do you prefer the most? >>>
OP didn't properly characterize GNU style.
GNU style is actually something like this:
if (flag)
{
switch (state)
{
case 42:
{
state = 73;
break;
}
}
}
else
{
statement;
}
Four space indentation, but braces half-indent by two spaces.
Which is one of the goofier styles I've seen. Although I don't recall
ever seeing it actually done that way, even in gnu code.
On 2025-02-25, Scott Lurndal <scott@slp53.sl.home> wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-02-25, John McCue <jmccue@reddwf.jmcunx.com> wrote:
Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Hello there,GNU Style for me.
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all >>>>> about that question. Which one of the following do you prefer the most? >>>>
OP didn't properly characterize GNU style.
GNU style is actually something like this:
if (flag)
{
switch (state)
{
case 42:
{
state = 73;
break;
}
}
}
else
{
statement;
}
Four space indentation, but braces half-indent by two spaces.
Which is one of the goofier styles I've seen. Although I don't recall
ever seeing it actually done that way, even in gnu code.
GNU code in official GNU projects is full of it. I picked this
file just now at random: hash.c in GNU Make:
https://git.savannah.gnu.org/cgit/make.git/tree/src/hash.c
Let's hit something else at random. How about GNU Emacs.
Being a Lisp guy, eval.c catches my eye:
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/eval.c
Goofy indents again.
GNU Bash, sig.c:
https://git.savannah.gnu.org/cgit/bash.git/tree/sig.c
Oh, look!
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
1. GNU Style
[...]
2. Linux Style
[...]
3. Other Styles?
[...]
Please show an example!
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
1. GNU Style
---------
#include <stddef.h>
#include <stdbool.h>
#include "malloc_internals.h"
struct malloc_chunk
{
struct malloc_chunk *next; /* The next chunk. */
struct malloc_chunk *prev; /* The previous chunk. */
bool is_free; /* Whether this chunk is usable. */
size_t size; /* The size of this chunk. */
};
static inline void *
get_chunk_ptr (struct malloc_chunk *chunk)
{
return (void *) (chunk + 1);
}
void *
malloc (size_t size)
{
struct malloc_chunk *chunk = mm_find_chunk (size, MM_CHUNK_FREE);
if (chunk)
return get_chunk_ptr (chunk);
chunk = mm_alloc_chunk (size);
if (!chunk)
return NULL;
return get_chunk_ptr (chunk);
}
---------
2. Linux Style
---------
#include <stddef.h>
#include <stdbool.h>
#include "malloc_internals.h"
struct malloc_chunk {
struct malloc_chunk *next; /* The next chunk. */
struct malloc_chunk *prev; /* The previous chunk. */
bool is_free; /* Whether this chunk is usable. */
size_t size; /* The size of this chunk. */
};
static inline void *get_chunk_ptr(struct malloc_chunk *chunk)
{
return (void *) (chunk + 1);
}
void *malloc(size_t size)
{
struct malloc_chunk *chunk = mm_find_chunk(size, MM_CHUNK_FREE);
if (chunk)
return get_chunk_ptr(chunk);
chunk = mm_alloc_chunk(size);
if (!chunk)
return NULL;
return get_chunk_ptr(chunk);
}
---------
3. Other Styles?
Please show an example!
Thank you.
Ar Rakin <rakinar2@onesoftnet.eu.org> writes:
On 2/25/25 9:23 PM, David LaRue wrote:
I used a style similar to this in school. Before that I used much the same.
As for existing code bases I prefer to keep their style and add comments >>> accordingly. That generally goes for any language.
Agreed. For existing projects, the code style should be preserved.
Popularity of a style shouldn't be a goal. It should be consistantly
readable and documented. We must write for ourselves as well as our future >>> self and others.
This is true. I just wanted to know which style most people seem to prefer. >>
Thanks for your response!
I prefer the AT&T style (which you call GNU style, but which actually predates Stallman).
The vi(1) editor has several commands that are designed to support
the AT*T (or more properly, Bell Labs) style, such as the '[['
and ']]' commands.
Starting a function definition with
the function name in column 1 enables the use of the VI
/^main
command to easily move the cursor to the start of a named function.
[...]
Yes - within reason. It is not good to be obsessive about coding style
- even within existing projects with lots of contributors, there can sometimes be good reasons for wavering from a common style.
[...]
[...]
There is no one style that has anything like a majority position,
especially not when you consider all the possible variations.
And even
if there was, picking a style due to popularity is as sane as picking a religion based on popularity.
[...]
Pick a tab size that suits /your/ preferences for coding, using tab characters or spaces for whatever works best with /your/ choice of tools.
[...]
Kaz Kylheku <643-408-1753@kylheku.com> writes:
OP didn't properly characterize GNU style.
GNU style is actually something like this:
[...]
Four space indentation, but braces half-indent by two spaces.
Which is one of the goofier styles I've seen. Although I don't recall
ever seeing it actually done that way, even in gnu code.
[...]
Which one of the following do you prefer the most?
On 25.02.2025 20:35, David Brown wrote:
[...]
Pick a tab size that suits /your/ preferences for coding, using tab
characters or spaces for whatever works best with /your/ choice of tools.
But only in your own projects. - Whenever you work in larger contexts
this shouldn't - any typically doesn't - apply any more.
On 26/02/2025 15:39, Bradley K. Sherman wrote:
Just do your best to keep it neat and under 80 columns.
Neat, yes. 80 columns, no - unless you are living in the previous century.
Lines that are too long are hard to read, but the idea that 80 columns
is a good number or should be a hard limit is /long/ outdated. About
100 - 120 columns is a better fit for a lot of code, letting you use
sensible identifiers without excessively splitting logical lines into multiple physical lines.
On Wed, 26 Feb 2025 13:39:12 +0100, Janis Papanagnou wrote:
There's reasons why folks stay with ("ancient") Emacs and Vi/Vim!
Emacs I can understand, vi/vim I can’t.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 26 Feb 2025 13:31:51 -0800, Keith Thompson wrote:
One interesting feature of Perl is that the braces are required.
And yet it doesn’t have C-style macros, which to me are the most obvious >> way one can get into trouble by omitting needed braces.
What do you mean? Sorry I'm stupid sometimes.
On 27/02/2025 12:56, Ar Rakin wrote:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example:
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
Interesting. Isn't this considered a compiler bug?
No. Line splicing occurs in Translation Phase 2. Comment removal doesn't happen until Translation Phase3. If a compiler /didn't/ splice those
lines, /that/ would be a bug.
On 2/27/25 8:16 PM, Scott Lurndal wrote:
Ar Rakin <rakinar2@onesoftnet.eu.org> writes:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example:
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
Interesting. Isn't this considered a compiler bug?
No, it is standard C line continuation behavior remaining from
the days of punched cards. More useful for strings
and invented prior to the invention of unterminated comments (//).
Understood.
Even though I have been writing C code for around four years now, I
still learn new things about this *simple* language every day.
On 27/02/2025 14:05, Ar Rakin wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 26 Feb 2025 13:31:51 -0800, Keith Thompson wrote:
One interesting feature of Perl is that the braces are required.
And yet it doesn’t have C-style macros, which to me are the most obvious >>> way one can get into trouble by omitting needed braces.
What do you mean? Sorry I'm stupid sometimes.
He is thinking of situations like this (ignore the stupidity of the
example) :
#define message(x) printf("Message: "); printf(x); printf("\n")
void foo(int y) {
message("Starting foo... ");
if (y < 0)
message("Y is negative");
message("Done foo.")
}
Reading "foo", you'd think that it would print "Message: Y is
negative\n" if y is negative. But in fact only the first statement in
the macro is covered by the conditional, and "Y is negative\n" will
always be printed. You can easily imagine how things could get a whole
lot worse from such mixups.
There are many ways to avoid this, including putting a "do { ... } while
(0)" wrapper around the statements in the macro, using an inline
function instead of a macro, writing macro names in all-caps as a
warning (I strongly dislike that convention), and always using braces
with conditionals even if they appear to cover just one statement.
I am not sure if there is a basis for judging the "most obvious" problem
that can occur from omitting braces in conditionals, but this is
certainly a strong contender for the title.
Another case that occurs is confusion about matching up else's with if's
in nested conditionals without braces.
On 27/02/2025 16:13, Ar Rakin wrote:
On 2/27/25 8:16 PM, Scott Lurndal wrote:
Ar Rakin <rakinar2@onesoftnet.eu.org> writes:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example:
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
Interesting. Isn't this considered a compiler bug?
No, it is standard C line continuation behavior remaining from
the days of punched cards. More useful for strings
and invented prior to the invention of unterminated comments (//).
Understood.
Even though I have been writing C code for around four years now, I
still learn new things about this *simple* language every day.
Like most quirks, as found in every language, you have to be very
unlucky to be hit by it, and extraordinarily unlucky to do so without it being immediately obvious when you compile your code or at least when
you try to run it. And it's peanuts to avoid triggering it once you
know about it - but most people can spend their entire careers as C programmers without ever coming across it.
These things can be inconvenient for people making C tools (compilers,
syntax highlighters, etc.), but are rarely a problem for C programmers.
David Brown <david.brown@hesbynett.no> writes:
On 26/02/2025 15:39, Bradley K. Sherman wrote:
Just do your best to keep it neat and under 80 columns.
Neat, yes. 80 columns, no - unless you are living in the previous century. >>
Lines that are too long are hard to read, but the idea that 80 columns
is a good number or should be a hard limit is /long/ outdated. About
100 - 120 columns is a better fit for a lot of code, letting you use
sensible identifiers without excessively splitting logical lines into
multiple physical lines.
Agreed. Unfortunately, most GNU projects still require you to not exceed
80 columns per line, in the code. It is a bit too hard limit.
On 27/02/2025 16:33, David Brown wrote:
On 27/02/2025 16:13, Ar Rakin wrote:
On 2/27/25 8:16 PM, Scott Lurndal wrote:
Ar Rakin <rakinar2@onesoftnet.eu.org> writes:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example: >>>>>>
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
Interesting. Isn't this considered a compiler bug?
No, it is standard C line continuation behavior remaining from
the days of punched cards. More useful for strings
and invented prior to the invention of unterminated comments (//).
Understood.
Even though I have been writing C code for around four years now, I
still learn new things about this *simple* language every day.
Like most quirks, as found in every language, you have to be very
unlucky to be hit by it, and extraordinarily unlucky to do so without
it being immediately obvious when you compile your code or at least
when you try to run it. And it's peanuts to avoid triggering it once
you know about it - but most people can spend their entire careers as
C programmers without ever coming across it.
These things can be inconvenient for people making C tools (compilers,
syntax highlighters, etc.), but are rarely a problem for C programmers.
Problems involving \ and // commonly come up with multi-line macros.
Problems involving \ and // commonly come up with multi-line macros.
Newspaper columns are often much shorter - 30 to 40 characters. So why
is that?
On 27/02/2025 15:13, Richard Heathfield wrote:
On 27/02/2025 12:56, Ar Rakin wrote:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example:
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
Interesting. Isn't this considered a compiler bug?
No. Line splicing occurs in Translation Phase 2. Comment removal doesn't
happen until Translation Phase3. If a compiler /didn't/ splice those
lines, /that/ would be a bug.
The bug, of course, is using Windows and Windows-style paths :-)
(Nice to have you back, Richard.)
David Brown <david.brown@hesbynett.no> wrote at 16:26 this Thursday (GMT):
What's worse, its a WONTFIX!lines, /that/ would be a bug.The bug, of course, is using Windows and Windows-style paths :-)
On 27.02.2025 10:15, Lawrence D'Oliveiro wrote:
On Thu, 27 Feb 2025 09:38:40 +0100, Janis Papanagnou wrote:
Too deep indenting I consider to be a possible bad structuring
effect ...
Would you consider half a dozen indentation levels to be too many? I
frequently go that deep.
To be honest, I've never counted them. So why should I suggest someone
else what's a "good" value. Programmers certainly should have got (or develop) a feeling about what's acceptable and what's too much in their
own playground (or in project contexts where many people cooperate).
But since you were asking I got curious; I pick one recent "C" source
from one of my toy projects and get this distribution of the amount of indents
80 - // empty lines
169 0
254 1
172 2
122 3
46 4
34 5
7 6
3 7
What would be your typical indent distribution in your "C" source code?
On Thu, 27 Feb 2025 09:38:40 +0100, Janis Papanagnou wrote:
Too deep indenting I consider to be a possible bad structuring
effect ...
Would you consider half a dozen indentation levels to be too many? I frequently go that deep.
On 27/02/2025 06:57, Janis Papanagnou wrote:[...]
On 26.02.2025 20:56, David Brown wrote:
On 26/02/2025 18:13, Janis Papanagnou wrote:
On 26.02.2025 17:32, David Brown wrote:
On 26/02/2025 15:39, Bradley K. Sherman wrote:
Just do your best to keep it neat and under 80 columns.
Since decades now there are no such hard limits, so why do you make
up such a statement.
That's exactly the point - there /are/ no real hard limits, and have not
been any since we moved on from pure text-mode terminals. Some
situations have short line limits (such as for a slideshow in a presentation), most situations for normal coding can be as wide as the developer finds convenient.
So why do some people think that 80 columns should be a hard limit to
their line length? They do not, for the most part, think 80 characters
is ideal for readability, or for display, or for printing, or for
writing code, or for reviewing it, or for any other use. For the most
part, they don't think at all. They simply regurgitate 80 columns
because IBM picked 80 columns as the width of punched cards in 1928. If
IBM had picked 72 columns or 96 columns, Bradley would have written
"Just do your best to keep it neat and under 72 columns" or "Just do
your best to keep it neat and under 96 columns".
[...]
In newspapers you can find articles that can span even a whole page.
It's nonetheless organized in small columns.
Of course different newspapers do things differently.
And maybe there are other reasons for having columns that are often far
too narrow for legibility, sometimes leading to horrible inconsistent spacing, really messy hyphenation, and the like.
Columns are clearly required for newspapers - the pages are (usually)
far too wide to be comfortable to read without splitting up into
columns. The question is what width they should be.
Generally, around 60 - 70 characters is common for quick, easy reading,
such as most books. Technical documents can have a good deal more - a
quick check suggests that the C standards have around 90 characters per
line, while the C++ standards (with a smaller typeface) have about 105.
A technical white paper that I happen to have open at the moment has 120 character lines.
Newspaper columns are often much shorter - 30 to 40 characters. So why
is that?
The prime purpose of a newspaper is, obviously, to make money. The more
you put in the same area, the better. Having regular column sizes
reduces costs (especially before computer-based layout and printing). It makes it easier to sell advertising space.
Modern newspapers can be more flexible in their layouts, but keeping a familiar look is important. Legibility of individual columns of text is
much less important - after all, most readers scan headlines and only
read a small proportion of the column text.
These numbers appear strange to me. - A quick look into a couple of
different editions show more like 45-90 characters, with typical
values around 55-70 (including spaces counted as characters), i.e.
not in the extreme ranges. For these numbers I've inspected random
books written in different layouts, in three different languages,
and of different types. - I would be very astonished if that would
be fundamentally different in your language domain, but YMMV.
What did you actually look at? Novels? Textbooks? Documents written
for A4 page sizes? Newspapers? Old legal documents?
So I have to conclude that printed typical text would fit regularly
and easily in an 80 column mono-spaced medium.
Your conclusion would be wrong, unless you are limiting it to specific
areas. (The word "typical" is very vague.)
It's not about "small screens"; it's about readability as being a
function of the used line-length. But readability, while probably
a most important factor, is not the only aspect...
I agree that readability is key here. But remember that readability of
code is not the same thing as readability of prose.
Doing too much in
one line of code makes it hard to understand - regardless of how many characters it actually uses.
Taking something that is logically one
operation or expression and artificially splitting it into two (or more) lines to suit an arbitrary line length limit also makes the code hard to understand. [...]
Myself I usually operate on a minimum of two physical screens, and
(with my font setting) each one capable of displaying two 80-column
windows side by side.
That seems small to me.
I have no problem with two approximately
120-column windows side-by-side in my IDE,
along with all the additional
junk - file lists, code outlines, line numbers, scroll bars, etc.
Sometimes I will have three files side-by-side, with a bit less space
for the junk, depending on what I am doing. (I usually have other stuff
like command windows, serial terminals, webpages, documents, etc., on
the other screens.)
[...]
Sure. I do the same, for the same reasons. But I don't restrict myself
to so short line lengths. (Of course most of the lines in my code are shorter than 80 characters.)
On 2025-02-28, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
David Brown <david.brown@hesbynett.no> wrote at 16:26 this Thursday (GMT): >>>> lines, /that/ would be a bug.
What's worse, its a WONTFIX!The bug, of course, is using Windows and Windows-style paths :-)
Not sure what you're talking about. All Microsoft operating systems
going back to MS-DOS have accepted the forward slash as an alternative
path separator. C:/Windows/System32 is a legitimate Windows-style path.
Some incorrectly-written user space programs might not like it.
On 28/02/2025 07:50, Janis Papanagnou wrote:
On 27.02.2025 10:15, Lawrence D'Oliveiro wrote:
On Thu, 27 Feb 2025 09:38:40 +0100, Janis Papanagnou wrote:
Too deep indenting I consider to be a possible bad structuring
effect ...
Would you consider half a dozen indentation levels to be too many? I
frequently go that deep.
To be honest, I've never counted them. So why should I suggest someone
else what's a "good" value. Programmers certainly should have got (or
develop) a feeling about what's acceptable and what's too much in their
own playground (or in project contexts where many people cooperate).
But since you were asking I got curious; I pick one recent "C" source
from one of my toy projects and get this distribution of the amount of
indents
80 - // empty lines
169 0
254 1
172 2
122 3
46 4
34 5
7 6
3 7
What would be your typical indent distribution in your "C" source code?
I looked at around 100 KLOC and was surprised to find that my modal
indent count was 3, which is lower than I expected.
On the other hand, I maxed out at 24.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 27/02/2025 12:56, Ar Rakin wrote:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example:Interesting. Isn't this considered a compiler bug?
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
No. Line splicing occurs in Translation Phase 2. Comment removal
doesn't happen until Translation Phase3. If a compiler /didn't/ splice
those lines, /that/ would be a bug.
<OT>Long time no see. Welcome back!</OT>
[...]
Well, in the GNU style, function definitions are still different than
other styles which I like:
int
main(int argc, char **argv)
{
printf ("Hello world\n");
return 0;
}
Plus, you can also see how there is a *space* before the open
parenthesis of function call expressions.
Many people argue that this is not a good idea, but I like it.
On 28.02.2025 09:55, Richard Heathfield wrote:<snip>
On the other hand, I maxed out at 24.
It would be interesting to get to know what sort of code-lines
or what sort of code-structure these extreme values stem from.
On 27/02/2025 22:24, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 27/02/2025 12:56, Ar Rakin wrote:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), forInteresting. Isn't this considered a compiler bug?
example:
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
No. Line splicing occurs in Translation Phase 2. Comment removal
doesn't happen until Translation Phase3. If a compiler
/didn't/ splice
those lines, /that/ would be a bug.
<OT>Long time no see. Welcome back!</OT>
As long as it's not "Long time no C" :-)
On 28/02/2025 09:22, David Brown wrote:
On 27/02/2025 22:24, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 27/02/2025 12:56, Ar Rakin wrote:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example: >>>>>>Interesting. Isn't this considered a compiler bug?
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
No. Line splicing occurs in Translation Phase 2. Comment removal
doesn't happen until Translation Phase3. If a compiler /didn't/ splice >>>> those lines, /that/ would be a bug.
<OT>Long time no see. Welcome back!</OT>
As long as it's not "Long time no C" :-)
I'm afraid it is. Nowadays I spend most of my time arguing with \LaTeX, although when I do cut code it is in C (and that's proper C, of course,
not this newfangled gibberish).
On 27.02.2025 16:47, David Brown wrote:
On 27/02/2025 06:57, Janis Papanagnou wrote:
On 26.02.2025 20:56, David Brown wrote:
On 26/02/2025 18:13, Janis Papanagnou wrote:
Doing too much in
one line of code makes it hard to understand - regardless of how many
characters it actually uses.
I think we should abandon speaking about it in terms of characters.
(I think we agreed that readability is the key, not a hard or soft
column limit; typically used number of columns are nonetheless based
on cultural - you may say also technical; still based on cultural -
sensible heuristics. But habits seem to run out of control "lately".)
Taking something that is logically one
operation or expression and artificially splitting it into two (or more)
lines to suit an arbitrary line length limit also makes the code hard to
understand. [...]
This may be the case or not. - That's the whole point; to organize the
code to become clear. - A split may make it even better readable. (But
a _misplaced_ split may make it worse.)
Is that split in your opinion reducing readability...?
if (sscanf (mutations, "r:%u,g:%u,a:%u,d:%u",
&mutation_rates.base,
&mutation_rates.genesis,
&mutation_rates.aging,
&mutation_rates.death
) != 4)
or would you prefer it for (better?) readability to be in one line?
Myself I usually operate on a minimum of two physical screens, and
(with my font setting) each one capable of displaying two 80-column
windows side by side.
That seems small to me.
Do you mean my screen or my default window size setting?
I cannot help; I'm used to the two 24" screens that I have, and my age
and health does not allow to regularly use font's below 10pt (or so).
I have no problem with two approximately
120-column windows side-by-side in my IDE,
This actually explains your preferences; elsethread I wrote about my observations of people using larger defaults for window sizes, and specifically that I've observed IDE users to work with larger default
window sizes also regularly don't mind writing code with (even much)
longer lines.
(Given what you write here my guess is that our habits actually don't
differ too much. And I think also our reasoning is not too different
in principle, if I've read your post correctly. - Our differences are probably only in our observation, experiences, opinions, hypotheses, concerning the historic or cultural background.)
On 28/02/2025 09:22, David Brown wrote:
As long as it's not "Long time no C" :-)
I'm afraid it is. Nowadays I spend most of my time arguing with
\LaTeX, although when I do cut code it is in C (and that's proper
C, of course, not this newfangled gibberish).
On 28/02/2025 10:00, Janis Papanagnou wrote:
On 27.02.2025 16:47, David Brown wrote:
On 27/02/2025 06:57, Janis Papanagnou wrote:
On 26.02.2025 20:56, David Brown wrote:
On 26/02/2025 18:13, Janis Papanagnou wrote:
(I'm snipping part of this - I don't think it is really going anywhere,
and certainly not anywhere topical for the group!)
Doing too much in
one line of code makes it hard to understand - regardless of how many
characters it actually uses.
I think we should abandon speaking about it in terms of characters.
Agreed.
(I think we agreed that readability is the key, not a hard or soft
column limit; typically used number of columns are nonetheless based
on cultural - you may say also technical; still based on cultural -
sensible heuristics. But habits seem to run out of control "lately".)
Yes.
Taking something that is logically one
operation or expression and artificially splitting it into two (or more) >>> lines to suit an arbitrary line length limit also makes the code hard to >>> understand. [...]
This may be the case or not. - That's the whole point; to organize the
code to become clear. - A split may make it even better readable. (But
a _misplaced_ split may make it worse.)
Sure. It is the "artificial" splitting merely to fit some line length
rule that is the problem, not splitting in itself.
Is that split in your opinion reducing readability...?
if (sscanf (mutations, "r:%u,g:%u,a:%u,d:%u",
&mutation_rates.base,
&mutation_rates.genesis,
&mutation_rates.aging,
&mutation_rates.death
) != 4)
or would you prefer it for (better?) readability to be in one line?
Splitting is fine here - it is natural and fits the flow of the code.
I might prefer to write it as :
const int matches = sscanf (mutations, "r:%u,g:%u,a:%u,d:%u",
&mutation_rates.base,
&mutation_rates.genesis,
&mutation_rates.aging,
&mutation_rates.death
);
if (matches != 4) {
since the "!= 4" bit looks a bit lonely and out of place in your code.
But that is perhaps just splitting hairs :-)
Myself I usually operate on a minimum of two physical screens, and
(with my font setting) each one capable of displaying two 80-column
windows side by side.
That seems small to me.
Do you mean my screen or my default window size setting?
I cannot help; I'm used to the two 24" screens that I have, and my age
and health does not allow to regularly use font's below 10pt (or so).
I also have two 24" screens (on this computer), and my eyes are also not
as good as they used to be. (In my youth, I used to write my notes on
2mm graph paper - normal lined paper seemed a waste of space to me.)
I have no problem with two approximately
120-column windows side-by-side in my IDE,
This actually explains your preferences; elsethread I wrote about my
observations of people using larger defaults for window sizes, and
specifically that I've observed IDE users to work with larger default
window sizes also regularly don't mind writing code with (even much)
longer lines.
I don't go overboard on line length, but I do like to have more room
than 80 characters, and I don't like hard limits. One factor in this is that a fair bit of my development is in C++ (on small embedded systems),
and namespaces and classes mean that the average full identifier length
is a fair amount longer than in C - thus it is natural for lines to be longer.
On 27/02/2025 15:47, David Brown wrote:
Newspaper columns are often much shorter - 30 to 40 characters. So
why is that?
Because newspapers are basically in portrait format, so long thin
columns fit well.
Computer terminals, back in the day, were basically square,
so 80
columns was often a hard limit.
Now you have larger landscape screens, with windows that can be
stretched as wide as you like.
On 27.02.2025 14:02, Ar Rakin wrote:
[...]
Well, in the GNU style, function definitions are still different than
other styles which I like:
int
main(int argc, char **argv)
{
printf ("Hello world\n");
return 0;
}
Plus, you can also see how there is a *space* before the open
parenthesis of function call expressions.
A space in a function call, but no space in the main() definition?
(In Awk, BTW, because of its primitive syntax, you may not place
spaces in user-defined function calls, but may use spacing in the
function definition. - But in "C" you may do as you prefer.)
Many people argue that this is not a good idea, but I like it.
Just avoid these "many people"! :-)
David Brown <david.brown@hesbynett.no> wrote at 16:26 this Thursday (GMT):
On 27/02/2025 15:13, Richard Heathfield wrote:
On 27/02/2025 12:56, Ar Rakin wrote:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), for example:
fopen(file,"rb"); // open file in \windows\system32\
fread(...);
Here, the // line continues onto the next, so that the fread is
commented out. But they are fewer.
Interesting. Isn't this considered a compiler bug?
No. Line splicing occurs in Translation Phase 2. Comment removal doesn't >>> happen until Translation Phase3. If a compiler /didn't/ splice those
lines, /that/ would be a bug.
The bug, of course, is using Windows and Windows-style paths :-)
(Nice to have you back, Richard.)
What's worse, its a WONTFIX!
On 2025-02-28, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
David Brown <david.brown@hesbynett.no> wrote at 16:26 this Thursday
(GMT):
What's worse, its a WONTFIX!lines, /that/ would be a bug.The bug, of course, is using Windows and Windows-style paths :-)
Not sure what you're talking about. All Microsoft operating systems
going back to MS-DOS have accepted the forward slash as an alternative
path separator. C:/Windows/System32 is a legitimate Windows-style
path. Some incorrectly-written user space programs might not like it.
On 28/02/2025 09:21, Janis Papanagnou wrote:
On 28.02.2025 09:55, Richard Heathfield wrote:<snip>
On the other hand, I maxed out at 24.
It would be interesting to get to know what sort of code-lines
or what sort of code-structure these extreme values stem from.
I thought so too, so I looked, and of course it's not as interesting as
we might have hoped.
I'm not allowed to post the code here, but I can paraphrase:
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
On 28/02/2025 09:21, Janis Papanagnou wrote:
On 28.02.2025 09:55, Richard Heathfield wrote:<snip>
On the other hand, I maxed out at 24.
It would be interesting to get to know what sort of code-lines
or what sort of code-structure these extreme values stem from.
I thought so too, so I looked, and of course it's not as interesting as
we might have hoped.
I'm not allowed to post the code here, but I can paraphrase:
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
<sigh>
On 28/02/2025 11:54, David Brown wrote:
I don't go overboard on line length, but I do like to have more room
than 80 characters, and I don't like hard limits. One factor in this
is that a fair bit of my development is in C++ (on small embedded
systems), and namespaces and classes mean that the average full
identifier length is a fair amount longer than in C - thus it is
natural for lines to be longer.
Have your mental margin-bell ding at around 75 characters, and aim to
thow a new line as soon a you can?
On 28/02/2025 10:19, Richard Heathfield wrote:
On 28/02/2025 09:21, Janis Papanagnou wrote:
On 28.02.2025 09:55, Richard Heathfield wrote:<snip>
On the other hand, I maxed out at 24.
It would be interesting to get to know what sort of code-lines
or what sort of code-structure these extreme values stem from.
I thought so too, so I looked, and of course it's not as interesting
as we might have hoped.
I'm not allowed to post the code here, but I can paraphrase:
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
<sigh>
I think I'd go with this:
value = really_quite_extremely_long_function_name(
arg1,
arg2,
arg3,
arg4);
Since the args would then also line up with a similar call but where the function name is a different length:
value2 = a_somewhat_shorter_function_name(
arg1,
arg2,
arg3,
arg4);
That's assuming it is still not viable to have them all on the same line.
On 28/02/2025 10:19, Richard Heathfield wrote:
On 28/02/2025 09:21, Janis Papanagnou wrote:
On 28.02.2025 09:55, Richard Heathfield wrote:<snip>
On the other hand, I maxed out at 24.
It would be interesting to get to know what sort of code-lines
or what sort of code-structure these extreme values stem from.
I thought so too, so I looked, and of course it's not as
interesting as we might have hoped.
I'm not allowed to post the code here, but I can paraphrase:
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
<sigh>
I think I'd go with this:
value = really_quite_extremely_long_function_name(
arg1,
arg2,
arg3,
arg4);
Since the args would then also line up with a similar call but where
the function name is a different length:
value2 = a_somewhat_shorter_function_name(
arg1,
arg2,
arg3,
arg4);
That's assuming it is still not viable to have them all on the same
line.
On Thu, 27 Feb 2025 17:27:17 +0000, bart wrote:
Problems involving \ and // commonly come up with multi-line macros.
C macros are yet another example of the wrong way to do macros.
The only right way to do macros is at the AST level.
Think how many problems would be solved if you could do gensym in a C
macro.
On 28/02/2025 05:29, Kaz Kylheku wrote:
On 2025-02-28, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
David Brown <david.brown@hesbynett.no> wrote at 16:26 this Thursday (GMT): >>>>> lines, /that/ would be a bug.
What's worse, its a WONTFIX!The bug, of course, is using Windows and Windows-style paths :-)
Not sure what you're talking about. All Microsoft operating systems
going back to MS-DOS have accepted the forward slash as an alternative
path separator. C:/Windows/System32 is a legitimate Windows-style path.
Yes, you can often use forward slashes for directory separations in
Windows - but you can't do so everywhere. There's no doubt that forward slashes are the standard in the Windows world.
Some incorrectly-written user space programs might not like it.
Indeed - and that can be a pain.
However, you can certainly use forward slashes in things like #include directives when using gcc on Windows, or in makefiles - and that covers
a lot of my needs for path names!
David Brown <david.brown@hesbynett.no> wrote at 09:21 this Friday (GMT):
On 28/02/2025 05:29, Kaz Kylheku wrote:
On 2025-02-28, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
David Brown <david.brown@hesbynett.no> wrote at 16:26 this Thursday (GMT): >>>>>> lines, /that/ would be a bug.
What's worse, its a WONTFIX!The bug, of course, is using Windows and Windows-style paths :-)
Not sure what you're talking about. All Microsoft operating systems
going back to MS-DOS have accepted the forward slash as an alternative
path separator. C:/Windows/System32 is a legitimate Windows-style path.
Yes, you can often use forward slashes for directory separations in
Windows - but you can't do so everywhere. There's no doubt that forward
slashes are the standard in the Windows world.
And, it's obviously the default for most paths.
Some incorrectly-written user space programs might not like it.
Indeed - and that can be a pain.
However, you can certainly use forward slashes in things like #include
directives when using gcc on Windows, or in makefiles - and that covers
a lot of my needs for path names!
Probably because gcc isn't made by MS.
On 28/02/2025 09:21, Janis Papanagnou wrote:
On 28.02.2025 09:55, Richard Heathfield wrote:<snip>
On the other hand, I maxed out at 24.
It would be interesting to get to know what sort of code-lines
or what sort of code-structure these extreme values stem from.
I thought so too, so I looked, and of course it's not as
interesting as we might have hoped.
I'm not allowed to post the code here, but I can paraphrase:
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
When format string is longer I put it on the separate line as well.
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
Have your mental margin-bell ding at around 75 characters ...
My impression is that even in early days 5:4 was more common than
square.
For many years I use 1200x1920 (yes, portait) as my main monitor at
work.
... (and that's proper C, of course, not this newfangled gibberish).
Would you say that the Rust compiler's implementation is *close* to what
you expect?
The Rust compiler processes macros during tokenization ...
On Fri, 28 Feb 2025 10:24:19 +0000, Richard Heathfield wrote:
... (and that's proper C, of course, not this newfangled gibberish).
Do you think it was a bad idea when struct field names went from
inhabiting a single common name space to each struct having their own?
C90 porridge tastes just fine to me.
On Fri, 28 Feb 2025 22:15:31 +0000, Richard Heathfield wrote:
C90 porridge tastes just fine to me.
Come on, C99 at least.
On Fri, 28 Feb 2025 12:21:01 +0000, Richard Harnden wrote:
Have your mental margin-bell ding at around 75 characters ...
What was the ding for? Was it because typists were not in the habit of looking at what they were typing?
On 28/02/2025 21:10, Lawrence D'Oliveiro wrote:
On Fri, 28 Feb 2025 12:21:01 +0000, Richard Harnden wrote:
Have your mental margin-bell ding at around 75 characters ...
What was the ding for? Was it because typists were not in the
habit of
looking at what they were typing?
Exactly. They didn't need to look at what they were typing,
because they could touch-type. It's why the F and J keys have
the little bumps - so you'd know where you were. They'd be
looking only at what they where copying, so the audible cue was
necessary. They could hit 90+ words per minute.
Very impressive, but not a skill a programmer needs.
On 28/02/2025 21:10, Lawrence D'Oliveiro wrote:
On Fri, 28 Feb 2025 12:21:01 +0000, Richard Harnden wrote:
Have your mental margin-bell ding at around 75 characters ...
What was the ding for? Was it because typists were not in the habit of
looking at what they were typing?
They didn't need to look at what they were typing, because
they could touch-type.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 28/02/2025 23:32, Richard Harnden wrote:
On 28/02/2025 21:10, Lawrence D'Oliveiro wrote:
On Fri, 28 Feb 2025 12:21:01 +0000, Richard Harnden wrote:Exactly. They didn't need to look at what they were typing, because
Have your mental margin-bell ding at around 75 characters ...
What was the ding for? Was it because typists were not in the habit
of
looking at what they were typing?
they could touch-type. It's why the F and J keys have the little
bumps - so you'd know where you were. They'd be looking only at
what they where copying, so the audible cue was necessary. They
could hit 90+ words per minute.
Very impressive, but not a skill a programmer needs.
MMMV.
You do you, obviously, but touch-typing can easily double your typing
speed. It never ceases to amaze me that the NHS claims their doctors
are overworked but can't be arsed to teach them to touch-type.
I suspect two different points are being made. Touch-typing without
looking at the keyboard is important for programmers. Touch-typing
without looking at the text being typed is less so.
On 28/02/2025 22:38, Lawrence D'Oliveiro wrote:
On Fri, 28 Feb 2025 22:15:31 +0000, Richard Heathfield wrote:
C90 porridge tastes just fine to me.
Come on, C99 at least.
Clean up your own backyard ...
Splitting is fine here - it is natural and fits the flow of the code.
[...]
But that is perhaps just splitting hairs :-)
I also have two 24" screens (on this computer), and my eyes are also not
as good as they used to be. (In my youth, I used to write my notes on
2mm graph paper - normal lined paper seemed a waste of space to me.)
On Fri, 28 Feb 2025 23:21:47 +0000, Richard Heathfield wrote:
On 28/02/2025 22:38, Lawrence D'Oliveiro wrote:
On Fri, 28 Feb 2025 22:15:31 +0000, Richard Heathfield wrote:
C90 porridge tastes just fine to me.
Come on, C99 at least.
Clean up your own backyard ...
Been there, done that. I practise what I preach.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 28/02/2025 23:32, Richard Harnden wrote:
On 28/02/2025 21:10, Lawrence D'Oliveiro wrote:
On Fri, 28 Feb 2025 12:21:01 +0000, Richard Harnden wrote:Exactly. They didn't need to look at what they were typing, because
Have your mental margin-bell ding at around 75 characters ...
What was the ding for? Was it because typists were not in the habit
of
looking at what they were typing?
they could touch-type. It's why the F and J keys have the little
bumps - so you'd know where you were. They'd be looking only at
what they where copying, so the audible cue was necessary. They
could hit 90+ words per minute.
Very impressive, but not a skill a programmer needs.
MMMV.
You do you, obviously, but touch-typing can easily double your typing
speed. It never ceases to amaze me that the NHS claims their doctors
are overworked but can't be arsed to teach them to touch-type.
I suspect two different points are being made. Touch-typing without
looking at the keyboard is important for programmers. Touch-typing
without looking at the text being typed is less so.
On Fri, 28 Feb 2025 10:19:49 +0000, Richard Heathfield wrote:
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
confection = prepare_carefully_according_to_detailed_recipe
(
/*pan =*/ flat,
/*line_with =*/ clarified_butter,
/*filling =*/ something_yummy,
/*cover_with =*/ lotsa_pastry,
/*bake_for =*/ 90 * MINUTES
);
You tend to your business, I'll tend to mine.
On 28/02/2025 22:08, Lawrence D'Oliveiro wrote:
On Fri, 28 Feb 2025 10:19:49 +0000, Richard Heathfield wrote:
value = really_quite_extremely_long_function_name(arg1,
arg2,
arg3,
arg4);
confection = prepare_carefully_according_to_detailed_recipe
(
/*pan =*/ flat,
/*line_with =*/ clarified_butter,
/*filling =*/ something_yummy,
/*cover_with =*/ lotsa_pastry,
/*bake_for =*/ 90 * MINUTES
);
I get the impression that you work alone.
On Sat, 1 Mar 2025 06:17:25 +0000, Richard Heathfield wrote:
You tend to your business, I'll tend to mine.
Next time, be more careful about using phrases like “newfangled gibberish”
in public.
My guess is that this form is just an informal syntax mimicking Perl's function parameter passing ...
On 01/03/2025 20:25, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 06:17:25 +0000, Richard Heathfield wrote:
You tend to your business, I'll tend to mine.
Next time, be more careful about using phrases like “newfangled
gibberish” in public.
I hope you're not implying I used the phrase carelessly.
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's
function parameter passing ...
The idea of passing arguments by keyword predates Perl.
If I wanted to annotate arguments with parameter names, I'd probably use aligned // comments with the name at the end of the line:
confection = prepare_carefully_according_to_detailed_recipe(
flat, // pan
clarified_butter, // line_with
something_yummy, // filling
lotsa_pastry, // cover_with
90 * MINUTES // bake_for
);
On Fri, 28 Feb 2025 10:24:19 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 28/02/2025 09:22, David Brown wrote:
As long as it's not "Long time no C" :-)
I'm afraid it is. Nowadays I spend most of my time arguing with
\LaTeX, although when I do cut code it is in C (and that's proper
C, of course, not this newfangled gibberish).
one man's newfangled gibberish is another man's proper C
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking
Perl's function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
For example, it exists in Ada since 1983. [...]
On 27/02/2025 12:56, Ar Rakin wrote:
[concerning line splicing with \ at end of line]
Then line-splicing, which combines two lines if the first ends
with \, is done before processing // comments.
I am aware that you can do the same thing with strings like this:
fprintf(stderr, "multi\
line\
strings\
are fun.");
I can understand how this might be useful; but with *comments*??
Was that actually a thing in the official C standards?
It's isn't that useful for strings; the following is simpler and
also works:
"multi"
"line"
"string"
But it is needed for multi-line macros, as C's proprocessor is
strictly line-oriented and a macro definition must fit onto one
line.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's >>>> function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
For example, it exists in Ada since 1983. [...]
The syntax is IMHO much nicer than using /*...*/ comments in C.
[...]
Perl doesn't have keyword arguments as a language feature, but it can be mimicked by passing hash or hash reference.
If I wanted to annotate arguments with parameter names, I'd probably use aligned // comments with the name at the end of the line:
confection = prepare_carefully_according_to_detailed_recipe(
flat, // pan
clarified_butter, // line_with
something_yummy, // filling
lotsa_pastry, // cover_with
90 * MINUTES // bake_for
);
In practice, I seldom do so unless there's direct language support.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-02-26, Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Sorry, I should have showed this difference in my original post.
I like the GNU style except the weird indentation before the
braces of control statements. Not sure why they choose to indent
that way.
The GNU style without indent before braces looks nice to me.
Without the weird brace indent, it has nothing to do with GNU any
more; it's just two-space indentation, where opening braces are on
their own line instead of being "cuddled" into the previous line,
which is very common:
if (flag)
{
switch (state)
{
case 42:
{
state = 73;
break;
}
}
}
else
{
statement;
}
There's so much vertical space wasted in that, however.
if (flag && (state == 42)) state = 73;
else statement;
[using // instead of /* ... */ to comment out lines of code]
I disagree with this. A line of code should never be commented
out; simply removed if not necessary.
On Fri, 28 Feb 2025 10:24:19 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 28/02/2025 09:22, David Brown wrote:
As long as it's not "Long time no C" :-)
I'm afraid it is. Nowadays I spend most of my time arguing with
\LaTeX, although when I do cut code it is in C (and that's proper
C, of course, not this newfangled gibberish).
one man's newfangled gibberish is another man's proper C
On 28/02/2025 11:24, Richard Heathfield wrote:
On 28/02/2025 09:22, David Brown wrote:
On 27/02/2025 22:24, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 27/02/2025 12:56, Ar Rakin wrote:
bart <bc@freeuk.com> writes:
// isn't devoid of quirks (this is still C after all), forInteresting. Isn't this considered a compiler bug?
example:
fopen(file,"rb"); // open file in \windows\system32\ >>>>>>> fread(...);
Here, the // line continues onto the next, so that the
fread is
commented out. But they are fewer.
No. Line splicing occurs in Translation Phase 2. Comment
removal
doesn't happen until Translation Phase3. If a compiler
/didn't/ splice
those lines, /that/ would be a bug.
<OT>Long time no see. Welcome back!</OT>
As long as it's not "Long time no C" :-)
I'm afraid it is. Nowadays I spend most of my time arguing with
\LaTeX, although when I do cut code it is in C (and that's
proper C, of course, not this newfangled gibberish).
LaTeX is great when it's all going well, but sometimes macros can
get pretty hairy - I've written more than my share of unreadable
macro code. There's also the risk that you spend so much time
examining the microtyping and ligature generation at 1600% zoom
on the pdf reader, that you don't have time to write the documents!
Still, LaTeX (or LuaLaTeX, as I use these days) is better than
anything else I know of.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's >>>> function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
For example, it exists in Ada since 1983. The following are all
equivalent, given that Foo takes integer arguments Arg1 and Arg2:
Foo(Arg1 => 10, Arg2 => 20);
Foo(Arg2 => 20, Arg1 => 10);
Foo(10, Arg2 => 20);
Foo(10, 20);
The syntax is IMHO much nicer than using /*...*/ comments in C.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's >>>> function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
For example, it exists in Ada since 1983. The following are all
equivalent, given that Foo takes integer arguments Arg1 and Arg2:
Foo(Arg1 => 10, Arg2 => 20);
Foo(Arg2 => 20, Arg1 => 10);
Foo(10, Arg2 => 20);
Foo(10, 20);
The syntax is IMHO much nicer than using /*...*/ comments in C.
Hello there,
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the
most?
[...]
3. Other Styles?
Please show an example!
scott@slp53.sl.home (Scott Lurndal) writes:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-02-26, Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
Sorry, I should have showed this difference in my original post.
I like the GNU style except the weird indentation before the
braces of control statements. Not sure why they choose to indent
that way.
The GNU style without indent before braces looks nice to me.
Without the weird brace indent, it has nothing to do with GNU any
more; it's just two-space indentation, where opening braces are on
their own line instead of being "cuddled" into the previous line,
which is very common:
if (flag)
{
switch (state)
{
case 42:
{
state = 73;
break;
}
}
}
else
{
statement;
}
There's so much vertical space wasted in that, however.
if (flag && (state == 42)) state = 73;
else statement;
The suggested rewrite has different semantics. Instead
if(flag) state = state == 42 ? 73 : state;
else statement;
or
if(flag) state != 42 || (state = 73);
else statement;
has the same behavior as the original. (Disclaimer: not
compiled.)
On 02/03/2025 02:24, Keith Thompson wrote:I've seen examples of emulating named parameters in C using structs.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's >>>>> function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
For example, it exists in Ada since 1983. The following are all
equivalent, given that Foo takes integer arguments Arg1 and Arg2:
Foo(Arg1 => 10, Arg2 => 20);
Foo(Arg2 => 20, Arg1 => 10);
Foo(10, Arg2 => 20);
Foo(10, 20);
The syntax is IMHO much nicer than using /*...*/ comments in C.
Ada (and Python - no idea about Perl) named parameter passing have two
huge advantages over comments like Lawrence uses - one is that they let
you order the parameters in what you see as a logical manner at the call source (especially useful combined with default parameters), and the
other is that the whole thing is checked by the compiler. If the
function's signature is changed, parameters re-ordered or renamed, the
call source is either still correct or there is a hard compile-time
error. With comment-based naming, all you have done is guaranteed that
the call source looks correct but is wrong. Using comments like
Lawrence does is significant extra effort (especially to keep it in sync
with changes), and can't be trusted. It's all cost and no gain.
Named parameters are a useful tool when the language provides them, but useless when done with comments.
If someone wants to have the benefits of named parameter passing in C,
then using a struct for the arguments along with designated initialisers
and compound literals is a much better way. Individual types for the different parameters also works (wrapping the desired types in structs).
On 26.02.2025 12:53, Ar Rakin wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
Re "goofy style"; I've seen someone preferring
while (q(a,b))
{
a=b;
f(x);
if (c>d)
{
g(y);
}
}
To each his own.
That looks like a nightmare for the code reviewers.
I cannot tell where that comes from; the person who uses it is an experienced Perl programmer - may that be some convention in that
specific language context? (I can't tell.)
On 27.02.2025 10:15, Lawrence D'Oliveiro wrote:
On Thu, 27 Feb 2025 09:38:40 +0100, Janis Papanagnou wrote:
Too deep indenting I consider to be a possible bad structuring
effect ...
Would you consider half a dozen indentation levels to be too many? I
frequently go that deep.
To be honest, I've never counted them. So why should I suggest someone
else what's a "good" value. Programmers certainly should have got (or develop) a feeling about what's acceptable and what's too much in their
own playground (or in project contexts where many people cooperate).
But since you were asking I got curious; I pick one recent "C" source
from one of my toy projects and get this distribution of the amount of indents
80 - // empty lines
169 0
254 1
172 2
122 3
46 4
34 5
7 6
3 7
What would be your typical indent distribution in your "C" source code?
[a bunch of stuff about line widths]
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 26.02.2025 12:53, Ar Rakin wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
Re "goofy style"; I've seen someone preferring
while (q(a,b))
{
a=b;
f(x);
if (c>d)
{
g(y);
}
}
To each his own.
That looks like a nightmare for the code reviewers.
I cannot tell where that comes from; the person who uses it is an experienced Perl programmer - may that be some convention in that
specific language context? (I can't tell.)
It's called Whitesmith (Whitesmiths?) style. It is (or was?)
used in PJ Plauger's company, who IIANM among other things wrote
one of the first C compilers done outside of Bell Labs.
For those who don't recognize the name, PJ Plauger was involved
in C standardization efforts from an early date, and was a member
of WG14 for more than 20 years even after the first C standard
was published.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 27.02.2025 10:15, Lawrence D'Oliveiro wrote:
On Thu, 27 Feb 2025 09:38:40 +0100, Janis Papanagnou wrote:
Too deep indenting I consider to be a possible bad structuring
effect ...
Would you consider half a dozen indentation levels to be too many? I
frequently go that deep.
To be honest, I've never counted them. So why should I suggest someone
else what's a "good" value. Programmers certainly should have got (or
develop) a feeling about what's acceptable and what's too much in their
own playground (or in project contexts where many people cooperate).
But since you were asking I got curious; I pick one recent "C" source
from one of my toy projects and get this distribution of the amount of
indents
80 - // empty lines
169 0
254 1
172 2
122 3
46 4
34 5
7 6
3 7
This measurement is an interesting idea.
Gathering some statistics from what I expect is typical source for
my own code, and ignoring: blank lines; lines that are flush left;
and "non-code" lines; I get
level percent percentile
===== ======= ==========
1 69.6 69.6
2 27.0 96.5
3 2.2 98.7
4 0.9 99.6
5 0.4 100.0
giving an average indentation of 1.36 levels. The numbers shown are calculated by considering the amount of leading white space in each line,
and rounding up to an integral multiple of one indent level (which
is four columns).
On Sun, 02 Mar 2025 06:00:13 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
It's called Whitesmith (Whitesmiths?) style. It is (or was?)
used in PJ Plauger's company, who IIANM among other things wrote
one of the first C compilers done outside of Bell Labs.
For those who don't recognize the name, PJ Plauger was involved
in C standardization efforts from an early date, and was a member
of WG14 for more than 20 years even after the first C standard
was published.
In his younger years he was rather well-regarded SF author.
In his more advanced years specialized on supplying STL to C++ compiler vendors.
FWIW, people really should learn to use indent(1), will help
with many of these arguments :) [...]
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's
function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's >>>> function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
VAX-11 Pascal supported it (and a form of comment that you would dislike).
Total_memory := 0;
REPEAT
Ss_status := $GETJPI( PIDADR := Wild_pid, EFN := 4, ITMLST := Jpi_list );
IF ODD( Ss_status ) AND (Terminal_len <> 0) THEN
BEGIN
$WAITFR( 4 ); { Wait for asynch stuff to return }
On 02/03/2025 11:52, David Brown wrote:
On 02/03/2025 02:24, Keith Thompson wrote:I've seen examples of emulating named parameters in C using structs.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking
Perl's
function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
For example, it exists in Ada since 1983. The following are all
equivalent, given that Foo takes integer arguments Arg1 and Arg2:
Foo(Arg1 => 10, Arg2 => 20);
Foo(Arg2 => 20, Arg1 => 10);
Foo(10, Arg2 => 20);
Foo(10, 20);
The syntax is IMHO much nicer than using /*...*/ comments in C.
Ada (and Python - no idea about Perl) named parameter passing have two
huge advantages over comments like Lawrence uses - one is that they
let you order the parameters in what you see as a logical manner at
the call source (especially useful combined with default parameters),
and the other is that the whole thing is checked by the compiler. If
the function's signature is changed, parameters re-ordered or renamed,
the call source is either still correct or there is a hard
compile-time error. With comment-based naming, all you have done is
guaranteed that the call source looks correct but is wrong. Using
comments like Lawrence does is significant extra effort (especially to
keep it in sync with changes), and can't be trusted. It's all cost
and no gain.
Named parameters are a useful tool when the language provides them,
but useless when done with comments.
If someone wants to have the benefits of named parameter passing in C,
then using a struct for the arguments along with designated
initialisers and compound literals is a much better way. Individual
types for the different parameters also works (wrapping the desired
types in structs).
They had multiple issues:
* Having to invent auxiliary struct types for each kind of function
signature
* Having to rewrite function bodies to access parameters as struct
elements instead
* (Within the implementation, probably having to set up then copy the
struct to preserve value-passing semantics)
* At the call-site, needing to use an ugly, cluttered syntax involving compound literals and designated initialisers, a lot worse than the
example with /**/ comments
* Being limited in the default values for omitted arguments, which can
only be zeros
* Not being able to superimpose named parameters on imported functions
of existings libraries, since they require the function source code to
be revised and recompiled. (In my implementations of the feature, this
is possible, while none of the above drawbacks apply.)
It's better to accept that the language doesn't have the feature.
However, it is similar to designated initialisers, and would have been a
much more useful feature for C99.
On 02.03.2025 17:32, Scott Lurndal wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
My guess is that this form is just an informal syntax mimicking Perl's >>>>> function parameter passing ...
The idea of passing arguments by keyword predates Perl.
That wouldn't surprise me. - I know it from Perl. - Which other
(earlier) languages do you have in mind? - What's its origin?
VAX-11 Pascal supported it (and a form of comment that you would dislike).
Interesting. (I didn't know that DEC supported a Pascal dialect.)
WRT that comment; I think that {...} is not worse than the (*...*)
variant we often see. - The main point is, though, how it fits in
the language. - "C" is already full of punctuation characters, and
especially the '*' is existing in many contexts. Pascal, OTOH, is
very text-biased; so its two comment variants don't annoy [me] too
much. (The "open end" comment property is not dominating here.)
Total_memory := 0;
REPEAT
Ss_status := $GETJPI( PIDADR := Wild_pid, EFN := 4, ITMLST := Jpi_list );
IF ODD( Ss_status ) AND (Terminal_len <> 0) THEN
BEGIN
$WAITFR( 4 ); { Wait for asynch stuff to return } >>
What's that '$' preceding the function names? (I don't recall that
from the Pascal standard or from the versions I programmed with.)
Janis
On Fri, 28 Feb 2025 00:29:29 +0000[...]
Richard Harnden <richard.nospam@gmail.invalid> wrote:
Computer terminals, back in the day, were basically square,
My impression is that even in early days 5:4 was more common than
square.
so 80 columns was often a hard limit.
Now you have larger landscape screens, with windows that can be
stretched as wide as you like.
For many years I use 1200x1920 (yes, portait) as my main monitor
at work.
Turning Full HD 90 degrees does not work as well - 1080 is too
narrow. In this case 11% difference matters.
(I didn't know that DEC supported a Pascal dialect.)
Does it have optional arguments with default values? IMO keyword
arguments are much less useful without that feature/
... change does not necessarily imply progress.
On Sun, 2 Mar 2025 09:29:37 +0000, Richard Heathfield wrote:
... change does not necessarily imply progress.
Tell that to those of us who actually find a use for the new features.
On 03/03/2025 02:17, Lawrence D'Oliveiro wrote:
On Sun, 2 Mar 2025 09:29:37 +0000, Richard Heathfield wrote:
... change does not necessarily imply progress.
Tell that to those of us who actually find a use for the new features.
Why?
Michael S <already5chosen@yahoo.com> writes:
On Fri, 28 Feb 2025 00:29:29 +0000[...]
Richard Harnden <richard.nospam@gmail.invalid> wrote:
Computer terminals, back in the day, were basically square,
My impression is that even in early days 5:4 was more common than
square.
Measuring an old VGA monitor, which is pretty close to an old
computer terminal, shows an aspect ratio of 3:2 (width:height).
Certainly not square.
so 80 columns was often a hard limit.
The reasoning here is backwards. The choice of 80 columns wasn't
made to accommodate a given aspect ratio; rather, the choice of
screen width was made to accommodate 80 columns. Furthermore the
choice of 80 columns was not plucked out of thin air, or made to
fit some accidental hardware constraint; rather, the choice of 80
columns was made to provide a suitable width for a single line, and
hardware was designed around that.
Probably the choice of having only 24 lines was made for some kind
of balance and for cost reasons. But the choice of 80 columns was
made long before choices were made for computer terminals.
Now you have larger landscape screens, with windows that can be
stretched as wide as you like.
A common aspect ratio these days is 16:9 (ie, HD). But that
choice was made to be able to show movies, not to allow absurdly
long lines of text, which is an incidental consequence.
For many years I use 1200x1920 (yes, portait) as my main monitor
at work.
Turning Full HD 90 degrees does not work as well - 1080 is too
narrow. In this case 11% difference matters.
My sense is that an aspect ratio of 7:5 or 3:2 (in both cases
height:width) is about right for one page. We might want a small
strip of screen real estate for a header, so going from 1.5 to
1.6 seems workable (note incidentally that 1920:1200 is a ratio
of 1.6). But HD is 1.78 to 1; that shape is just awkward for
the display of text.
On Sun, 02 Mar 2025 13:17:12 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Fri, 28 Feb 2025 00:29:29 +0000[...]
Richard Harnden <richard.nospam@gmail.invalid> wrote:
Computer terminals, back in the day, were basically square,
My impression is that even in early days 5:4 was more common than
square.
Measuring an old VGA monitor, which is pretty close to an old
computer terminal, shows an aspect ratio of 3:2 (width:height).
Certainly not square.
Are you sure that you measured viewing area?
The references that I find on the net suggest 4:3 ratio for viewing
area, which makes sense, considering 4:3 ratio of pixels in VGA's main graphics mode (64x480).
240mm x 180mm for IBM 8512 color display
212mm x 155mm for IBM 8513 color display
283mm x 212mm for IBM 8514 color display
On 03/03/2025 12:29, bart wrote:
On 03/03/2025 12:13, Michael S wrote:
On Sun, 02 Mar 2025 13:17:12 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Fri, 28 Feb 2025 00:29:29 +0000[...]
Richard Harnden <richard.nospam@gmail.invalid> wrote:
Computer terminals, back in the day, were basically square,
My impression is that even in early days 5:4 was more common than
square.
Measuring an old VGA monitor, which is pretty close to an old
computer terminal, shows an aspect ratio of 3:2 (width:height).
Certainly not square.
Are you sure that you measured viewing area?
The references that I find on the net suggest 4:3 ratio for viewing
area, which makes sense, considering 4:3 ratio of pixels in VGA's main
graphics mode (64x480).
240mm x 180mm for IBM 8512 color display
212mm x 155mm for IBM 8513 color display
283mm x 212mm for IBM 8514 color display
It depends on the aspect ratio of the pixels. But from I remember, in
640x480 mode, they were square, so the aspect of the full-frame image,
assuming no overscan, would be 4:3. The CRT physical aspect is harder
to measure (some may be masked by the enclosure for example).
Domestic TV sizes in that era (40 years ago) were also 4:3, in the UK
at least. And a lot of monitors would have been about the same.
For home micros; Spectrums, BBCs, C64s etc, the TV was the monitor.
On 03/03/2025 12:13, Michael S wrote:
On Sun, 02 Mar 2025 13:17:12 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Fri, 28 Feb 2025 00:29:29 +0000[...]
Richard Harnden <richard.nospam@gmail.invalid> wrote:
Computer terminals, back in the day, were basically square,
My impression is that even in early days 5:4 was more common than
square.
Measuring an old VGA monitor, which is pretty close to an old
computer terminal, shows an aspect ratio of 3:2 (width:height).
Certainly not square.
Are you sure that you measured viewing area?
The references that I find on the net suggest 4:3 ratio for viewing
area, which makes sense, considering 4:3 ratio of pixels in VGA's main
graphics mode (64x480).
240mm x 180mm for IBM 8512 color display
212mm x 155mm for IBM 8513 color display
283mm x 212mm for IBM 8514 color display
It depends on the aspect ratio of the pixels. But from I remember, in
640x480 mode, they were square, so the aspect of the full-frame image, assuming no overscan, would be 4:3. The CRT physical aspect is harder to measure (some may be masked by the enclosure for example).
Domestic TV sizes in that era (40 years ago) were also 4:3, in the UK at least. And a lot of monitors would have been about the same.
(I was then developing graphics hardware with increasing resolution, but
one problem was finding suitable monitors, with a finer shadow mask for colour, that could accommodate higher line and frame rates.
Wide-screen didn't start become popular until much later. I do remember massive monitors like ones with a 5:4 display, or 1280x1024, that I had
to lug to trade shows.)
Michael S <already5chosen@yahoo.com> writes:
On Fri, 28 Feb 2025 00:29:29 +0000[...]
Richard Harnden <richard.nospam@gmail.invalid> wrote:
Computer terminals, back in the day, were basically square,
My impression is that even in early days 5:4 was more common than
square.
Measuring an old VGA monitor, which is pretty close to an old
computer terminal, shows an aspect ratio of 3:2 (width:height).
Certainly not square.
so 80 columns was often a hard limit.
The reasoning here is backwards. The choice of 80 columns wasn't
made to accommodate a given aspect ratio; rather, the choice of
screen width was made to accommodate 80 columns. Furthermore the
choice of 80 columns was not plucked out of thin air, or made to
fit some accidental hardware constraint; rather, the choice of 80
columns was made to provide a suitable width for a single line, and
hardware was designed around that.
My sense is that an aspect ratio of 7:5 or 3:2 (in both cases
height:width) is about right for one page. We might want a small
strip of screen real estate for a header, so going from 1.5 to
1.6 seems workable (note incidentally that 1920:1200 is a ratio
of 1.6). But HD is 1.78 to 1; that shape is just awkward for
the display of text.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
My sense is that an aspect ratio of 7:5 or 3:2 (in both cases
height:width) is about right for one page. We might want a small
strip of screen real estate for a header, so going from 1.5 to
1.6 seems workable (note incidentally that 1920:1200 is a ratio
of 1.6). But HD is 1.78 to 1; that shape is just awkward for
the display of text.
Personally, I generally use vim with both horizontal and
vertical splits to edit multiple source files and headers
in a single window (using tabs as well, since the project
has several hundred source files). Each split is usually
about 30x90.
On Sun, 02 Mar 2025 13:17:12 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Fri, 28 Feb 2025 00:29:29 +0000
Richard Harnden <richard.nospam@gmail.invalid> wrote:
[...]
Computer terminals, back in the day, were basically square,
My impression is that even in early days 5:4 was more common than
square.
Measuring an old VGA monitor, which is pretty close to an old
computer terminal, shows an aspect ratio of 3:2 (width:height).
Certainly not square.
Are you sure that you measured viewing area?
The references that I find on the net suggest 4:3 ratio for viewing
area, which makes sense, considering 4:3 ratio of pixels in VGA's main graphics mode (64x480).
240mm x 180mm for IBM 8512 color display
212mm x 155mm for IBM 8513 color display
283mm x 212mm for IBM 8514 color display
For many years I use 1200x1920 (yes, portait) as my main monitor
at work.
Turning Full HD 90 degrees does not work as well - 1080 is too
narrow. In this case 11% difference matters.
My sense is that an aspect ratio of 7:5 or 3:2 (in both cases
height:width) is about right for one page. We might want a small
strip of screen real estate for a header, so going from 1.5 to
1.6 seems workable (note incidentally that 1920:1200 is a ratio
of 1.6). But HD is 1.78 to 1; that shape is just awkward for
the display of text.
In case of FHD turned 90 Degrees I am less concerned about ratio.
I just find 1080 pixel width insufficient.
If somebody gives me 1200x2048 (W:H) display I will use it just fine
despite almost the same ratio as 1080x1920.
The use case is several landscape windows placed one above another. Most
of the time attention concentrated on one window, but occasionally goes
to the others without need to resize or minimize anything. I find it
more convenient than arranging windows side-by-side or then using
multiple monitors.
On 02/03/2025 13:52, Tim Rentsch wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 27.02.2025 10:15, Lawrence D'Oliveiro wrote:
On Thu, 27 Feb 2025 09:38:40 +0100, Janis Papanagnou wrote:
Too deep indenting I consider to be a possible bad structuring
effect ...
Would you consider half a dozen indentation levels to be too many? I
frequently go that deep.
To be honest, I've never counted them. So why should I suggest someone
else what's a "good" value. Programmers certainly should have got (or
develop) a feeling about what's acceptable and what's too much in their
own playground (or in project contexts where many people cooperate).
But since you were asking I got curious; I pick one recent "C" source
from one of my toy projects and get this distribution of the amount of
indents
80 - // empty lines
169 0
254 1
172 2
122 3
46 4
34 5
7 6
3 7
This measurement is an interesting idea.
Gathering some statistics from what I expect is typical source for
my own code, and ignoring: blank lines; lines that are flush left;
and "non-code" lines; I get
level percent percentile
===== ======= ==========
1 69.6 69.6
2 27.0 96.5
3 2.2 98.7
4 0.9 99.6
5 0.4 100.0
giving an average indentation of 1.36 levels. The numbers shown are
calculated by considering the amount of leading white space in each line,
and rounding up to an integral multiple of one indent level (which
is four columns).
I tried it on a non-C project and the results were:
Level Count Percentage
1 11843 52%
2 6659 29%
3 3016 13%
4 1016 4%
5 366 2%
6 79 0%
7 15 0%
Total 22994 100%
Total project size was 29K lines. Comments are ignored. Level 0 lines
are ignored.
IBM developed 80-column cards, with the same overall size, in the late
1920s. Apparently 80 just happened to be the number of rectangular
holes that could reasonably be accommodated (and it's a nice round
number). And 80-column video terminals were baed on card sizes (though
I think some earlier terminals had 40 columns).
It depends on the aspect ratio of the pixels. But from I remember, in
640x480 mode, they were square ...
On Mon, 03 Mar 2025 15:23:52 -0800, Keith Thompson wrote:
IBM developed 80-column cards, with the same overall size, in the late
1920s. Apparently 80 just happened to be the number of rectangular
holes that could reasonably be accommodated (and it's a nice round
number). And 80-column video terminals were baed on card sizes (though
I think some earlier terminals had 40 columns).
Where did 132-column printers come from?
On 04.03.2025 04:17, Lawrence D'Oliveiro wrote:
Where did 132-column printers come from?
From IBM ? - Or S&H ?
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
1. GNU Style
2. Linux Style
Ar Rakin:
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
1. GNU Style
2. Linux Style
I don't like them much. Below is a piece of my code
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 4 Mar 2025 06:12:54 +0100, Janis Papanagnou wrote:
On 04.03.2025 04:17, Lawrence D'Oliveiro wrote:
Where did 132-column printers come from?
From IBM ? - Or S&H ?
The point being, the idea that 80 columns is a good line length for
programming is, shall we say, based on doubtful evidence.
Why are you writing that in (indirect) response to a post in which I
already acknowledged that?
If your question about 132-column printers was intended to make a point,
why not just make that point directly?
On 04/03/2025 14:56, Anton Shepelev wrote:
Ar Rakin:
I've been writing C code for a long time, in different styles, but
always wanted to know which code style most people prefer. This is all
about that question. Which one of the following do you prefer the most?
1. GNU Style
2. Linux Style
I don't like them much. Below is a piece of my code
I don't like most of the choices you've made :-) *but* I can see
perfectly good reasons for making those choices (if that's any
consolation).
Just about the only choice of yours that I /do/ like is your brace
placement:
{
{
{
}
}
}
which like because it makes the code's structure stand out so clearly.
I know a lot of people criticise this style for being wasteful of
vertical space, but I've never seen that as a problem. My screen can
hold more than enough code to occupy me, and my annual vertical space
bill is very reasonable.
The style I use for generated code is like this:
if (cond) {
stmt1;
}
else {
stmt2;
}
On Tue, 4 Mar 2025 06:12:54 +0100, Janis Papanagnou wrote:
On 04.03.2025 04:17, Lawrence D'Oliveiro wrote:
Where did 132-column printers come from?
From IBM ? - Or S&H ?
The point being, the idea that 80 columns is a good line length for programming is, shall we say, based on doubtful evidence.
On 2025-03-04, bart <bc@freeuk.com> wrote:
The style I use for generated code is like this:
if (cond) {
stmt1;
}
else {
stmt2;
}
I've been known to do this:
if (case_ineligible_for_switch) {
// ...
} else switch (state_variable) {
// ...
}
or
if (case_not_requiring_loop) {
// ...
} else for (;;) {
// ...
}
and I might even have historically perpetrated something like:
if (case_not_requiring_loop) {
// ...
} else if (case_requiring_loop) for (;;) {
// ...
} else {
// ...
}
:)
I like the brace on its own line. It visually separates the
condidition from the statement.
How do people format long and complex conditions, given that
you're trying not to a much over 80 columns?
On Tue, 4 Mar 2025 05:39:25 -0000 (UTC), I wrote:
On Tue, 4 Mar 2025 06:12:54 +0100, Janis Papanagnou wrote:
On 04.03.2025 04:17, Lawrence D'Oliveiro wrote:
Where did 132-column printers come from?
From IBM ? - Or S&H ?
The point being, the idea that 80 columns is a good line length for
programming is, shall we say, based on doubtful evidence.
And also, there was one computer company, might have been ICL, that used >90-column punch cards.
On 04/03/2025 21:49, Richard Harnden wrote:
<snip>
I like the brace on its own line. It visually separates the
condidition from the statement.
Agreed.
How do people format long and complex conditions, given that
you're trying not to a much over 80 columns?
I like to break after a binary operator so that it is
syntactically obvious that the line must continue:
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
(You'll be glad to hear that that's not a direct quote!)
On 2025-03-04, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 04/03/2025 21:49, Richard Harnden wrote:
<snip>
I like the brace on its own line. It visually separates the
condidition from the statement.
Agreed.
How do people format long and complex conditions, given that
you're trying not to a much over 80 columns?
I like to break after a binary operator so that it is
syntactically obvious that the line must continue:
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
(You'll be glad to hear that that's not a direct quote!)
(when (or (and (/= a b)
(/= c d)
(/= e f))
(and (= g (* (h)
(i)))
(= j k)))
(foo))
I like the brace on its own line. It visually separates the condidition
from the statement.
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
On Tue, 4 Mar 2025 05:39:25 -0000 (UTC), I wrote:
On Tue, 4 Mar 2025 06:12:54 +0100, Janis Papanagnou wrote:
On 04.03.2025 04:17, Lawrence D'Oliveiro wrote:
Where did 132-column printers come from?
From IBM ? - Or S&H ?
The point being, the idea that 80 columns is a good line length for
programming is, shall we say, based on doubtful evidence.
And also, there was one computer company, might have been ICL, that used 90-column punch cards.
[ big snip of possible and personal style preferences ]
(That is, when you have to use braces; generally I don't like that style
of syntax *because* there are so many placement styles: there are
multiple ways of writing the three tokens of '} else {'; not so many if
it's just the single token 'else'.)
Trying to compensate suboptimal programming choices by extending the
used line length ...
On 04/03/2025 21:49, Richard Harnden wrote:
How do people format long and complex conditions, given that you're
trying not to a much over 80 columns?
I like to break after a binary operator so that it is syntactically
obvious that the line must continue:
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
On 04.03.2025 23:17, Richard Heathfield wrote:
On 04/03/2025 21:49, Richard Harnden wrote:
How do people format long and complex conditions, given that you're
trying not to a much over 80 columns?
I had a look into that "C" project where I posted some excerpts but unfortunately it hasn't code that's artificially split; I seem to avoid overly complex expressions in the first place.
BTW, one way to avoid complex expressions is to use interim variables
(if possible for semantical parts). (This had previously already been suggested by someone else here some time ago).
I like to break after a binary operator so that it is syntactically
obvious that the line must continue:
In principle I do the same. - But in cases like this:
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
I prefer a logical bundling (and also try not to put '||' and '&&' in
the same category); something like
if ((a != b && c != d && e != f) ||
(g = h() * i() && (j = k))) // assuming assignments here
{
foo();
}
and, depending on the expression complexity, occasionally adding some
more spaces, like
if ((a != b && c != d && e != f) ||
to easier identify the components (relational first, logical later).
Janis
There's a reason why I dislike languages whose syntax is cluttered
with parentheses
On 05/03/2025 08:35, Janis Papanagnou wrote:
There's a reason why I dislike languages whose syntax is cluttered
with parentheses
(I (bet ((you ((jutht) love) Lithp).)))
It may forever label me as a pariah, but if I were writing
this for myself, I'd probably put it:
if (
(a != b && c != d && e != f)
||
(g = h() * i() && (j = k)
)
{
foo();
}
[...]
I like to break after a binary operator so that it is
syntactically obvious that the line must continue:
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
(You'll be glad to hear that that's not a direct quote!)
Richard Heathfield:
I like to break after a binary operator so that it is
syntactically obvious that the line must continue:
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
(You'll be glad to hear that that's not a direct quote!)
There is no way I like for the formatting of multiline
conditions in if()'s.
On 05/03/2025 13:22, Anton Shepelev wrote:
Richard Heathfield:
I like to break after a binary operator so that it is
syntactically obvious that the line must continue:
if((a != b &&
c != d &&
e != f) ||
(g = h() * i() &&
(j = k))
{
foo();
}
(You'll be glad to hear that that's not a direct quote!)
There is no way I like for the formatting of multiline
conditions in if()'s.
Agreed. The correct (IMNO, of course) way to re-format the code
above is to throw it out and start again. There is no way to
make it clear in a single expression. (The appropriate way to
organise the final result will depend on what these different
identifiers actually are in real code.)
I can now reveal that in real code those identifiers don't
exist, having been spun into existence merely to serve as
an illustration.
In practice, of course, one would have refactored the code
long before it reached this advanced stage of
nonsensicalitude.
[...]
Now some use ridiculously long identifiers. And actually, some compilers don't have a cap on the length. I once tried to compile code like this
with gcc:
int a, b, c;
a = b + c;
but using machine-generated billion-character identifiers. I think it
worked, eventually.
The context in the thread this came up in was whether names should have
any limit on the length (my tools capped them at 255 characters), and
most thought they shouldn't. But even 255 characters would be hopelessly impractical if using a text editor.
Richard Heathfield:
I can now reveal that in real code those identifiers don't
exist, having been spun into existence merely to serve as
an illustration.
In practice, of course, one would have refactored the code
long before it reached this advanced stage of
nonsensicalitude.
Of course, but with longer identifiers, even sensible
conditions often jutt beyond the 80-character margin.
On 05.03.2025 17:40, bart wrote:
[...]
Now some use ridiculously long identifiers. And actually, some compilers
don't have a cap on the length. I once tried to compile code like this
with gcc:
int a, b, c;
a = b + c;
but using machine-generated billion-character identifiers. I think it
worked, eventually.
The context in the thread this came up in was whether names should have
any limit on the length (my tools capped them at 255 characters), and
most thought they shouldn't. But even 255 characters would be hopelessly
impractical if using a text editor.
Your choice is IMO large enough with plenty of room for pathological
variable name lengths. The longest name constructs I encountered was
in Java contexts; first of all long names were used, but the total
length came from sequences of dot-separated entities. (Still within
limits like 255.)
Of course, if you can prevent limits in the first place that would be
yet better. But are flexible limits necessary here in practice? (I'd
be interested to hear whether anyone encountered such long names, or
felt a need for that.[*])
Reminds me the file name evolution/revolution; in earlier days (due
to length restrictions) file names have often been abbreviated, in
more recent days file _names_ have often become file _novels_ (even
carrying other stuff, file meta-information, or complete stories in
it, sort of). - Evolving from one extreme to the other...
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop >counters;
Richard Harnden <richard.nospam@gmail.invalid> writes:
Seriously, short variable names for common things - i, j, k for loop
counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
On 05.03.2025 09:39, Richard Heathfield wrote:
On 05/03/2025 08:35, Janis Papanagnou wrote:
There's a reason why I dislike languages whose syntax is cluttered
with parentheses
(I (bet ((you ((jutht) love) Lithp).)))
With my first glimpse of lithp code I immediately felt repelled, erm..,
wrong word - I meant: felt deep and long lasting _respect_ for it. :-)
But I know there are folks who really love it. - That's fine by me.
(It's always good if you have options to choose from.)
Seriously, short variable names for common things - i, j, k for loop >>counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop >>counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Using i for indexing, and then allocating nested indices using
subsequent letters after i, is a practice that long precedes
the existence of computers and Fortran.
On 2025-03-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 05.03.2025 09:39, Richard Heathfield wrote:
On 05/03/2025 08:35, Janis Papanagnou wrote:
There's a reason why I dislike languages whose syntax is cluttered
with parentheses
(I (bet ((you ((jutht) love) Lithp).)))
With my first glimpse of lithp code I immediately felt repelled, erm..,
wrong word - I meant: felt deep and long lasting _respect_ for it. :-)
But I know there are folks who really love it. - That's fine by me.
(It's always good if you have options to choose from.)
Lisp offers ways to break long expressions in multiple ways,
all falling under the same general algorithm that is easy supported
in your editor.
That's why I posted that example:
(when (or (and (/= a b)
(/= c d)
(/= e f))
(and (= g (* (h)
(i)))
(= j k)))
(foo))
You just don't have these stylistic issues about where to put
the operator relative to the operand. [...]
It all started with Irving Joshua Matrix, a close personal friend of
Martin Gardner (well-known Press Officer for the University of Chicago).
Dr Matrix, who gave his surname to the celebrated mathematical
construct, famously bequeathed his initials to medical indexing.
Fortran's 'implicit' keyword led to one of the longest and ugliest court cases in computing history, settled out of court in Dr Matrix's favour
in 2018 for an undisclosed sum.
People are forgetting that in the days of 80-character hardware,
identifiers were often limited to 6 characters or even fewer.
On Wed, 5 Mar 2025 16:40:51 +0000, bart wrote:
People are forgetting that in the days of 80-character hardware,
identifiers were often limited to 6 characters or even fewer.
COBOL allowed for 30 from the beginning, as I recall. And PL/I allowed 31.
Whatever it was you meant by “80-character hardware” (see discussion elsewhere) ...
On 05/03/2025 22:02, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 16:40:51 +0000, bart wrote:
People are forgetting that in the days of 80-character hardware,
identifiers were often limited to 6 characters or even fewer.
COBOL allowed for 30 from the beginning, as I recall. And PL/I allowed
31.
So:
ADD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA TO BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
GIVING CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC.
? A tight fit for an 80-column card I think.
On 05.03.2025 20:12, Kaz Kylheku wrote:
On 2025-03-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 05.03.2025 09:39, Richard Heathfield wrote:
On 05/03/2025 08:35, Janis Papanagnou wrote:
There's a reason why I dislike languages whose syntax is cluttered
with parentheses
(I (bet ((you ((jutht) love) Lithp).)))
With my first glimpse of lithp code I immediately felt repelled, erm..,
wrong word - I meant: felt deep and long lasting _respect_ for it. :-)
But I know there are folks who really love it. - That's fine by me.
(It's always good if you have options to choose from.)
Lisp offers ways to break long expressions in multiple ways,
all falling under the same general algorithm that is easy supported
in your editor.
That's why I posted that example:
(when (or (and (/= a b)
(/= c d)
(/= e f))
(and (= g (* (h)
(i)))
(= j k)))
(foo))
You just don't have these stylistic issues about where to put
the operator relative to the operand. [...]
But isn't that a property of every system specified in either
Polish Notation (like Lisp) or Reversed Polish Notation, that
require no parenthesis to evaluate expressions? Interestingly,
Lisp (employing such a in principle parenthesis-free language)
With my first glimpse of lithp code I immediately felt repelled ...
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Is that "Dr Matrix" a joke?
Yes.
https://en.wikipedia.org/wiki/Irving_Joshua_Matrix
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop
counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
On 05/03/2025 22:02, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 16:40:51 +0000, bart wrote:
People are forgetting that in the days of 80-character hardware,
identifiers were often limited to 6 characters or even fewer.
COBOL allowed for 30 from the beginning, as I recall. And PL/I allowed
31.
So:
ADD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA TO BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
GIVING CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC.
? A tight fit for an 80-column card I think.
I think linker symbols were more limited; on DEC typically 6 characters
for example.
I suspect the 30 characters were as a much of an arbitrary
implementation limit as my 255; you wouldn't supposed to get anywhere
near it.
Whatever it was you meant by “80-character hardware” (see discussion
elsewhere) ...
Punched cards, teletypes and VDUs tended to use 72/80 columns.
The first
text display I owned used 64. I think home or small-business printers
(not lineprinters) were based around 80 columns too (10cpi over 8 inches).
On 05/03/2025 22:02, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 16:40:51 +0000, bart wrote:
People are forgetting that in the days of 80-character hardware,
identifiers were often limited to 6 characters or even fewer.
COBOL allowed for 30 from the beginning, as I recall. And PL/I allowed 31.
So:
ADD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA TO BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
GIVING CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC.
? A tight fit for an 80-column card I think.
On 05/03/2025 18:51, Scott Lurndal wrote:
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop
counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Nonsense.
Ask rather why Fortran picked i, j, k for integer-type index variables.
Their use for that function in maths /long/ predates Fortran.
David Brown <david.brown@hesbynett.no> writes:
On 05/03/2025 18:51, Scott Lurndal wrote:
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop
counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Nonsense.
Ask rather why Fortran picked i, j, k for integer-type index variables.
Their use for that function in maths /long/ predates Fortran.
That doesn't mean that C programmers didn't adopt the
use of i,j,k from FORTRAN.
On 06/03/2025 14:49, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 05/03/2025 18:51, Scott Lurndal wrote:
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k
for loop
counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Nonsense.
Ask rather why Fortran picked i, j, k for integer-type index
variables.
Their use for that function in maths /long/ predates Fortran.
That doesn't mean that C programmers didn't adopt the
use of i,j,k from FORTRAN.
I'd always assumed it was because 'index' was too much to type,
and that j and k just followed on.
Didn't know about any hysterical raisins.
David Brown <david.brown@hesbynett.no> writes:
On 05/03/2025 18:51, Scott Lurndal wrote:
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop
counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Nonsense.
Ask rather why Fortran picked i, j, k for integer-type index variables.
Their use for that function in maths /long/ predates Fortran.
That doesn't mean that C programmers didn't adopt the
use of i,j,k from FORTRAN.
David Brown <david.brown@hesbynett.no> writes:
On 05/03/2025 18:51, Scott Lurndal wrote:
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop
counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Nonsense.
Ask rather why Fortran picked i, j, k for integer-type index variables. >>Their use for that function in maths /long/ predates Fortran.
That doesn't mean that C programmers didn't adopt the
use of i,j,k from FORTRAN.
At school we used a, b, c... for trigonometry and p, q, r for
point co-ordinates, so I suppose I assumed that i, j, k... for
matrices was intended to exploit a nice juicy part of the
alphabet that wasn't being used for anything else...
...and then along came imaginary numbers.
bart <bc@freeuk.com> writes:
On 05/03/2025 22:02, Lawrence D'Oliveiro wrote:
On Wed, 5 Mar 2025 16:40:51 +0000, bart wrote:So:
People are forgetting that in the days of 80-character hardware,
identifiers were often limited to 6 characters or even fewer.
COBOL allowed for 30 from the beginning, as I recall. And PL/I allowed 31. >>
ADD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA TO BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
GIVING CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC.
? A tight fit for an 80-column card I think.
A statement could easily span multiple cards. Do a google search
on 'COBOL continuation line'.
On 2025-03-06, Scott Lurndal <scott@slp53.sl.home> wrote:
A statement could easily span multiple cards. Do a google search
on 'COBOL continuation line'.
The "COBOL continuation line" is the result of the ritual when the aging
king of COBOL in a given geographic region nominates his younger
successor, passing to him the deck of royal punched cards, and a
sceptre-like stick for reaching the computer room power switch that
is mounted ten feet up on the wall.
On 06/03/2025 15:49, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 05/03/2025 18:51, Scott Lurndal wrote:
Richard Harnden <richard.nospam@gmail.invalid> writes:
On 05/03/2025 17:09, Janis Papanagnou wrote:
On 05.03.2025 17:40, bart wrote:
[...]
Seriously, short variable names for common things - i, j, k for loop >>>>> counters;
So, one might ask _why_ i, j, k instead of a, b, c?
Answer: Fortran IMPLICIT INTEGER
Nonsense.
Ask rather why Fortran picked i, j, k for integer-type index variables.
Their use for that function in maths /long/ predates Fortran.
That doesn't mean that C programmers didn't adopt the
use of i,j,k from FORTRAN.
I certainly did not. I use i, j, k in maths, then in BASIC, then in
Pascal, then in C. No Fortran in sight.
/Everyone/ uses i, j, k for simple indices, because it is standard in
maths and is a convention that works well in just about any programming language. Fortran may have been have been one of the first high-level programming languages, but there is no reason to suppose others copied
this convention from it.
And while my knowledge of Fortran is close to negligible, I don't
believe you are /required/ to use i, j or k for indices - people use
other letters or identifiers for loop counters and indices, just as they
do in most languages. The only language I know of where you are forced
to use i and j is FORTH.
I'm sure that people who first programmed in Fortran, and then in C,
took some of their habits with them. And there are no doubt plenty of features of programming and programming languages that Fortran
pioneered, and other languages copied - this is not one of them.
On 2025-03-06, Richard Heathfield <rjh@cpax.org.uk> wrote:
At school we used a, b, c... for trigonometry and p, q, r for
point co-ordinates, so I suppose I assumed that i, j, k... for
matrices was intended to exploit a nice juicy part of the
alphabet that wasn't being used for anything else...
...and then along came imaginary numbers.
The imaginary i happily coexists with the indexing i.
Mathematicians come in two varieties: those who are oblivious
to ambiguity and those who relish it. This i situation goes
unnoticed by the former, and pleases the latter.
Electrical engineers, on the other hand, came along bearing
current, and immediately saw the i clash, renaming the
imaginary i to j.
However, electrical engineers don't count through any abstract spaces,
so they don't care about i (current) clashing with i (indexing).
They count things like resistors (R1, R2, ...), capacitors (C1, C2, ...) integrated circuits (U1, U2, ...), component pins, and so on.
An EE would never say impractical, goofy things like, "For i from 1
through n (that being the number of capacitors n in my circuit), such
and such a facts holds about Ci ..."
And that was before I learned that the first instruction in any FORTRAN program has to be "IMPLICIT NONE" ...
David Brown <david.brown@hesbynett.no> writes:
On 06/03/2025 22:14, Kaz Kylheku wrote:[...]
Mathematicians come in two varieties: those who are oblivious
to ambiguity and those who relish it. This i situation goes
unnoticed by the former, and pleases the latter.
Mathematicians come in two varieties - those that can count, and those
that can't count.
Mathematicians come in three varieties - those that can count, and those
that can't count. The third variety is left as an exercise for the
student.
On 04/03/2025 18:14, Kaz Kylheku wrote:
On 2025-03-04, bart <bc@freeuk.com> wrote:
The style I use for generated code is like this:
if (cond) {
stmt1;
}
else {
stmt2;
}
I've been known to do this:
if (case_ineligible_for_switch) {
// ...
} else switch (state_variable) {
// ...
}
or
if (case_not_requiring_loop) {
// ...
} else for (;;) {
// ...
}
and I might even have historically perpetrated something like:
if (case_not_requiring_loop) {
// ...
} else if (case_requiring_loop) for (;;) {
// ...
} else {
// ...
}
I like the brace on its own line. It visually separates the
condidition from the statement.
How do people format long and complex conditions, given that
you're trying not to a much over 80 columns?
David Brown <david.brown@hesbynett.no> writes:
On 26/02/2025 15:39, Bradley K. Sherman wrote:
Just do your best to keep it neat and under 80 columns.
Neat, yes. 80 columns, no - unless you are living in the previous
century.
Lines that are too long are hard to read, but the idea that 80
columns is a good number or should be a hard limit is /long/
outdated. [...]
I tend to prefer the 80 column constraint. I use vim with both
horizontal and vertical splits to work on a codebase with several
hundred source files; 80-column lines are much easier to read in
that environment, where each split may only be 80 columns wide
with two or three vertical splits available on a wide (16x9)
screen.
Makes it easly to move between files/splits using the keyboard,
especially useful over ssh.
I often read code on 8.5 by 11 paper. I find using that medium
gives me a wider focus, and lets me understand how code fits
together on a large scale, better than looking at code on a
display, even a very large one.
Having more than 80 columns per
line when using a paper medium makes the characters smaller, and
IME increases the amount of effort and energy needed when reading,
which consequently limits the amount of time I can spend reviewing
and understanding code.
There are other reasons to want to limit
line lengths to something near 80 columns, but the effect of output
on standard paper media is one of the most compelling.
On 09.03.2025 20:18, Tim Rentsch wrote:
I often read code on 8.5 by 11 paper. I find using that medium
gives me a wider focus, and lets me understand how code fits
together on a large scale, better than looking at code on a
display, even a very large one.
Oh, I wouldn't have expected that there's something here where I
can agree with you. Or only disagree in that I'd prefer A4 format
(instead of US Letter).
Though I wouldn't expect that many folks
still prefer (for a better overview) paper to displays. More so
if we consider that common (e.g. 24") screens have an area that
even exceeds two A4 papers put side by side horizontally.
[other comparisons]
Having more than 80 columns per
line when using a paper medium makes the characters smaller, and
IME increases the amount of effort and energy needed when reading,
which consequently limits the amount of time I can spend reviewing
and understanding code.
It depends. In cases where you're focusing on structure than on
details of content smaller fonts are advantageous. In programming
there's a mixture of looking at contents and structure[*]. Here
the advantage of screens with a scalable font size beats paper;
you can adjust windows and fonts to fit actual necessities. YMMV.
(And there's yet more useful functions available, like folding.)
[*] That's a difference to left-aligned, blocked prose text, BTW.
There are other reasons to want to limit
line lengths to something near 80 columns, but the effect of output
on standard paper media is one of the most compelling.
Back in the days when paper was more commonly used I often printed
source code with a2ps in its default mode, which was 2 print pages
side by side on a landscape A4 paper (with a scaling equivalent of
~71%); for 80-column programs that was fine - more columns would
result in extremely annoying line wrapping, which is actually the
primary reason for me to typically not use lines larger than these
80 columns (that a lot of devices, tools, programs, and standards
rely on). That equally holds for displays and for output on paper!
One aspect when working together with others on the same source is
important to be aware of; cleanly formatted 80-columns source code
can be trivially read by "anyone", but larger lines that wrap on
smaller devices (or on paper, if you like) is an unnecessary pain
for others; I would even call it anti-social. :-)
On 28/02/2025 12:19, Michael S wrote:
On Fri, 28 Feb 2025 10:24:19 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 28/02/2025 09:22, David Brown wrote:
As long as it's not "Long time no C" :-)
I'm afraid it is. Nowadays I spend most of my time arguing with
\LaTeX, although when I do cut code it is in C (and that's proper
C, of course, not this newfangled gibberish).
one man's newfangled gibberish is another man's proper C
Agreed. On the other hand, it is easy to overlook the virtue of
stability, and change does not necessarily imply progress.
Are any of these cases ones that you find objectionable
or would
cause difficulty for code that you work on? If so which ones?
My question here is meant to ask about specifics, not just
general categories. And to be clear, I don't mean to limit the
set of potential problems being considered to just the examples
given above.
On 12/03/2025 05:11, Tim Rentsch wrote:
Are any of these cases ones that you find objectionable
In my capacity as grumpy old git? All of them, of course.
For sound practical reasons? No, of course not.
But the importance of grump should not be under-estimated.
or would
cause difficulty for code that you work on? If so which ones?
My question here is meant to ask about specifics, not just
general categories. And to be clear, I don't mean to limit the
set of potential problems being considered to just the examples
given above.
I suppose what I'm trying to get at is that there is merit in
having a small, well-defined, well-known language that doesn't
keep buzzing around. People who want bells and whistles can
undoubtedly find them in other languages, so why insist on
dragging them into C as well when they're so rarely a good fit,
like trying to split an infinitive... in Latin?
So no, Tim; it's not for specific technical reasons, but more for
the sake of having one widely-known language that really is a
lingua franca and valuable for that very reason.
On Wed, 12 Mar 2025 06:52:33 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 12/03/2025 05:11, Tim Rentsch wrote:
Are any of these cases ones that you find objectionable
In my capacity as grumpy old git? All of them, of course.
Even in your capacity as grumpy old git you can be more concrete.
For sound practical reasons? No, of course not.
But the importance of grump should not be under-estimated.
or would
cause difficulty for code that you work on? If so which ones?
My question here is meant to ask about specifics, not just
general categories. And to be clear, I don't mean to limit the
set of potential problems being considered to just the examples
given above.
I suppose what I'm trying to get at is that there is merit in
having a small, well-defined, well-known language that doesn't
keep buzzing around. People who want bells and whistles can
undoubtedly find them in other languages, so why insist on
dragging them into C as well when they're so rarely a good fit,
like trying to split an infinitive... in Latin?
So no, Tim; it's not for specific technical reasons, but more for
the sake of having one widely-known language that really is a
lingua franca and valuable for that very reason.
So far it looks like hand waving.
On 07/03/2025 21:17, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
On 06/03/2025 22:14, Kaz Kylheku wrote:[...]
Mathematicians come in two varieties: those who are oblivious
to ambiguity and those who relish it. This i situation goes
unnoticed by the former, and pleases the latter.
Mathematicians come in two varieties - those that can count, and those
that can't count.
Mathematicians come in three varieties - those that can count, and those
that can't count. The third variety is left as an exercise for the
student.
There are two sorts of people. Those that can infer from missing data.
I'll bet that even to this day there are some grumpy old gits out there decrying Fortran 90 and insisting that FORTRAN 77 is far superior...
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:
David Brown <david.brown@hesbynett.no> wrote at 15:47 this Saturday (GMT): >>> On 07/03/2025 21:17, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
On 06/03/2025 22:14, Kaz Kylheku wrote:[...]
Mathematicians come in two varieties: those who are oblivious
to ambiguity and those who relish it. This i situation goes
unnoticed by the former, and pleases the latter.
Mathematicians come in two varieties - those that can count, and those >>>>> that can't count.
Mathematicians come in three varieties - those that can count, and those >>>> that can't count. The third variety is left as an exercise for the
student.
There are two sorts of people. Those that can infer from missing data.
There are 10 kinds of people, people who know binary and those who
don't.
There are 01 kinds of people, those who understand little-endian
notation and those who don't.
On 2025-03-12, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:
David Brown <david.brown@hesbynett.no> wrote at 15:47 this Saturday (GMT): >>>> On 07/03/2025 21:17, Keith Thompson wrote:
There are 10 kinds of people, people who know binary and those whoDavid Brown <david.brown@hesbynett.no> writes:
On 06/03/2025 22:14, Kaz Kylheku wrote:[...]
Mathematicians come in two varieties: those who are oblivious
to ambiguity and those who relish it. This i situation goes
unnoticed by the former, and pleases the latter.
Mathematicians come in two varieties - those that can count, and those >>>>>> that can't count.
Mathematicians come in three varieties - those that can count, and those >>>>> that can't count. The third variety is left as an exercise for the
student.
There are two sorts of people. Those that can infer from missing data. >>>
don't.
There are 01 kinds of people, those who understand little-endian
notation and those who don't.
There are '\0002' kinds of people: those who understand that a C octal character escape is restricted to three digits, and those who
drag their knuckles on the ground when they try to walk on their
hind legs.
On 13/03/2025 01:12, Kaz Kylheku wrote:
On 2025-03-12, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:
David Brown <david.brown@hesbynett.no> wrote at 15:47 this Saturday (GMT): >>>>> On 07/03/2025 21:17, Keith Thompson wrote:
There are 10 kinds of people, people who know binary and those whoDavid Brown <david.brown@hesbynett.no> writes:
On 06/03/2025 22:14, Kaz Kylheku wrote:[...]
Mathematicians come in two varieties: those who are oblivious
to ambiguity and those who relish it. This i situation goes
unnoticed by the former, and pleases the latter.
Mathematicians come in two varieties - those that can count, and those >>>>>>> that can't count.
Mathematicians come in three varieties - those that can count, and those >>>>>> that can't count. The third variety is left as an exercise for the >>>>>> student.
There are two sorts of people. Those that can infer from missing data. >>>>
don't.
There are 01 kinds of people, those who understand little-endian
notation and those who don't.
There are '\0002' kinds of people: those who understand that a C octal
character escape is restricted to three digits, and those who
drag their knuckles on the ground when they try to walk on their
hind legs.
There are two sorts of people - those that can be divided into two sorts
of people, and those that can't.
On 2025-03-13, David Brown <david.brown@hesbynett.no> wrote:
On 13/03/2025 01:12, Kaz Kylheku wrote:
On 2025-03-12, Keith Thompson <Keith.S.Thompson+u@gmail.com>
wrote:
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:
David Brown <david.brown@hesbynett.no> wrote at 15:47 this
Saturday (GMT):
On 07/03/2025 21:17, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
On 06/03/2025 22:14, Kaz Kylheku wrote:[...]
Mathematicians come in two varieties: those who are oblivious >>>>>>>> to ambiguity and those who relish it. This i situation goes
unnoticed by the former, and pleases the latter.
Mathematicians come in two varieties - those that can count,
and those that can't count.
Mathematicians come in three varieties - those that can count,
and those that can't count. The third variety is left as an
exercise for the student.
There are two sorts of people. Those that can infer from
missing data.
There are 10 kinds of people, people who know binary and those
who don't.
There are 01 kinds of people, those who understand little-endian
notation and those who don't.
There are '\0002' kinds of people: those who understand that a C
octal character escape is restricted to three digits, and those who
drag their knuckles on the ground when they try to walk on their
hind legs.
There are two sorts of people - those that can be divided into two
sorts of people, and those that can't.
There are two sorts of people: unstable sorts, which leave identical
twins in an unpredictable order, and stable sorts, which preserve
their original order.
The usual suspects wrote:[...]
Mathematicians come in two varieties: those who are oblivious >>>>>>>>>> to ambiguity and those who relish it. This i situation goes >>>>>>>>>> unnoticed by the former, and pleases the latter.
Mathematicians come in two varieties - those that can count, >>>>>>>>> and those that can't count.
Mathematicians come in three varieties - those that can count, >>>>>>>> and those that can't count. The third variety is left as an
exercise for the student.
There are two sorts of people. Those that can infer from
missing data.
There are 10 kinds of people, people who know binary and those
who don't.
There are 01 kinds of people, those who understand little-endian
notation and those who don't.
There are '\0002' kinds of people: those who understand that a C
octal character escape is restricted to three digits, and those who
drag their knuckles on the ground when they try to walk on their
hind legs.
There are two sorts of people - those that can be divided into two
sorts of people, and those that can't.
There are two sorts of people: unstable sorts, which leave identical
twins in an unpredictable order, and stable sorts, which preserve
their original order.
There are two sorts of people: those that find jokes about two sorts of people amusing and myself.
On 12/03/2025 05:11, Tim Rentsch wrote:
Are any of these cases ones that you find objectionable
In my capacity as grumpy old git? All of them, of course.
For sound practical reasons? No, of course not.
But the importance of grump should not be under-estimated.
or would
cause difficulty for code that you work on? If so which ones?
My question here is meant to ask about specifics, not just
general categories. And to be clear, I don't mean to limit the
set of potential problems being considered to just the examples
given above.
I suppose what I'm trying to get at is that there is merit in having
a small, well-defined, well-known language that doesn't keep buzzing
around. [...]
So no, Tim; it's not for specific technical reasons, but more for
the sake of having one widely-known language that really is a lingua
franca and valuable for that very reason.
So it looks like the grump factor is the only factor actually taking
part in the decision here.
IBM developed 80-column cards, with the same overall size, in
the late 1920s. Apparently 80 just happened to be the number
of rectangular holes that could reasonably be accommodated
[...]
Source: <https://en.wikipedia.org/wiki/Punched_card>
I'll just note that the fact that 80 is an arbitrary number,
based on technologies we no longer use, [...]
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
IBM developed 80-column cards, with the same overall size, in
the late 1920s. Apparently 80 just happened to be the number
of rectangular holes that could reasonably be accommodated
[...]
We don't know that. The same size might have accommodated 85
columns, but was revised down to 80 for other reasons. Or the
same size might have accommodated only 77 columns, but it was
discovered that 80 columns could work if a different card
material was used. The form factor was one constraint, but
not the only constraint, and not the only consideration.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
IBM developed 80-column cards, with the same overall size, in
the late 1920s. Apparently 80 just happened to be the number
of rectangular holes that could reasonably be accommodated
[...]
We don't know that. The same size might have accommodated 85
columns, but was revised down to 80 for other reasons. Or the
same size might have accommodated only 77 columns, but it was
discovered that 80 columns could work if a different card
material was used. The form factor was one constraint, but
not the only constraint, and not the only consideration.
I have a hardcover book about punched cards somewhere
in storage - came from the Burroughs library when they
closed it. I'll try to dig it out if I get a chance.
Casey, Robert S. and Perry, James W. Editors
Punched Cards - Their application to science and industry
scott@slp53.sl.home (Scott Lurndal) writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
IBM developed 80-column cards, with the same overall size, in
the late 1920s. Apparently 80 just happened to be the number
of rectangular holes that could reasonably be accommodated
[...]
We don't know that. The same size might have accommodated 85
columns, but was revised down to 80 for other reasons. Or the
same size might have accommodated only 77 columns, but it was
discovered that 80 columns could work if a different card
material was used. The form factor was one constraint, but
not the only constraint, and not the only consideration.
I have a hardcover book about punched cards somewhere
in storage - came from the Burroughs library when they
closed it. I'll try to dig it out if I get a chance.
Casey, Robert S. and Perry, James W. Editors
Punched Cards - Their application to science and industry
https://archive.org/stream/
PunchedCardsTheirApplicationsToScienceAndIndustry/
Punched_cards-their_applications_to_science_and_industry_djvu.txt
scott@slp53.sl.home (Scott Lurndal) writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
IBM developed 80-column cards, with the same overall size, in
the late 1920s. Apparently 80 just happened to be the number
of rectangular holes that could reasonably be accommodated
[...]
We don't know that. The same size might have accommodated 85
columns, but was revised down to 80 for other reasons. Or the
same size might have accommodated only 77 columns, but it was
discovered that 80 columns could work if a different card
material was used. The form factor was one constraint, but
not the only constraint, and not the only consideration.
I have a hardcover book about punched cards somewhere
in storage - came from the Burroughs library when they
closed it. I'll try to dig it out if I get a chance.
Casey, Robert S. and Perry, James W. Editors
Punched Cards - Their application to science and industry
https://archive.org/stream/
PunchedCardsTheirApplicationsToScienceAndIndustry/
Punched_cards-their_applications_to_science_and_industry_djvu.txt
A remarkable document. Thank you for the link.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
IBM developed 80-column cards, with the same overall size, in
the late 1920s. Apparently 80 just happened to be the number
of rectangular holes that could reasonably be accommodated
[...]
We don't know that. The same size might have accommodated 85
columns, but was revised down to 80 for other reasons. Or the
same size might have accommodated only 77 columns, but it was
discovered that 80 columns could work if a different card
material was used. The form factor was one constraint, but
not the only constraint, and not the only consideration.
I have a hardcover book about punched cards somewhere
in storage - came from the Burroughs library when they
closed it. I'll try to dig it out if I get a chance.
Casey, Robert S. and Perry, James W. Editors
Punched Cards - Their application to science and industry
https://archive.org/stream/
PunchedCardsTheirApplicationsToScienceAndIndustry/
Punched_cards-their_applications_to_science_and_industry_djvu.txt
A remarkable document. Thank you for the link.
The hardcover has nice B&W pictures of most of the gear.
The text document on archive.org is a poorly formatted scan thereof.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 146:55:11 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,718 |