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

[Seebs]

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

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."

-s

 

[Les Cargill]

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.

 

[Jorgen Grahn]

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]

.

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

 

[Jorgen Grahn]

[Linux kernel]

....


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.

/Jorgen

 

[Charlton Wilbur]

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]

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.

Charlton

 

[Jens Schweikhardt]

in <[email protected]>:
....
# 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

 

[Keith Thompson]

in <[email protected]>:
...
# 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.

 

[Geoff]

in <[email protected]>:
...
# 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]

in <[email protected]>:

# 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]

in <[email protected]>:
#> in <[email protected]>:
#
#> # 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

Regards,

Jens

 

[Ian Collins]

Or better, beautify and review before commit.

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

 

[Keith Thompson]

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 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]

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.

 

[glen herrmannsfeldt]

(snip)
(snip, someone wrote)

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]

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.

 

[Jorgen Grahn]

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.

/Jorgen

 

[Jorgen Grahn]

in <[email protected]>:
#> in <[email protected]>:
#
#> # 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 ...

/Jorgen