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

Discussion in 'C Programming' started by randy, Oct 23, 2013.

  1. randy

    Seebs Guest

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

    Seebs, Nov 3, 2013
    1. Advertisements

  2. randy

    Les Cargill Guest

    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.

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

    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, Nov 3, 2013
    1. Advertisements

  3. randy

    Jorgen Grahn Guest

    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 Grahn, Nov 6, 2013
  4. randy

    Jorgen Grahn Guest

    My experience too, sadly.
    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.
    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, Nov 6, 2013
  5. randy

    Jorgen Grahn Guest

    [Linux kernel]
    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 Grahn, Nov 9, 2013
  6. 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 Wilbur, Nov 11, 2013
  7. 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 Wilbur, Nov 11, 2013
  8. in <PScdu.20235$>:
    # 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


    Jens Schweikhardt, Jan 4, 2014
  9. 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, Jan 4, 2014
  10. randy

    Geoff Guest

    Or better, beautify and review before commit.
    Geoff, Jan 4, 2014
  11. 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
    glen herrmannsfeldt, Jan 4, 2014
  12. in <laa19i$sb2$>:
    #> in <PScdu.20235$>:
    #> # 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 :)


    Jens Schweikhardt, Jan 4, 2014
  13. randy

    Ian Collins Guest

    Or better still don't mix style and content changes in the same commit.
    Ian Collins, Jan 4, 2014
  14. 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.
    Keith Thompson, Jan 4, 2014
  15. randy

    Ian Collins Guest

    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, Jan 5, 2014
  16. (snip)
    (snip, someone wrote)
    You need a diff that can generate the appropriate differences.
    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.
    -- glen
    glen herrmannsfeldt, Jan 5, 2014
  17. randy

    Kaz Kylheku Guest

    I use this program, in conjunction with Vim:

    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

    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.
    Kaz Kylheku, Jan 5, 2014
  18. randy

    James Kuyper Guest

    On 01/04/2014 07:35 PM, glen herrmannsfeldt wrote:
    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.
    That has not been my experience.
    James Kuyper, Jan 5, 2014
  19. randy

    Jorgen Grahn Guest

    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, 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 Grahn, Jan 7, 2014
  20. randy

    Jorgen Grahn Guest

    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 Grahn, Jan 7, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.