tools for manipulating (or pre-processing) data structures to simplify source

[ra...@edisonjunior.com]

Hi c,

Trying to understand somebody else's code.

I look at a simple loop, to write flash memory, a data structure 3 levels deep, and see stuff like this:

if(GSN_FW_APP_0 == fwupCtx->gsnExtFlashFwupPvtCtx.binInProgress)
{
fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size + buffsize;
/* Calculate the intermidiate checksum*/
while(orgbuffsize>0)
{
fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum + (*orgbuff++);
orgbuffsize--;
}

}



It has been a while, do we really write now, with variable names 30+ characters long, in complex data structures, or do we use the preprocessor and tools to manage this?

I do not see how to read code written this way, it looks tool generated to me.

I will have to rewrite it by hand, and refer to the defined data structures to see whats going on. This is totally illegible.

Whats been happening since I have been out, for 10+ years?

Randy

[Keith Thompson]

ra...@edisonjunior.com writes:
> Trying to understand somebody else's code.
>
> I look at a simple loop, to write flash memory, a data structure 3 levels deep, and see stuff like this:
>
> if(GSN_FW_APP_0 == fwupCtx->gsnExtFlashFwupPvtCtx.binInProgress)
> {
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size + buffsize;
> /* Calculate the intermidiate checksum*/
> while(orgbuffsize>0)
> {
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum + (*orgbuff++);
> orgbuffsize--;
> }
>
> }

This line:

tx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size + buffsize;

is absurd; it should be written as:

tx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size += buffsize;

Likewise for the other assignment.

(Not commenting on the rest of the code.)

[...]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Willem]

ra...@edisonjunior.com wrote:
) Hi c,
)
) Trying to understand somebody else's code.
)
) I look at a simple loop, to write flash memory, a data structure 3 levels deep, and see stuff like this:
)
) if(GSN_FW_APP_0 == fwupCtx->gsnExtFlashFwupPvtCtx.binInProgress)
) {
) fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size + buffsize;
) /* Calculate the intermidiate checksum*/
) while(orgbuffsize>0)
) {
) fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum + (*orgbuff++);
) orgbuffsize--;
) }
)
) }
)
)
)
) It has been a while, do we really write now, with variable names 30+ characters long, in complex data structures, or do we use the preprocessor and tools to manage this?
)
) I do not see how to read code written this way, it looks tool generated to me.

They probably use an IDE with completion for variable and member names (you
type the first few and get a list of the possible members).

) Whats been happening since I have been out, for 10+ years?

IDE's happened.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[BartC]

<ra...@edisonjunior.com> wrote in message
news:5218f42d-68f1-4853...@googlegroups.com...

> if(GSN_FW_APP_0 == fwupCtx->gsnExtFlashFwupPvtCtx.binInProgress)
> {
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size =
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size + buffsize;
> /* Calculate the intermidiate checksum*/
> while(orgbuffsize>0)
> {
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum =
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum +
> (*orgbuff++);
> orgbuffsize--;

> It has been a while, do we really write now, with variable names 30+
> characters long, in complex data structures, or do we use the preprocessor
> and tools to manage this?

At least they seem to have used abbreviations; it could have been a lot
worse!

No, this is terrible code. Since many of these seem to be struct member
names, you don't need 20- or 30-character field names to distinguish between
a dozen different members.

And it's surely possible to give a hint as to what a field does, without to
put its entire history, background and every conceivable bit of information
into the name. If an IDE is in fact being used, that will tell you all you
need to know.

My struct member names tend to be either one or two simple words. I don't
use abbreviations much either; there's no need.

--
Bartc

[Richard]

"BartC" <b...@freeuk.com> writes:

> <ra...@edisonjunior.com> wrote in message
> news:5218f42d-68f1-4853...@googlegroups.com...
>
>> if(GSN_FW_APP_0 == fwupCtx->gsnExtFlashFwupPvtCtx.binInProgress)
>> {
>> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size =
>> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size + buffsize;
>> /* Calculate the intermidiate checksum*/
>> while(orgbuffsize>0)
>> {
>> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum =
>> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum +
>> (*orgbuff++);
>> orgbuffsize--;
>
>> It has been a while, do we really write now, with variable names 30+
>> characters long, in complex data structures, or do we use the preprocessor
>> and tools to manage this?
>
> At least they seem to have used abbreviations; it could have been a lot
> worse!
>
> No, this is terrible code. Since many of these seem to be struct member
> names, you don't need 20- or 30-character field names to distinguish between
> a dozen different members.

Nonsense.

>
> And it's surely possible to give a hint as to what a field does,
> without to

Thats what they do and do it consistently : much more important than
saving a few bytes in source code. That code is pretty much self
documentating.

> put its entire history, background and every conceivable bit of information into
> the name. If an IDE is in fact being used, that will tell you all you need to
> know.

And if an IDE isn't being used?

Consistency and clarity is much more important than "short" field names.

>
> My struct member names tend to be either one or two simple words. I don't use
> abbreviations much either; there's no need.

Try looking into linux drivers and marvel at the long struct and field
names then tell Torwalds and co they're writing "terrible code". Should be an
interesting exchange.

[BartC]

"Richard" <rgr...@gmail.com> wrote in message
news:87a9i09...@gmail.com...

> "BartC" <b...@freeuk.com> writes:

>> No, this is terrible code. Since many of these seem to be struct member
>> names, you don't need 20- or 30-character field names to distinguish
>> between
>> a dozen different members.
>
> Nonsense.

Well I wouldn't to have read any of your code, if you think this is clear!

>> And it's surely possible to give a hint as to what a field does,
>> without to
>
> Thats what they do and do it consistently : much more important than
> saving a few bytes in source code. That code is pretty much self
> documentating.

That's your opinion. I think it shouldn't be necessary to build practically
a complete set of documentation into every identifier, especially if that
identifier has a context which can take care of some of that (namely, being
a member of a specific struct type, and being used with a specific
instance).

>> put its entire history, background and every conceivable bit of
>> information into
>> the name. If an IDE is in fact being used, that will tell you all you
>> need to
>> know.
>
> And if an IDE isn't being used?

Then I would find it more effective to write one, than to try and decipher
what looks at first glance like MIME-encoded binary data!

(BTW I don't use any fancy IDEs that can do that sort of stuff. All the more
reason to keep my identifiers simple.)

>> My struct member names tend to be either one or two simple words. I don't
>> use
>> abbreviations much either; there's no need.
>
> Try looking into linux drivers and marvel at the long struct and field
> names then tell Torwalds and co they're writing "terrible code". Should be
> an
> interesting exchange.

(I've tried to have a look, but as usual with linux-related matters have run
into a dead-end, because nothing is ever straightforward! Not content with
having .tar, .gz, .gz2, .bz and .bz2 extensions, apparently the kernel
sources I located now use a tar.xz extension! My 7-Zip program couldn't
understand it, and attempts to download a new version nearly crashed my
machine (and lost me my first draft of this post). So that will have to
wait.)

--
Bartc

[BartC]

"BartC" <b...@freeuk.com> wrote in message
news:cbT9u.42071$J72....@fx08.am4...

> "Richard" <rgr...@gmail.com> wrote in message

>> Try looking into linux drivers and marvel at the long struct and field
>> names then tell Torwalds and co they're writing "terrible code".

> (I've tried to have a look, but as usual with linux-related matters have
> run
> into a dead-end, because nothing is ever straightforward!

I do happen to have some Python C sources lying around. Most of the struct
member names seem short, readable and completely reasonable. Either formed
of one or two words, or with a prefix, such as *name, HEAD, length, offset,
gc_prev, gc_next etc. There are some longer identifiers outside structs, but
these are still readable rather than look like gobbledygook, partly because
they are not so fantastically long that the words need to be abbreviated.

Maybe it's just a Linux thing to make things incomprehensible (and then try
and make out it's good coding practice!).

--
Bartc

[Eric Sosman]

On 10/22/2013 10:46 PM, ra...@edisonjunior.com wrote:
> Hi c,
>
> Trying to understand somebody else's code.
>
> I look at a simple loop, to write flash memory, a data structure 3 levels deep, and see stuff like this:
>
> if(GSN_FW_APP_0 == fwupCtx->gsnExtFlashFwupPvtCtx.binInProgress)
> {
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.APP1Size + buffsize;
> /* Calculate the intermidiate checksum*/
> while(orgbuffsize>0)
> {
> fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum = fwupCtx->gsnExtFlashFwupPvtCtx.fwupWlanCtrlBlk.app1Checksum + (*orgbuff++);
> orgbuffsize--;
> }
>
> }
>
>
>
> It has been a while, do we really write now, with variable names 30+ characters long, in complex data structures, or do we use the preprocessor and tools to manage this?

To my taste, the identifiers are on the long side, and the
multiple appearances of "fwup" look redundant. Tastes vary, though,
and I don't know what other things these names distinguish from.
In any case the longest identifier I see has 21 letters, only
about two-thirds of your "30+".

Although one *could* use macros to abbreviate:

#define GIGGLE gsnExtFlashFwupPftCtx.fwupWlanCtrlBlk
...
fwupCtx->GIGGLE.app1Checksum = ...

... I'd recommend against it. By introducing a second name for
the same thing, you'd add opportunities for confusion: Someone
looking for all uses of GIGGLE.app1Checksum could easily overlook
a reference via the true name.

> I do not see how to read code written this way, it looks tool generated to me.

Doesn't look tool-generated to me (when tools deign to write
comments, they're usually about the mechanics and not about the
purpose), but I suppose it might be. If it is, you should look for
the tool and its input: Work with them, not with their output.

(A guy once sought my help in debugging some code, and I studied
it in vain for any explanation of the symptom he'd seen. It was
utterly inexplicable: There was simply no way his code could produce
the output he showed me. Come to find out he'd been using the
compiler to generate assembly code, hand-"optimizing" the assembly,
and running *that* -- and when it didn't work, he showed me the
original source code ... Don't edit tool output.)

> I will have to rewrite it by hand, and refer to the defined data structures to see whats going on. This is totally illegible.

A few uses of the "+=" operator would make a world of difference.

> Whats been happening since I have been out, for 10+ years?

The explanation is too long for the margin of this post.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Malcolm McLean]

On Wednesday, October 23, 2013 3:46:26 AM UTC+1, ra...@edisonjunior.com wrote:
> Hi c,
>
> Trying to understand somebody else's code.
>
> I look at a simple loop, to write flash memory, a data structure 3 levels
> deep, and see stuff like this:
>
> if(GSN_FW_APP_0 == fwupCtx->gsnExtFlashFwupPvtCtx.binInProgress)
>

That's all we need to know :-)

The highlighting rule hasn't been understood.

Plain ascii test is reasonably understandable, but a bit boring to look at.
We can improve legibility by putting some words in colours, or in bold,
or in italics. But only to a point. When every other word is highlighted or
decorated in some way, the text becomes far more difficult to read.

In C we need to avoid namespace collisions, so a short prefix is unfortunately
necessary. BabyX prefixes virtually all its external symbols with "bbx_", for
this reason. But once you've done that, that's all that's really necessary.
You can then use normal identifiers, like "flash" or "context".

[Jorgen Grahn]

On Wed, 2013-10-23, ra...@edisonjunior.com wrote:
> Hi c,
>
> Trying to understand somebody else's code.

...

> Whats been happening since I have been out, for 10+ years?

Nothing. People use a lot of different styles, and many of them seem
awful. You could easily have encountered this one in 2003 too.

The solution isn't macros -- adding another parallel set of names
which disappear at compile time would just make it a lot worse.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Wed, 2013-10-23, Richard wrote:
...

> Try looking into linux drivers and marvel at the long struct and field
> names then tell Torwalds and co they're writing "terrible code". Should be an
> interesting exchange.

I read kernel code a lot, and it's far more pleasant and elegant than
this.

Not hardware drivers though; I can imagine they are often written by
outsiders. Also they may want to adapt their naming to hardware specs
et cetera.

[Jorgen Grahn]

On Wed, 2013-10-23, BartC wrote:
> "BartC" <b...@freeuk.com> wrote in message
> news:cbT9u.42071$J72....@fx08.am4...
>
>> "Richard" <rgr...@gmail.com> wrote in message
>
>>> Try looking into linux drivers and marvel at the long struct and field
>>> names then tell Torwalds and co they're writing "terrible code".
>
>> (I've tried to have a look, but as usual with linux-related matters have
>> run into a dead-end, because nothing is ever straightforward!

Any particular problems? A lot of things about Linux are very
straightforward.

> I do happen to have some Python C sources lying around. Most of the struct
> member names seem short, readable and completely reasonable. Either formed
> of one or two words, or with a prefix, such as *name, HEAD, length, offset,
> gc_prev, gc_next etc. There are some longer identifiers outside structs, but
> these are still readable rather than look like gobbledygook, partly because
> they are not so fantastically long that the words need to be abbreviated.
>
> Maybe it's just a Linux thing to make things incomprehensible (and then try
> and make out it's good coding practice!).

I should have responded here instead of upthread: the Linux [kernel]
sources I've seen are nothing like this, and quite readable.

[ralph]

On 25 Oct 2013 19:15:45 GMT, Jorgen Grahn <grahn...@snipabacken.se>
wrote:

>On Wed, 2013-10-23, ra...@edisonjunior.com wrote:
>> Hi c,
>>
>> Trying to understand somebody else's code.
>...
>> Whats been happening since I have been out, for 10+ years?
>
>Nothing. People use a lot of different styles, and many of them seem
>awful. You could easily have encountered this one in 2003 too.
>
>The solution isn't macros -- adding another parallel set of names
>which disappear at compile time would just make it a lot worse.
>

It was even worse back in the X3J Committee days.
We had compilers which accepted 16, 32, ... 128 character length
identifiers, BUT only the first 5, 8, 13, ... characters were
'unique/significant'.

Kernighan wanted only 5 significant characters written into the
standard. Real C programmers didn't need more. Imagine if that had
happened? <g>

Macros were our only salvation. <bg>

-ralph

[Kenny McCormack]

In article <slrnl6lj3d.2...@frailea.sa.invalid>,
Jorgen Grahn <grahn...@snipabacken.se> wrote:
...

>> Maybe it's just a Linux thing to make things incomprehensible (and then
>> try and make out it's good coding practice!).
>
>I should have responded here instead of upthread: the Linux [kernel]
>sources I've seen are nothing like this, and quite readable.

Caveat: I've not looked at any of his code (either the kernel or git), but I
have watched a talk he gave once in which he discussed (among other things)
his coding style.

The take-away from that talk was that he does have an, er, shall we say,
"unique" coding style, and the implied statement was that you either love
it or hate it. I get the impression that the world kinda splits about
50/50 into the love/hate camps.

So, arguing about whether or not the Linux kernel is "readable" is going to
be like arguing about any other "love/hate" kind of thing; you're not going
to convince anyone to change their stance.

--
A Catholic woman tells her husband to buy Viagra.

A Jewish woman tells her husband to buy Pfizer.

[BartC]

"Jorgen Grahn" <grahn...@snipabacken.se> wrote in message
news:slrnl6lj3d.2...@frailea.sa.invalid...

I've since managed to download the Linux sources. The one or two files I've
glanced at seem nothing like as bad as what the OP posted either. (But there
are about 45,000 files I haven't yet looked at.)

--
Bartc

[glen herrmannsfeldt]

ralph <nt_con...@yahoo.com> wrote:

(snip)

> It was even worse back in the X3J Committee days.
> We had compilers which accepted 16, 32, ... 128 character length
> identifiers, BUT only the first 5, 8, 13, ... characters were
> 'unique/significant'.

> Kernighan wanted only 5 significant characters written into the
> standard. Real C programmers didn't need more. Imagine if that had
> happened? <g>

The early PL/I compilers used the first four and last three for
external symbols. (The linker only knew about 8.) Internal names
could be longer, such as 31. Using some from each end allows for
long_name1, long_name2, etc.

The Fortran H compiler uses six trees for its symbol table, one for
each possible length. One manual suggests for faster compilation
distribute your names equally between 1 and 6 characters.
(No mention of readability of the program.)

-- glen

[christ...@cbau.wanadoo.co.uk]

On Wednesday, October 23, 2013 3:28:00 PM UTC+1, Bart wrote:

> At least they seem to have used abbreviations; it could have been a lot
> worse!

Try reading that code to someone over the phone!

Now imagine you are debugging this code. In other words, you don't trust it. How much time does it take you to verify that very similar but entirely meaningless looking identifiers are the same / are different?

[Ben Bacarisse]

ralph <nt_con...@yahoo.com> writes:
On long names...

> It was even worse back in the X3J Committee days.
> We had compilers which accepted 16, 32, ... 128 character length
> identifiers, BUT only the first 5, 8, 13, ... characters were
> 'unique/significant'.
>
> Kernighan wanted only 5 significant characters written into the
> standard. Real C programmers didn't need more. Imagine if that had
> happened? <g>

Do you have a citation? It sounds like a peculiar thing for him to
have said.

--
Ben.

[Malcolm McLean]

On Friday, October 25, 2013 10:07:49 PM UTC+1, ralph wrote:
> On 25 Oct 2013 19:15:45 GMT, Jorgen Grahn <grahn...@snipabacken.se>
>

> It was even worse back in the X3J Committee days.
> We had compilers which accepted 16, 32, ... 128 character length
> identifiers, BUT only the first 5, 8, 13, ... characters were
> 'unique/significant'.
>
> Kernighan wanted only 5 significant characters written into the
> standard. Real C programmers didn't need more. Imagine if that had
> happened? <g>
>

Fortran would accept up to six, and C compilers would prefix an underscore
to the linker. So you could only call a C routine or use a C identifier
from Fortran if it was unique in the first five.

Mathematicians don't use long names. They virtually always use single letters,
resorting to Greek or even other alphabets when they run out of Latin.
But really in programming we've several types of variables. Minor variables
should be x, y, z for co-ordinates or real values, theta for an angle,
N for a count, i, for an index. I use ii, iii, iv, v etc for nested counters
and j, k for secondary counters. (Eg if you're removing runs of duplicates,
I'd iterate over the array with i, and keep j as the counter to the top
of the unique list). But a lot of people use j, k for nested counters.
z is a complex number, ptr a pointer, str a string, ch a character, fp a
file pointer.
There's quite a lot you can do with only five characters.

[ralph]

Surprised me as well.

It was rather well known at the time so there must be some mention in
some of the earlier publications CPJ, Byte, Dr. Dobbs, ??? It is
definitely in the X3J meeting notes. All my paper is gone - too many
moves.

As Mr. McLean points out - the idea while sounding strange today had
its points.

Something often over-looked by most language lawyers today is that the
process of "standardizing" C in the beginning was less an academic
exercise that it was a process of "codifying" a common ground out of
what compilers were already doing. It doesn't take much to appreciate
that migrating programs between compilers with different views of how
many characters are significant led to problems. Since all compilers
accepted at least 5, "5" certainly made sense.

-ralph

[Ben Bacarisse]

ralph <nt_con...@yahoo.com> writes:

> On Sat, 26 Oct 2013 03:06:32 +0100, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>ralph <nt_con...@yahoo.com> writes:
>>On long names...
>>
>>> It was even worse back in the X3J Committee days.
>>> We had compilers which accepted 16, 32, ... 128 character length
>>> identifiers, BUT only the first 5, 8, 13, ... characters were
>>> 'unique/significant'.
>>>
>>> Kernighan wanted only 5 significant characters written into the
>>> standard. Real C programmers didn't need more. Imagine if that had
>>> happened? <g>
>>
>>Do you have a citation? It sounds like a peculiar thing for him to
>>have said.
>
> Surprised me as well.
>
> It was rather well known at the time so there must be some mention in
> some of the earlier publications CPJ, Byte, Dr. Dobbs, ??? It is
> definitely in the X3J meeting notes. All my paper is gone - too many
> moves.

Maybe we are talking at cross purposes. You quote suggests that
Kernighan did not want more because real programmers don't need more.
That seems entirely at odds with almost everything I've read by him.
For example, in 1974 -- four years before K&R 1 and more than a decade
before the ANSI standard he was advising, as a matter of style, to make
external identifiers unique in the first 6 characters. That was, as you
probably know, common at the time. Note, as a matter of style, not "you
don't need more" just that you may hit a linker limit if you assume that
more will be unique.

I can see him advocating for the standard to require no more than five
from an implementation if he had become aware in those ten or twelve
years of a system that could not guarantee even six, but that's not at
all the same as saying the real programmers don't need more.

> As Mr. McLean points out - the idea while sounding strange today had
> its points.
>
> Something often over-looked by most language lawyers today is that the
> process of "standardizing" C in the beginning was less an academic
> exercise that it was a process of "codifying" a common ground out of
> what compilers were already doing. It doesn't take much to appreciate
> that migrating programs between compilers with different views of how
> many characters are significant led to problems. Since all compilers
> accepted at least 5, "5" certainly made sense.

Yes, but that's not how you presented the quote. If there were key
systems that could not guarantee five I can see him, and others, arguing
for four, but that would be out of desperation with broken linkers, not
because real programmer don't need more.

--
Ben.

[Lew Pitcher]

On Saturday 26 October 2013 14:00, in comp.lang.c, "Ben Bacarisse"

IIRC, the MVS LKED linkage editor of the time had a 6-character limit on the
size of external names. The VSE linkage editor had a similar limit.

It wasn't too long later (a few years) that IBM came up with the LE370 tools
that extended both the assembler and linkage editor to handle larger
external names, and added a native C compiler to the language support.

[snip]


--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[Lew Pitcher]

On Saturday 26 October 2013 14:31, in comp.lang.c, "Lew Pitcher"

Correction, now that I've checked my archived JCL: the MVS Linkage Editor
was programname IEWL, later replaced by HEWL when LE370 came along.

> linkage editor of the time had a 6-character limit on
> the size of external names. The VSE linkage editor had a similar limit.

[ralph]

"Real C programmers didn't need more" was my tongue-in-cheek
embellishment, which wasn't necessary, but thought obvious.

Expressing what "Real" programmers would do, or would not do, was
common. A sort of double-entendre used both to support one's own
opinion or deride other's.

I agree that it is doubtful Kernighan would ever have used the
expression formally. However, in his heart of hearts, I firmly believe
he KNEW what REAL programmers would do. <g>

-ralph

[glen herrmannsfeldt]

Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:

(snip, someone wrote)

>> Maybe we are talking at cross purposes. You quote suggests that
>> Kernighan did not want more because real programmers don't need more.
>> That seems entirely at odds with almost everything I've read by him.
>> For example, in 1974 -- four years before K&R 1 and more than a decade
>> before the ANSI standard he was advising, as a matter of style, to make
>> external identifiers unique in the first 6 characters. That was, as you
>> probably know, common at the time. Note, as a matter of style, not "you
>> don't need more" just that you may hit a linker limit if you assume that
>> more will be unique.

> IIRC, the MVS LKED linkage editor of the time had a 6-character
> limit on the size of external names. The VSE linkage editor had
> a similar limit.

I don't know the DOS/360 or VSE well at all, but from OS/360 through
to MVS the limit is eight. Eight is a favorite number. Jobnames are
eight, DDnames are eight, PDS member names are eight, and DSNames
in the catalog have at most eight between periods.

VM/370 and descendants have eight character filenames and filetypes
(what many call extensions).

The six character limits came from BCD on the 36 bit machines,
and later SIXBIT on the DEC 36 bit machines.

> It wasn't too long later (a few years) that IBM came up with
> the LE370 tools that extended both the assembler and linkage
> editor to handle larger external names, and added a native C
> compiler to the language support.

Well, PL/I allowed longer names, too, but IBM restricted
external names by using, I believe, the first four and last
three characters. (Allows for more than one CSECT per PROC.)
LE is convenient for both PL/I and C. Is there a Fortran 90
compiler?

-- glen

[Richard Damon]

My guess is either some popular compiler or linker had a 5 (or maybe 6
in the linker to deal with the standardly supplied leading _) limit.

Compressing the 63 valid name characters (A-Za-z0-9_) into 6 bits would
put 5 characters into a 32 bit long (or 5 7 bit characters into a 36 bit
long) could be a viable compact representation.

[Ben Bacarisse]

ralph <nt_con...@yahoo.com> writes:

> On Sat, 26 Oct 2013 19:00:45 +0100, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>
>>Yes, but that's not how you presented the quote. If there were key
>>systems that could not guarantee five I can see him, and others, arguing
>>for four, but that would be out of desperation with broken linkers, not
>>because real programmer don't need more.
>
> "Real C programmers didn't need more" was my tongue-in-cheek
> embellishment, which wasn't necessary, but thought obvious.
>
> Expressing what "Real" programmers would do, or would not do, was
> common. A sort of double-entendre used both to support one's own
> opinion or deride other's.

Yes I know the trope, and I, too, doubt he would have said it literally.
But we are back to square one -- do you have a citation that shows that
attitude?

> I agree that it is doubtful Kernighan would ever have used the
> expression formally. However, in his heart of hearts, I firmly believe
> he KNEW what REAL programmers would do. <g>

That sounds like you don't have any evidence that he would have taken
such an attitude to this issue. It's hardly a big deal, but if so, I
think you should withdraw it.

--
Ben.

[ralph]

LOL. Get over it.

Chalk it up to "something I don't believe happened". Ok by me.

I was there. Were you?

-ralph

[BartC]

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:l4h7vg$5ee$1...@speranza.aioe.org...

> The six character limits came from BCD on the 36 bit machines,
> and later SIXBIT on the DEC 36 bit machines.

And possibly from Radix-50 on 16 and 32-bit ones.

--
Bartc

[Ben Bacarisse]

ralph <nt_con...@yahoo.com> writes:

> On Sat, 26 Oct 2013 22:17:55 +0100, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>>
>>That sounds like you don't have any evidence that he would have taken
>>such an attitude to this issue. It's hardly a big deal, but if so, I
>>think you should withdraw it.
>
> LOL. Get over it.

With time, and counselling, I may one day... oh, I'm over it. You did
see "It's hardly a big deal" yes?

> Chalk it up to "something I don't believe happened". Ok by me.
>
> I was there. Were you?

Not sure where "there" is, but most likely not. If you are just
reporting what you saw/heard/read, I'll take your word for it ("personal
communication" is a reasonable citation). But the grins made me feel
you were taking the mickey out of someone who's not around to set the
record straight.

--
Ben.

[Keith Thompson]

You were there? Can you expand on that?

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Jorgen Grahn]

On Fri, 2013-10-25, Kenny McCormack wrote:
> In article <slrnl6lj3d.2...@frailea.sa.invalid>,
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
> ...
>>> Maybe it's just a Linux thing to make things incomprehensible (and then
>>> try and make out it's good coding practice!).
>>
>>I should have responded here instead of upthread: the Linux [kernel]
>>sources I've seen are nothing like this, and quite readable.
>
> Caveat: I've not looked at any of his code (either the kernel or git), but I
> have watched a talk he gave once in which he discussed (among other things)
> his coding style.
>
> The take-away from that talk was that he does have an, er, shall we say,
> "unique" coding style, and the implied statement was that you either love
> it or hate it. I get the impression that the world kinda splits about
> 50/50 into the love/hate camps.

Linus can certainly make a statement and imply anyone who disagrees is
an idiot ... but when I look at the code what I see is

- K&R style
- prefix_foo_bar naming
- TAB-indented (so indentation levels are really deep)
- lots of non-portable constructs
- no C99 constructs except heavy use of inlining (he has something
against C99; I forget what)

I find that rather conservative, after all.

[Malcolm McLean]

On Sunday, October 27, 2013 7:21:26 AM UTC, Jorgen Grahn wrote:
> On Fri, 2013-10-25, Kenny McCormack wrote:
>
>
> Linus can certainly make a statement and imply anyone who disagrees is
> an idiot ... but when I look at the code what I see is
>

He's a brilliant programmer. He's also been very lucky in that he produced
something which everyone wanted, at the right time. Programmers are notoriously
socially-challenged, partly because computers are too. They insist on having
everything right, they don't understand compromise and fudging the point
to smooth over relationships.
>
> - K&R style
>
Irritation, but something and nothing.
>
> - prefix_foo_bar naming
>
All conventions have good points and bad points. Underscores make it easier
for automatic programs to parse identifiers, but humans tend to prefer
compound words without them.

>
> - TAB-indented (so indentation levels are really deep)
>

TABs should be banned in source code. But it's something and nothing. it
does discourage you from making indention too deep.

>
> - lots of non-portable constructs
>

That doesn't matter in a kernel. It's disastrous for general C programming,
of course.

>
> - no C99 constructs except heavy use of inlining (he has something
> against C99; I forget what)
>

C99 was essentially a failure. A lot of the new features were dubious. Then
Microsoft didn't support it, so if you wanted your routines to compile on
Windows machines, you had to use the common subset of C89 and C99 anyway.

>
> I find that rather conservative, after all.
>

I'm also very conservative in coding practices.

[Keith Thompson]

Malcolm McLean <malcolm...@btinternet.com> writes:
> On Sunday, October 27, 2013 7:21:26 AM UTC, Jorgen Grahn wrote:

[...]

>> - K&R style
>>
> Irritation, but something and nothing.

A matter of opinion. Personally, I prefer K&R style brace placement,
but I'm not going to get into yet another debate about it.
Consistency is what's important.

>> - prefix_foo_bar naming
>>
> All conventions have good points and bad points. Underscores make it easier
> for automatic programs to parse identifiers, but humans tend to prefer
> compound words without them.

You're over-generalizing about what "humans" prefer. By all means
state your own opinion, but please don't assume it's universal.
(Case in point: I'm human, and I like underscores in identifiers.)

>> - TAB-indented (so indentation levels are really deep)
>>
> TABs should be banned in source code. But it's something and nothing. it
> does discourage you from making indention too deep.

There are counterarguments to this as well. And most editors can easily
be configured to adjust how tabs are displayed. At my job, the coding
standard specifies tabs for indentation and 4-column tabstops. Not my
preference, but again, consistency is more important.

>> - lots of non-portable constructs
>>
> That doesn't matter in a kernel. It's disastrous for general C programming,
> of course.
>>
>> - no C99 constructs except heavy use of inlining (he has something
>> against C99; I forget what)
>>
> C99 was essentially a failure. A lot of the new features were dubious. Then
> Microsoft didn't support it, so if you wanted your routines to compile on
> Windows machines, you had to use the common subset of C89 and C99 anyway.

Microsoft's lack of support for C99 has close to exactly zero
relevance for Linux kernel programming.

[...]

[David Brown]

On 27/10/13 11:50, Malcolm McLean wrote:
> On Sunday, October 27, 2013 7:21:26 AM UTC, Jorgen Grahn wrote:
>> On Fri, 2013-10-25, Kenny McCormack wrote:
>>
>>
>> Linus can certainly make a statement and imply anyone who disagrees is
>> an idiot ... but when I look at the code what I see is
>>
> He's a brilliant programmer. He's also been very lucky in that he produced
> something which everyone wanted, at the right time. Programmers are notoriously
> socially-challenged, partly because computers are too. They insist on having
> everything right, they don't understand compromise and fudging the point
> to smooth over relationships.
>>
>> - K&R style
>>
> Irritation, but something and nothing.
>>
>> - prefix_foo_bar naming
>>
> All conventions have good points and bad points. Underscores make it easier
> for automatic programs to parse identifiers, but humans tend to prefer
> compound words without them.
>>
>> - TAB-indented (so indentation levels are really deep)
>>
> TABs should be banned in source code. But it's something and nothing. it
> does discourage you from making indention too deep.

TABs work fine in source code. I think the traditional 8-space tab is
rather excessive - 4-space tabs gives more readable code IMHO.

/Mixing/ spaces and tabs for indentation in the same file is always
wrong - but I don't see anything wrong with tabs as long as you are
consistent.

>>
>> - lots of non-portable constructs
>>
> That doesn't matter in a kernel. It's disastrous for general C programming,
> of course.
>>
>> - no C99 constructs except heavy use of inlining (he has something
>> against C99; I forget what)

Torvalds dislikes C99 bool's, but I don't know of anything else about
C99 that he has ranted about.

>>
> C99 was essentially a failure. A lot of the new features were dubious. Then
> Microsoft didn't support it, so if you wanted your routines to compile on
> Windows machines, you had to use the common subset of C89 and C99 anyway.

MS is pretty much irrelevant in the C world - most people writing code
for Windows use something other than C (such as C++, C#, java, python,
VB, etc.). Those that need to compile C code on Windows often need
their code to be portable to other systems, and it is then easier to use
cross-platform tools like gcc or Intel's compilers. I think MSVC's lack
of C99 support annoys some people, but I doubt if many people pick C89
over C99 because of it.

I use a number of C99 features regularly, and truly hate having to go
back to C89 (as happens occasionally in my job). Key points are:

+ inline functions
+ mixing declarations and code
+ <stdbool.h>
+ <stdint.h>, including "long long" types
+ // comments

I have never felt the need for complex numbers or VLA's - and I could
live without some of the other C99 features (like designated
initialisers) if I had to.


My guess is that the biggest use of C in modern code is in embedded
systems and code for *nix systems - and I would guess that C99 is the
most commonly used standard for new code. But that's guesswork, not
statistics or surveys.

>>
>> I find that rather conservative, after all.
>>
> I'm also very conservative in coding practices.
>

Me too - but it's been quite a while since 1999.

[Keith Thompson]

David Brown <da...@westcontrol.removethisbit.com> writes:
[...]

> /Mixing/ spaces and tabs for indentation in the same file is always
> wrong - but I don't see anything wrong with tabs as long as you are
> consistent.

http://www.emacswiki.org/emacs/TabsSpacesBoth

[...]

> Torvalds dislikes C99 bool's, but I don't know of anything else about
> C99 that he has ranted about.

Linus Torvalds writes about C99 bool here
<https://lkml.org/lkml/2013/8/31/138>:
LT> I don't use "bool" in code I write. I don't think it adds any actual
LT> value, and I think the data type is badly designed and of dubious
LT> value in C. It has very few actual advantages.
LT>
LT> That said, it's not like I *hate* the type, and I won't remove bool
LT> from code other people write. I just think it's superfluous and
LT> stupid, and another case of C++ people thinking too much "this is a
LT> cool feature" without then actually doing it well. The C people then
LT> picked it up because it was less onerous than some other C++ features,
LT> and all the compilers had the logic anyway.

He makes a good point about the subtle difference in behavior between
C99's bool (_Bool) and common pre-C99 replacements like:

typedef int bool;
#define false 0
#define true 1

(personally I prefer `typedef enum { false, true } bool;`). But IMHO
it's easy enough to write code that doesn't run into those subtleties,
particularly if you avoid comparing values for equality to `true` or
`false`.

I vaguely recall that he dislikes mixing declarations and statements,
but I don't have a reference for that.

[Richard Damon]

On 10/27/13, 6:50 AM, Malcolm McLean wrote:
> TABs should be banned in source code. But it's something and nothing. it
> does discourage you from making indention too deep.
>> >

Actually, Tabs are the technological superior solution, as long as you
can be reasonably sure that everyone has editors that deal with this
properly. It allows each person to set the indent to match THEIR
preference, and reduces (slightly) the size of files.

If you can't be sure of that, then you need to resort to the fall back,
using spaces.

Perhaps Linus felt that the environment he was working with met that
condition well enough, and those few using antiquated editors would be
compelled to upgrade to something better.

[Keith Thompson]

Richard Damon <Ric...@Damon-Family.org> writes:
> On 10/27/13, 6:50 AM, Malcolm McLean wrote:
>> TABs should be banned in source code. But it's something and nothing. it
>> does discourage you from making indention too deep.
>>> >
>
> Actually, Tabs are the technological superior solution, as long as you
> can be reasonably sure that everyone has editors that deal with this
> properly. It allows each person to set the indent to match THEIR
> preference, and reduces (slightly) the size of files.

That's the argument in favor of using tabs for indentation, and
it's a valid one.

An argument for using spaces for indentation is that nobody has
to reconfigure their tools to view source code as it's intended to
be seen. A chunk of code will look the same whether I view it in
a text editor, cat it to my terminal, print it, or copy-and-paste
it into a web form.

There are advantages to tabs if they're used correctly and
consistently. I've never seen a software project maintained by
more than one person that uses tabs with complete consistency.

[wil...@wilbur.25thandclement.com]

Keith Thompson <ks...@mib.org> wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
>> On 10/27/13, 6:50 AM, Malcolm McLean wrote:
>>> TABs should be banned in source code. But it's something and nothing. it
>>> does discourage you from making indention too deep.
>>>> >
>>
>> Actually, Tabs are the technological superior solution, as long as you
>> can be reasonably sure that everyone has editors that deal with this
>> properly. It allows each person to set the indent to match THEIR
>> preference, and reduces (slightly) the size of files.
>
> That's the argument in favor of using tabs for indentation, and
> it's a valid one.
>
> An argument for using spaces for indentation is that nobody has
> to reconfigure their tools to view source code as it's intended to
> be seen. A chunk of code will look the same whether I view it in
> a text editor, cat it to my terminal, print it, or copy-and-paste
> it into a web form.

If one uses tabs for indentation and spaces for alignment, then it doesn't
matter what the tab stop is, except for perhaps line wrapping. The logic is
unassailable, and frankly I have no idea why people are reticent to adopt
that form. From the perspective of semantics or style it's the best rule...
period.

When people tell me they uses soft tabs because it makes presentation more
consistent, I want to punch them in their face. Most people have vim and
emacs configurations that reflow everything they look at (presuming they use
vim or emacs), so their point is both moot and wrong. Secondly, far too many
people have vim and emacs configurations which reflow and then save the
reflowed text. Just thinking about it makes my blood boil.

I'm a convert to tabs+spaces, so I've already eaten my humble pie.

> There are advantages to tabs if they're used correctly and
> consistently. I've never seen a software project maintained by
> more than one person that uses tabs with complete consistency.

BSD? Linux? GNU? Open source used to be predominantely tabs, and the
projects with any pedigree still are. Open source is far from a
representative sample of all code, but it's representative of code that's
publically viewable, and the consistency is there for all to see.

[BartC]

<wil...@wilbur.25thandClement.com> wrote in message
news:9lc6ka-...@wilbur.25thandClement.com...

> Keith Thompson <ks...@mib.org> wrote:

>> An argument for using spaces for indentation is that nobody has
>> to reconfigure their tools to view source code as it's intended to
>> be seen. A chunk of code will look the same whether I view it in
>> a text editor, cat it to my terminal, print it, or copy-and-paste
>> it into a web form.
>
> If one uses tabs for indentation and spaces for alignment, then it doesn't
> matter what the tab stop is, except for perhaps line wrapping. The logic
> is
> unassailable, and frankly I have no idea why people are reticent to adopt
> that form. From the perspective of semantics or style it's the best
> rule...
> period.

What do you mean by using spaces for alignment? Both tabs and spaces are
used for horizontal alignment.

The trouble with mixing tabs and spaces, is that one line might use a
4-space tab, and the next might just 4 spaces; the two lines will appear to
be aligned.

But on a different editor with an 8-space tab, they will be all over the
place.

--
bartc

[Kenny McCormack]

In article <9lc6ka-...@wilbur.25thandClement.com>,
<wil...@wilbur.25thandClement.com> wrote:
...

>When people tell me they uses soft tabs because it makes presentation more
>consistent, I want to punch them in their face.

You need to deal with your anger management issues. Or get back your meds.

Your whole posts seeths with anger (i.e., not just the above quoted line).

--
A liberal, a moderate, and a conservative walk into a bar...

Bartender says, "Hi, Mitt!"

[Ben Bacarisse]

"BartC" <b...@freeuk.com> writes:

> <wil...@wilbur.25thandClement.com> wrote in message
> news:9lc6ka-...@wilbur.25thandClement.com...
>> Keith Thompson <ks...@mib.org> wrote:
>
>>> An argument for using spaces for indentation is that nobody has
>>> to reconfigure their tools to view source code as it's intended to
>>> be seen. A chunk of code will look the same whether I view it in
>>> a text editor, cat it to my terminal, print it, or copy-and-paste
>>> it into a web form.
>>
>> If one uses tabs for indentation and spaces for alignment, then it doesn't
>> matter what the tab stop is, except for perhaps line wrapping. The
>> logic is
>> unassailable, and frankly I have no idea why people are reticent to adopt
>> that form. From the perspective of semantics or style it's the best
>> rule...
>> period.
>
> What do you mean by using spaces for alignment? Both tabs and spaces
> are used for horizontal alignment.

He means:

int my_function(const char *str, /* the string to frobnicate */
long int how_much, /* how much frobnication */ )
{
....if (!str) {
........my_other_function(str);
........return str;
....}
....frobnicate(str, how_much);
}

The leading .... show tabs (at four spaces in the case) and spaces are
spaces. The function header shows spaces used for alignment (both
leading and embedded), and these should not be replaced by tabs, ever.

> The trouble with mixing tabs and spaces, is that one line might use a
> 4-space tab, and the next might just 4 spaces; the two lines will
> appear to be aligned.

Not what he meant. Indentation is a special form of alignment for which
tabs are, technically, superior. (I say "technically" because they
don't stand up well to the social aspects of team work.) Other forms of
alignment should use spaces, as above.

<snip>
--
Ben.

[Keith Thompson]

<wil...@wilbur.25thandClement.com> writes:
> Keith Thompson <ks...@mib.org> wrote:
>> Richard Damon <Ric...@Damon-Family.org> writes:
>>> On 10/27/13, 6:50 AM, Malcolm McLean wrote:
>>>> TABs should be banned in source code. But it's something and nothing. it
>>>> does discourage you from making indention too deep.
>>>
>>> Actually, Tabs are the technological superior solution, as long as you
>>> can be reasonably sure that everyone has editors that deal with this
>>> properly. It allows each person to set the indent to match THEIR
>>> preference, and reduces (slightly) the size of files.
>>
>> That's the argument in favor of using tabs for indentation, and
>> it's a valid one.
>>
>> An argument for using spaces for indentation is that nobody has
>> to reconfigure their tools to view source code as it's intended to
>> be seen. A chunk of code will look the same whether I view it in
>> a text editor, cat it to my terminal, print it, or copy-and-paste
>> it into a web form.
>
> If one uses tabs for indentation and spaces for alignment, then it doesn't
> matter what the tab stop is, except for perhaps line wrapping. The logic is
> unassailable, and frankly I have no idea why people are reticent to adopt
> that form. From the perspective of semantics or style it's the best rule...
> period.

Try working on code that's been maintained by multiple programmers.
Your suggested convention, though it does have real advantages,
is unenforceable. I work on code written under a coding standard
that requires tabs for indentation; I see inconsistent use of tabs
and spaces all over it.

In my own code, I happen to prefer using only spaces, usually with
4-column indenntation. It works for me.

> When people tell me they uses soft tabs because it makes presentation more
> consistent, I want to punch them in their face.

[...]

I presume you're exaggerating your reaction, but it's hard to tell;
humor, if that's what it it's meant to be, doesn't always come across
well in plain text. Nothing we're discussing is that important.
Drop the violent rhetoric or be ignored.

[wil...@wilbur.25thandclement.com]

Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <9lc6ka-...@wilbur.25thandClement.com>,
> <wil...@wilbur.25thandClement.com> wrote:
> ...
>>When people tell me they uses soft tabs because it makes presentation more
>>consistent, I want to punch them in their face.
>
> You need to deal with your anger management issues. Or get back your
> meds.
>
> Your whole posts seeths with anger (i.e., not just the above quoted line).

I would have thought that somebody who has racked up your number of usenet
screeds could appreciate the scorn and passion. :P

[wil...@wilbur.25thandclement.com]

I do. Every day. Proprietary and open source. At the company I work at we
have hundreds of engineers with a tremendously large source code repository.

As for unenforceable, that equally applies to all the alternative rules, as
well. And the one-and-true-rule doesn't trump the

> In my own code, I happen to prefer using only spaces, usually with
> 4-column indenntation. It works for me.

I prefer 8. The beauty with hard tabs and the "tabs for identation and
spaces for alignment" rule is that we can both eat our cake and eat it to,
without stepping on each others' toes, unless someone's editor
programmatically converts the source code. Among large groups of engineers
with different editors, the one-and-true-rule is the most accommodating.

>> When people tell me they uses soft tabs because it makes presentation more
>> consistent, I want to punch them in their face.
> [...]
>
> I presume you're exaggerating your reaction, but it's hard to tell;
> humor, if that's what it it's meant to be, doesn't always come across
> well in plain text. Nothing we're discussing is that important.
> Drop the violent rhetoric or be ignored.

I've been posting on this forum for over 10 years. I figured I had
accumulated some social capital, but I guess not. It was off the cuff and in
jest. I apologize if I offended anyone.

I only join these identation threads once in a blue moon. They come once or
twice a year. This is my stop, however. Cheers.

[Kenny McCormack]

In article <b528ka-...@wilbur.25thandClement.com>,

Good one. Full marks to you.

I like what you said about "social capital" in your other response.

Unfortunately, nobody escapes the wrath of Kiki. If he decides to talk to
you like you were 5 years old, there's nothing you or anyone else can do
about it.

--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.

- John Kenneth Galbraith -

[Richard]

gaz...@shell.xmission.com (Kenny McCormack) writes:

> In article <b528ka-...@wilbur.25thandClement.com>,
> <wil...@wilbur.25thandClement.com> wrote:
>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>>> In article <9lc6ka-...@wilbur.25thandClement.com>,
>>> <wil...@wilbur.25thandClement.com> wrote:
>>> ...
>>>>When people tell me they uses soft tabs because it makes presentation more
>>>>consistent, I want to punch them in their face.
>>>
>>> You need to deal with your anger management issues. Or get back your
>>> meds.
>>>
>>> Your whole posts seeths with anger (i.e., not just the above quoted line).
>>
>>I would have thought that somebody who has racked up your number of usenet
>>screeds could appreciate the scorn and passion. :P
>>
>
> Good one. Full marks to you.
>
> I like what you said about "social capital" in your other response.
>
> Unfortunately, nobody escapes the wrath of Kiki. If he decides to talk to
> you like you were 5 years old, there's nothing you or anyone else can do
> about it.

I cant believe the pompous android still hasn't defrosted.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[Richard Damon]

On 10/29/13, 11:37 AM, Keith Thompson wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
>> On 10/27/13, 6:50 AM, Malcolm McLean wrote:
>>> TABs should be banned in source code. But it's something and nothing. it
>>> does discourage you from making indention too deep.
>>>>>
>>
>> Actually, Tabs are the technological superior solution, as long as you
>> can be reasonably sure that everyone has editors that deal with this
>> properly. It allows each person to set the indent to match THEIR
>> preference, and reduces (slightly) the size of files.
>
> That's the argument in favor of using tabs for indentation, and
> it's a valid one.
>
> An argument for using spaces for indentation is that nobody has
> to reconfigure their tools to view source code as it's intended to
> be seen. A chunk of code will look the same whether I view it in
> a text editor, cat it to my terminal, print it, or copy-and-paste
> it into a web form.
>
> There are advantages to tabs if they're used correctly and
> consistently. I've never seen a software project maintained by
> more than one person that uses tabs with complete consistency.
>

The argument that nobody has to reconfigure their tools doesn't work for
me, because, given the conditions, anyone competent to work on the code,
should already have their editor set the right way (or are brand new an
need to set this up as part of initial configuration).

In this environment, someone who insists on having their editor indent
with spaces is essentially telling everyone else, that only MY
preferences matter, and the heck with what anyone else might want.

My own experience is that using spaces doesn't make things much more
consistent, as some will indent 2 spaces, some 3, and some 4, so if you
pick up code from someone else code, you likely have to change your
editor anyway to make your code fit in. The only exception is if you
have a strong formatting rule with a tool to check/enforce the rule.
(and it can check for tab consistency too)

One thing that can help is if the editor will faintly distinguish
between leading tabs and leading spaces so you can see that continuation
lines start with the same indent with tabs, and then the added alignment
is done with spaces.

[Malcolm McLean]

On Friday, November 1, 2013 1:10:21 AM UTC, Richard Damon wrote:
> On 10/29/13, 11:37 AM, Keith Thompson wrote:
>
> My own experience is that using spaces doesn't make things much more
> consistent, as some will indent 2 spaces, some 3, and some 4, so if you
> pick up code from someone else code, you likely have to change your
> editor anyway to make your code fit in. The only exception is if you
> have a strong formatting rule with a tool to check/enforce the rule.
> (and it can check for tab consistency too)
>

I indent two spaces per indent, which to my mind gives the right balance
between making the indent clear and not pushing highly indented code too
fr to the right. But that preference isn't so strong that I can't read code
indented with three or four spaces, or indent four spaces if adding to code
written like that.
Tabs are a problem, however. Often, if not set correctly, the code isn't
just indented with a different setting to the one intended, it's all over
the place. Because spaces have been mixed with tabs.
Then I don't necessarily know how to set the tab stops on the editor I'm
using, and a few minutes later I might be using a different editor, because
you often don't want to set up a whole IDE just to browse come code, or
the code might shuttle between a desktop and a remote machine with console
access. Then the stops need to be set again when loading another piece of
code written with different conventions.
So I always leave editors in default mode and just cope with the inconveniences.
Tabs are nuisance, though. They're typewriter technology, they don't adapt
well to computers.

[ralph]

On Tue, 29 Oct 2013 08:37:37 -0700, Keith Thompson <ks...@mib.org>
wrote:

>Richard Damon <Ric...@Damon-Family.org> writes:
>> On 10/27/13, 6:50 AM, Malcolm McLean wrote:
>>> TABs should be banned in source code. But it's something and nothing. it
>>> does discourage you from making indention too deep.
>>>> >
>>
>> Actually, Tabs are the technological superior solution, as long as you
>> can be reasonably sure that everyone has editors that deal with this
>> properly. It allows each person to set the indent to match THEIR
>> preference, and reduces (slightly) the size of files.
>
>That's the argument in favor of using tabs for indentation, and
>it's a valid one.
>
>An argument for using spaces for indentation is that nobody has
>to reconfigure their tools to view source code as it's intended to
>be seen. A chunk of code will look the same whether I view it in
>a text editor, cat it to my terminal, print it, or copy-and-paste
>it into a web form.
>
>There are advantages to tabs if they're used correctly and
>consistently. I've never seen a software project maintained by
>more than one person that uses tabs with complete consistency.

After some thirty years of working with multi-developer projects, I
have to agree that in the long run, to maintain any semblance of
consistency, tabs need to be banned. However, no matter how diligent
one might be in enforcing a single style, there will always be someone
or some tool that travels their own path.

Thus I'm somewhat surprised that no one has mentioned the project
manager's single best tool in the battle for consistency -
beautifiers. A good example is "Artistic Style". There are others.

http://astyle.sourceforge.net/

One configures the utility to enforce the style.

Developers, CASE tools, utilites, etc. can do pretty much whatever
they want, even run their own versions to set things 'back' to what
they prefer - just as long as they run the enterprise tool before
check-in.

-ralph

[Seebs]

On 2013-11-02, ralph <nt_con...@yahoo.com> wrote:
> Thus I'm somewhat surprised that no one has mentioned the project
> manager's single best tool in the battle for consistency -
> beautifiers. A good example is "Artistic Style". There are others.
>
> http://astyle.sourceforge.net/
>
> One configures the utility to enforce the style.
>
> Developers, CASE tools, utilites, etc. can do pretty much whatever
> they want, even run their own versions to set things 'back' to what
> they prefer - just as long as they run the enterprise tool before
> check-in.

The difficulty of using such tools on Python code is one of the reasons
I don't get along with the language.

-s
--
Copyright 2013, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
Autism Speaks does not speak for me. http://autisticadvocacy.org/
I am not speaking for my employer, although they do rent some of my opinions.

[Richard Damon]

On 11/2/13, 7:29 AM, ralph wrote:
> After some thirty years of working with multi-developer projects, I
> have to agree that in the long run, to maintain any semblance of
> consistency, tabs need to be banned. However, no matter how diligent
> one might be in enforcing a single style, there will always be someone
> or some tool that travels their own path.
>
> Thus I'm somewhat surprised that no one has mentioned the project
> manager's single best tool in the battle for consistency -
> beautifiers. A good example is "Artistic Style". There are others.
>
> http://astyle.sourceforge.net/
>
> One configures the utility to enforce the style.
>
> Developers, CASE tools, utilites, etc. can do pretty much whatever
> they want, even run their own versions to set things 'back' to what
> they prefer - just as long as they run the enterprise tool before
> check-in.
>
> -ralph
>

Ralph,
The big problem with a "beautifier" is that it plays havoc with revision
control and looking at change history, as it can make so many "changes"
that you lose track of what is really different.

Normally, for a large project, this loss of history is much worse than
the damage caused by inconsistent indentation (and sometime guidelines
actually discourage fixing indentation in order to keep from polluting
the change history).

[Les Cargill]

Richard Damon wrote:
> On 11/2/13, 7:29 AM, ralph wrote:
>> After some thirty years of working with multi-developer projects, I
>> have to agree that in the long run, to maintain any semblance of
>> consistency, tabs need to be banned. However, no matter how diligent
>> one might be in enforcing a single style, there will always be someone
>> or some tool that travels their own path.
>>
>> Thus I'm somewhat surprised that no one has mentioned the project
>> manager's single best tool in the battle for consistency -
>> beautifiers. A good example is "Artistic Style". There are others.
>>
>> http://astyle.sourceforge.net/
>>
>> One configures the utility to enforce the style.
>>
>> Developers, CASE tools, utilites, etc. can do pretty much whatever
>> they want, even run their own versions to set things 'back' to what
>> they prefer - just as long as they run the enterprise tool before
>> check-in.
>>
>> -ralph
>>
>
> Ralph,
> The big problem with a "beautifier" is that it plays havoc with revision
> control and looking at change history, as it can make so many "changes"
> that you lose track of what is really different.
>

You can't insert te use of a pretty printer in the middle of a
project without being able to suffer the slings and arrows of that. You
have to consider that revision "year zero", so to speak.

> Normally, for a large project, this loss of history is much worse than
> the damage caused by inconsistent indentation (and sometime guidelines
> actually discourage fixing indentation in order to keep from polluting
> the change history).
>

Indentation per se is not a problem if you use "diff -wur" or reasonable
equivalent.

I do not recall if the patch tool accepts patches that are not in "diff
-wur" format or not.

And if you say "but that is Linux specific"... well, yeah - unless it
isn't. There is at least one port of diff for Windows.



--
Les Cargill

[Richard Damon]

On 11/2/13, 3:08 PM, Seebs wrote:
> On 2013-11-02, ralph <nt_con...@yahoo.com> wrote:
>> Thus I'm somewhat surprised that no one has mentioned the project
>> manager's single best tool in the battle for consistency -
>> beautifiers. A good example is "Artistic Style". There are others.
>>
>> http://astyle.sourceforge.net/
>>
>> One configures the utility to enforce the style.
>>
>> Developers, CASE tools, utilites, etc. can do pretty much whatever
>> they want, even run their own versions to set things 'back' to what
>> they prefer - just as long as they run the enterprise tool before
>> check-in.
>
> The difficulty of using such tools on Python code is one of the reasons
> I don't get along with the language.
>
> -s
>

Just imagine what it would do to a program written in WhiteSpace.

[Seebs]

On 2013-11-02, Richard Damon <Ric...@Damon-Family.org> wrote:
> The big problem with a "beautifier" is that it plays havoc with revision
> control and looking at change history, as it can make so many "changes"
> that you lose track of what is really different.

That depends! If you *always* use it, it reduces and/or eliminates
whitespace changes.

[James Kuyper]

On 11/02/2013 04:01 PM, Richard Damon wrote:
> On 11/2/13, 7:29 AM, ralph wrote:
>> After some thirty years of working with multi-developer projects, I
>> have to agree that in the long run, to maintain any semblance of
>> consistency, tabs need to be banned. However, no matter how diligent
>> one might be in enforcing a single style, there will always be someone
>> or some tool that travels their own path.
>>
>> Thus I'm somewhat surprised that no one has mentioned the project
>> manager's single best tool in the battle for consistency -
>> beautifiers. A good example is "Artistic Style". There are others.
>>
>> http://astyle.sourceforge.net/
>>
>> One configures the utility to enforce the style.
>>
>> Developers, CASE tools, utilites, etc. can do pretty much whatever
>> they want, even run their own versions to set things 'back' to what
>> they prefer - just as long as they run the enterprise tool before
>> check-in.
>>
>> -ralph
>>
>
> Ralph,
> The big problem with a "beautifier" is that it plays havoc with revision
> control and looking at change history, as it can make so many "changes"
> that you lose track of what is really different.

That is a serious issue to be considered when deciding to "beautify"
code for the first time. However, a policy that requires, from the
beginning, that all updates be processed by the beautifier before
check-in shouldn't have the same problems.

Exception:
Consider a file that has been beautified in accordance with the
enterprise standard rules. If it is checked out, beautified according to
developer-specific rules, and converted back according to the enterprise
standard rules, without any other modifications, does it match the file
as checked out? If there are numerous mismatches, then it will cause the
kind of problem you describe - but the solution might be to prohibit
whatever feature of the developer-specific rules was responsible for
that fact.

[James Kuyper]

On 11/02/2013 04:12 PM, Richard Damon wrote:
> On 11/2/13, 3:08 PM, Seebs wrote:

...

>> The difficulty of using such tools on Python code is one of the reasons
>> I don't get along with the language.
>>
>> -s
>>
>
> Just imagine what it would do to a program written in WhiteSpace.

Beautifiers targeting WhiteSpace would have to work VERY differently
than ones targeting C. However, there shouldn't be any additional with a
beautifier correctly targeted for WhiteSpace.

[Ian Collins]

ralph wrote:
>
> Thus I'm somewhat surprised that no one has mentioned the project
> manager's single best tool in the battle for consistency -
> beautifiers. A good example is "Artistic Style". There are others.

Any team that lets a project manager anywhere near their code is in
serious trouble!

--
Ian Collins

[Richard Damon]

If the previous poster was concerned about the tool messing up Python,
which is just moderately sensitive to changes in whitespace, a similar
tool would have no chance with a language which totally dependent on the
formation of white space.

Of course, the other question is how would you define "beautifying" for
a language that only uses invisible characters, and all printing
characters are merely comments.

[Seebs]

Amusingly, the manager I report to these days is a fairly competent
programmer, and chips in with bug fixes occasionally to help avoid
schedule slip.

And by "fairly competent" I mean "no, really, this actually helps."

[James Kuyper]

On 11/02/2013 06:53 PM, Richard Damon wrote:
> On 11/2/13, 4:41 PM, James Kuyper wrote:
>> On 11/02/2013 04:12 PM, Richard Damon wrote:

...

>>> Just imagine what it would do to a program written in WhiteSpace.
>>
>> Beautifiers targeting WhiteSpace would have to work VERY differently
>> than ones targeting C. However, there shouldn't be any additional with a

The word "problem" was supposed to follow "additional".

>> beautifier correctly targeted for WhiteSpace.
>>
>
> If the previous poster was concerned about the tool messing up Python,
> which is just moderately sensitive to changes in whitespace, a similar
> tool would have no chance with a language which totally dependent on the
> formation of white space.

For precisely that reason, a "similar tool" could not possibly qualify
as a WhiteSpace beautifier.

> Of course, the other question is how would you define "beautifying" for
> a language that only uses invisible characters, and all printing
> characters are merely comments.

True. By it's very nature, WhiteSpace is not the kind of language likely
to provoke a desire for beautification. The term "Obfuscated WhiteSpace
code" is inherently redundant. :-)
--
James Kuyper

[ralph]

On Sun, 03 Nov 2013 11:52:21 +1300, Ian Collins <ian-...@hotmail.com>
wrote:

I would suggest that any enterprise, striving for consistency, that
has a team that considers code exclusively *theirs*, is already in
trouble. <g>

-ralph

[Richard]

I'd suggest that anyone that thinks that is so far up their own arse
they shouldn't be anywhere near a competent team. The huge majority of
project managers I have worked with directly or indirectly were there
because of their programming/design/debugging/development
competence. It's not all excel jockying.

[Jorgen Grahn]

On Sun, 2013-11-03, Richard wrote:
> Ian Collins <ian-...@hotmail.com> writes:
>
>> ralph wrote:
>>>
>>> Thus I'm somewhat surprised that no one has mentioned the project
>>> manager's single best tool in the battle for consistency -
>>> beautifiers. A good example is "Artistic Style". There are others.
>>
>> Any team that lets a project manager anywhere near their code is in serious
>> trouble!
>
> I'd suggest that anyone that thinks that is so far up their own arse
> they shouldn't be anywhere near a competent team. The huge majority of
> project managers I have worked with directly or indirectly were there
> because of their programming/design/debugging/development
> competence. It's not all excel jockying.

Obviously different environments. As far as I know none of the project
managers I've worked with has had that competence (although some of
them have been very good at managing projects).

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Sat, 2013-11-02, ralph wrote:
...

> After some thirty years of working with multi-developer projects, I
> have to agree that in the long run, to maintain any semblance of
> consistency, tabs need to be banned.

My experience too, sadly.

> However, no matter how diligent
> one might be in enforcing a single style, there will always be someone
> or some tool that travels their own path.
>
> Thus I'm somewhat surprised that no one has mentioned the project
> manager's single best tool in the battle for consistency -
> beautifiers. A good example is "Artistic Style". There are others.
>
> http://astyle.sourceforge.net/
>
> One configures the utility to enforce the style.

OK, but then you need to accept a mediocre style and the associated
cost in loss of readability. As far as I can tell, running any
beautifier on good code will:

- leave 95% of the code as readable as it was
- make 5% a lot less readable
- not do anything about the really serious readability problems,
like misleading documentation or naming

Good style is not something you can program.

> Developers, CASE tools, utilites, etc. can do pretty much whatever
> they want, even run their own versions to set things 'back' to what
> they prefer - just as long as they run the enterprise tool before
> check-in.

That's a red herring; in practice you're forced to obey the codified,
mechanical style, since checkin should happen within a few seconds or
minutes after writing the code.

(On the other hand, at least once I've voted for introducing such a
mechanism. But that's only after the social mechanisms were found to
clearly not work.)

[Jorgen Grahn]

On Mon, 2013-10-28, David Brown wrote:
> On 27/10/13 11:50, Malcolm McLean wrote:
>> On Sunday, October 27, 2013 7:21:26 AM UTC, Jorgen Grahn wrote:
>>> On Fri, 2013-10-25, Kenny McCormack wrote:

[Linux kernel]

>>> ... but when I look at the code what I see is

...

>>> - no C99 constructs except heavy use of inlining (he has something
>>> against C99; I forget what)
>
> Torvalds dislikes C99 bool's, but I don't know of anything else about
> C99 that he has ranted about.

Thinking about it again, I just assumed he had ranted about C99
because he has about everything else ...

The small core of fact here is that I cannot use mixed declarations
and code at work, because the kernel build system will complain. This
might be a configuration by us or the interemediate kernel vendor, but
apparently the rest of the kernel doesn't use this C99 construct.

I can appreciate if Linus doesn't want VLAs and stuff in the kernel.
But that's possibly just because I never learned to use them myself.

[David Brown]

On 09/11/13 09:59, Jorgen Grahn wrote:
> On Mon, 2013-10-28, David Brown wrote:
>> On 27/10/13 11:50, Malcolm McLean wrote:
>>> On Sunday, October 27, 2013 7:21:26 AM UTC, Jorgen Grahn wrote:
>>>> On Fri, 2013-10-25, Kenny McCormack wrote:
>
> [Linux kernel]
>
>>>> ... but when I look at the code what I see is
>
> ...
>
>>>> - no C99 constructs except heavy use of inlining (he has something
>>>> against C99; I forget what)
>>
>> Torvalds dislikes C99 bool's, but I don't know of anything else about
>> C99 that he has ranted about.
>
> Thinking about it again, I just assumed he had ranted about C99
> because he has about everything else ...
>
> The small core of fact here is that I cannot use mixed declarations
> and code at work, because the kernel build system will complain. This
> might be a configuration by us or the interemediate kernel vendor, but
> apparently the rest of the kernel doesn't use this C99 construct.

It could well be that he doesn't like mixing declarations and code
either - while his rants are often well-publicised, I certainly don't
know /everything/ about what he doesn't like! But I didn't notice this
one in the kernel coding style guid.

[Charlton Wilbur]

>>>>> "r" == ralph <nt_con...@yahoo.com> writes:

r> Thus I'm somewhat surprised that no one has mentioned the project
r> manager's single best tool in the battle for consistency -
r> beautifiers. A good example is "Artistic Style". There are
r> others.

At $PPOE[-2] they decided early on to collaboratively develop a coding
style. When I came on the scene -- several years in -- after many
meetings to discuss, they had finally agreed that given the diversity of
editors we were using, spaces were far peferable to tabs.

It took another four years to agree to run a code formatter with
consistent and detailed specs before any check-in. Oddly enough, this
was easy to agree on.

r> Developers, CASE tools, utilites, etc. can do pretty much
r> whatever they want, even run their own versions to set things
r> 'back' to what they prefer - just as long as they run the
r> enterprise tool before check-in.

I would not refer to this as an "enterprise" tool. In my idiolect,
"enterprise" means six-figure price tag, completely useless, buggy, and
implemetned in Java glued together with XML.

Charlton


--
Charlton Wilbur
cwi...@chromatico.net

[Charlton Wilbur]

>>>>> "RD" == Richard Damon <Ric...@Damon-Family.org> writes:

RD> Ralph, The big problem with a "beautifier" is that it plays
RD> havoc with revision control and looking at change history, as it
RD> can make so many "changes" that you lose track of what is really
RD> different.

So you decide on the standard style, eat the pain once, and have one
commit where the only thing you change is the formatting.

Or you use diff tools that have an option of treating the quantity of
whitespace as irrelevant. Unix diff had this the first time it occurred
to me that it might be useful, so I have no idea how far back it goes.

[Jens Schweikhardt]

Richard Damon <Ric...@damon-family.org> wrote
in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
...
# The big problem with a "beautifier" is that it plays havoc with revision
# control and looking at change history, as it can make so many "changes"
# that you lose track of what is really different.

This argument never convinced me. If you really wanted to see minimal
diffs, simply run the revisions to be compared through the beautifier
first and then compare.

Sure, it's an extra step. But computers are great at automation, aren't
they?

Regards,

Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

[Keith Thompson]

Jens Schweikhardt <use...@schweikhardt.net> writes:
> Richard Damon <Ric...@damon-family.org> wrote
> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
> ...
> # The big problem with a "beautifier" is that it plays havoc with revision
> # control and looking at change history, as it can make so many "changes"
> # that you lose track of what is really different.
>
> This argument never convinced me. If you really wanted to see minimal
> diffs, simply run the revisions to be compared through the beautifier
> first and then compare.
>
> Sure, it's an extra step. But computers are great at automation, aren't
> they?

Sure, but inserting that extra step into the middle of multiple
existing processes isn't likely to be quite so trivial.

Some revision control systems might let you configure how diffs are
performed, but sometimes you really need to see changes in what's
actually stored in the repository.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Geoff]

On 4 Jan 2014 17:42:34 GMT, Jens Schweikhardt

<use...@schweikhardt.net> wrote:

>Richard Damon <Ric...@damon-family.org> wrote
> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
>...
># The big problem with a "beautifier" is that it plays havoc with revision
># control and looking at change history, as it can make so many "changes"
># that you lose track of what is really different.
>
>This argument never convinced me. If you really wanted to see minimal
>diffs, simply run the revisions to be compared through the beautifier
>first and then compare.
>
>Sure, it's an extra step. But computers are great at automation, aren't
>they?
>

Or better, beautify and review before commit.

[glen herrmannsfeldt]

Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Richard Damon <Ric...@damon-family.org> wrote
> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:

> # The big problem with a "beautifier" is that it plays havoc with revision
> # control and looking at change history, as it can make so many "changes"
> # that you lose track of what is really different.

> This argument never convinced me. If you really wanted to see minimal
> diffs, simply run the revisions to be compared through the beautifier
> first and then compare.

That wouldn't be bad if version control systems knew how to do it.

You want to type

svn diff ...

and see the right thing.

Otherwise, if you filter (and consider a beautifier as a filter)
then check in the result, then modify that, you can diff the befores
and afters, but not across the line.

-- glen

[Jens Schweikhardt]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote
in <laa19i$sb2$1...@speranza.aioe.org>:
# Jens Schweikhardt <use...@schweikhardt.net> wrote:
#> Richard Damon <Ric...@damon-family.org> wrote
#> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
#
#> # The big problem with a "beautifier" is that it plays havoc with revision
#> # control and looking at change history, as it can make so many "changes"
#> # that you lose track of what is really different.
#
#> This argument never convinced me. If you really wanted to see minimal
#> diffs, simply run the revisions to be compared through the beautifier
#> first and then compare.
#
# That wouldn't be bad if version control systems knew how to do it.
#
# You want to type
#
# svn diff ...
#
# and see the right thing.

How hard is it to write a three line script named svndiff that checks
out the revisions, runs indent on them and diffs the result? Then it's
even one less character to type.

One could even replace the svn binary with a script that checks
whether a diff of a C file is requested and does the above or
calls the real binary otherwise. Not exactly rocket science :-)

[Ian Collins]

Or better still don't mix style and content changes in the same commit.

--
Ian Collins

[Keith Thompson]

Agreed, but there are still problems if you want to compare
non-consecutive revisions.

Suppose version 1.1 is the initial checkin, 1.2 is a 3-line bug fix,
1.3 changes 50% of the lines for style reasons, and 1.4 has another
3-line bug fix. Comparing versions 1.1 and 1.4 to see what was
actually fixed is going to be difficult. (You can compare 1.1 to
1.2 and 1.3 to 1.4 if you happen to know that the 1.2..1.3 change
was style only, but that's not always easy to determine -- and
there's always the risk that a style-only change can accidentally
break something.)

Summary: Maintaining software is hard.

[Ian Collins]

Keith Thompson wrote:
> Ian Collins <ian-...@hotmail.com> writes:
>> Geoff wrote:
>>> On 4 Jan 2014 17:42:34 GMT, Jens Schweikhardt
>>> <use...@schweikhardt.net> wrote:
>>>
>>>> Richard Damon <Ric...@damon-family.org> wrote
>>>> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
>>>> ...
>>>> # The big problem with a "beautifier" is that it plays havoc with revision
>>>> # control and looking at change history, as it can make so many "changes"
>>>> # that you lose track of what is really different.
>>>>
>>>> This argument never convinced me. If you really wanted to see minimal
>>>> diffs, simply run the revisions to be compared through the beautifier
>>>> first and then compare.
>>>>
>>>> Sure, it's an extra step. But computers are great at automation, aren't
>>>> they?
>>>
>>> Or better, beautify and review before commit.
>>
>> Or better still don't mix style and content changes in the same commit.
>
> Agreed, but there are still problems if you want to compare
> non-consecutive revisions.
>
> Suppose version 1.1 is the initial checkin, 1.2 is a 3-line bug fix,
> 1.3 changes 50% of the lines for style reasons, and 1.4 has another
> 3-line bug fix. Comparing versions 1.1 and 1.4 to see what was
> actually fixed is going to be difficult.

On my projects that's normally done by checking which unit tests were
added between revisions. Comparing tests is a lot easier than diffing
code, which is something I seldom do.

Where unit tests aren't used (tut tut), the webrev or equivalent
generated for reviews are the bet documentation for changes.

--
Ian Collins

[glen herrmannsfeldt]

Keith Thompson <ks...@mib.org> wrote:

(snip)

>>>> Richard Damon <Ric...@damon-family.org> wrote
>>>> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
>>>> ...
>>>> # The big problem with a "beautifier" is that it plays havoc with revision
>>>> # control and looking at change history, as it can make so many "changes"
>>>> # that you lose track of what is really different.

(snip, someone wrote)

>> Or better still don't mix style and content changes in the same commit.

> Agreed, but there are still problems if you want to compare
> non-consecutive revisions.

> Suppose version 1.1 is the initial checkin, 1.2 is a 3-line bug fix,
> 1.3 changes 50% of the lines for style reasons, and 1.4 has another
> 3-line bug fix. Comparing versions 1.1 and 1.4 to see what was
> actually fixed is going to be difficult.

You need a diff that can generate the appropriate differences.

> (You can compare 1.1 to
> 1.2 and 1.3 to 1.4 if you happen to know that the 1.2..1.3 change
> was style only, but that's not always easy to determine -- and
> there's always the risk that a style-only change can accidentally
> break something.)

If this problem is real, then version control systems should adapt
for it. It should be possible to commit a change as style only.
The system would remember that, and, if not give the appropriate
diff, warn you where the style reversions are so you can do the
appropriate diff yourself.

I would expect most diff requests are consecutive versions, but one
still has to be sure to check-in the style-only change.

> Summary: Maintaining software is hard.

-- glen

[Kaz Kylheku]

On 2013-11-02, Richard Damon <Ric...@Damon-Family.org> wrote:

> Normally, for a large project, this loss of history is much worse than
> the damage caused by inconsistent indentation (and sometime guidelines
> actually discourage fixing indentation in order to keep from polluting
> the change history).

I use this program, in conjunction with Vim:

http://www.kylheku.com/cgit/c-snippets/tree/autotab.c

This is geared toward languages which resemble C. (Patches, suggestions,
critisms welcome).

With the help of this utility, I instantly conform to the indentation style of
the source file that I load into Vim's buffer.

Without this program, I would go crazy working with multiple code bases that
have different conventions, and with inconsistent conventions within the same
project.

Worse, I might accidentally introduce edits which use a different style; for
instance spaces when the existing code uses hard tabs or vice versa.

Conforming to the exiting style is more important than enforcing one.

If a project contains numerous files that are inconsistently formatted
internally, it may be a good idea to fix them. It should be discussed with the
team; you don't just go in and reindent everything. Since the changes may
cause merge conflicts, cleanup work should be coordinated with the release
management process. For instance, if you still have an old branch that is
active (bugs are being fixed for customers and then integrated into the
mainline), then maybe hold off with the whitespace changes, so that changes can
back- and forward-port easily.

It's also a poor idea to mix whitespace changes with an actual code change,
needless to add.

[James Kuyper]

On 01/04/2014 07:35 PM, glen herrmannsfeldt wrote:
...

> If this problem is real, then version control systems should adapt
> for it. It should be possible to commit a change as style only.
> The system would remember that, and, if not give the appropriate
> diff, warn you where the style reversions are so you can do the
> appropriate diff yourself.

I'm familiar with only a few version control systems: RCS, CVS,
ClearCase, and SubVersion, and one other system whose name I can't
remember which was built on an RCS foundation. If any of them had the
capability of doing what you suggest, I wasn't aware of the fact. It
seems to me that, in order to work that way, the version control system
would have to know about the source code syntax, in order to properly
distinguish between meaningful and cosmetic changes - I don't believe
that any of the systems I'm familiar with knew or cared anything about
the syntax of the documents being controlled.

> I would expect most diff requests are consecutive versions, ...

That has not been my experience.
--
James Kuyper

[ralph]

On Sat, 04 Jan 2014 13:01:37 -0800, Keith Thompson <ks...@mib.org>
wrote:

>Jens Schweikhardt <use...@schweikhardt.net> writes:
>> Richard Damon <Ric...@damon-family.org> wrote
>> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
>> ...
>> # The big problem with a "beautifier" is that it plays havoc with revision
>> # control and looking at change history, as it can make so many "changes"
>> # that you lose track of what is really different.
>>
>> This argument never convinced me. If you really wanted to see minimal
>> diffs, simply run the revisions to be compared through the beautifier
>> first and then compare.
>>
>> Sure, it's an extra step. But computers are great at automation, aren't
>> they?
>
>Sure, but inserting that extra step into the middle of multiple
>existing processes isn't likely to be quite so trivial.
>
>Some revision control systems might let you configure how diffs are
>performed, but sometimes you really need to see changes in what's
>actually stored in the repository.

Wow! Wait long enough and everything DOES happen.

Something I can agree with Mr. Thompson on. <g>

Before every "cleanup" - people like me are only called in when it is
already a mess <g> - I try to make that very clear - if one is
dependent on tracking miniscule variance, enforcing beauty in the
middle is going to be very very annoying.

Everyone always signs off - then the emails start coming. LOL

If the object is just to be prettier exclusively, its best to leave it
alone and keep complaining. Modern beautifiers are capable of a range
of adjustment (as well as modern SCCSs), but neither will solve
everything. It has to be combined with a complete library, resource,
etc. re-arrangement. Policies will be changed, new 'standards'
adopted. Resources get that way because no one was paying attention
from the beginning. Do it from the beginning and it goes well.
Sometimes you just go to a new beginning. Sometimes the budget just
won't let you.

And before we go into inventing too many scenerios that may break thus
invalidate going there - one needs to consider the industry. A large
argiculture or banking institute with a vast library of multiple
versioned bonded or certified products does not have to face the same
issues (risk) as a place selling ZombieBarbie games with only one or
two on the shelf at any one time.

It like everything else in this industry. There are trade-offs each
with its own risks, complexity, and headaches.

-ralph

[Jorgen Grahn]

On Sat, 2014-01-04, Keith Thompson wrote:
> Jens Schweikhardt <use...@schweikhardt.net> writes:
>> Richard Damon <Ric...@damon-family.org> wrote
>> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
>> ...
>> # The big problem with a "beautifier" is that it plays havoc with revision
>> # control and looking at change history, as it can make so many "changes"
>> # that you lose track of what is really different.
>>
>> This argument never convinced me. If you really wanted to see minimal
>> diffs, simply run the revisions to be compared through the beautifier
>> first and then compare.
>>
>> Sure, it's an extra step. But computers are great at automation, aren't
>> they?
>
> Sure, but inserting that extra step into the middle of multiple
> existing processes isn't likely to be quite so trivial.

True. Diffing is not just about comparing files A and B; you want it
to work with entire directory trees, and you want to do it quickly.
The automation would have to happen inside the source control tool.

> Some revision control systems might let you configure how diffs are
> performed

Some, yes. But I don't think I've encountered one so far, if you
don't count "ignore changes in amount of whitespace" which most seem
to implement.

[Richard]

Jorgen Grahn <grahn...@snipabacken.se> writes:

>> Some revision control systems might let you configure how diffs are
>> performed
>
> Some, yes. But I don't think I've encountered one so far, if you
> don't count "ignore changes in amount of whitespace" which most seem
> to implement.
>
> /Jorgen

Then you havent looked around. Numerous allow you to tailor the diff
tool and its corresponding parameters. Not least git.

[Jorgen Grahn]

On Sat, 2014-01-04, Jens Schweikhardt wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote
> in <laa19i$sb2$1...@speranza.aioe.org>:
> # Jens Schweikhardt <use...@schweikhardt.net> wrote:
> #> Richard Damon <Ric...@damon-family.org> wrote
> #> in <PScdu.20235$SO1....@en-nntp-06.dc1.easynews.com>:
> #
> #> # The big problem with a "beautifier" is that it plays havoc with revision
> #> # control and looking at change history, as it can make so many "changes"
> #> # that you lose track of what is really different.
> #
> #> This argument never convinced me. If you really wanted to see minimal
> #> diffs, simply run the revisions to be compared through the beautifier
> #> first and then compare.
> #
> # That wouldn't be bad if version control systems knew how to do it.
> #
> # You want to type
> #
> # svn diff ...
> #
> # and see the right thing.
>
> How hard is it to write a three line script named svndiff that checks
> out the revisions, runs indent on them and diffs the result?

Try it. It's rather tricky to do in a safe and robust way. And then
you'd have to teach people to use it and not any of the Subversion
tools ...

I once had to to it for ClearCase (which doesn't have a normal diff
tool which works on entire directory hierarchies). I got it working
well enough so I could use it myself, but you had to be careful or
you'd fill a disk or corrupt your working directory ...