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

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

  1. 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?
    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 Bacarisse, Oct 26, 2013
    #21
    1. Advertisements

  2. randy

    BartC Guest

    And possibly from Radix-50 on 16 and 32-bit ones.
     
    BartC, Oct 26, 2013
    #22
    1. Advertisements

  3. With time, and counselling, I may one day... oh, I'm over it. You did
    see "It's hardly a big deal" yes?
    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 Bacarisse, Oct 27, 2013
    #23
  4. You were there? Can you expand on that?
     
    Keith Thompson, Oct 27, 2013
    #24
  5. randy

    Jorgen Grahn Guest

    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.[/QUOTE]

    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.

    /Jorgen
     
    Jorgen Grahn, Oct 27, 2013
    #25
  6. 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.
    Irritation, but something and nothing.
    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.
    TABs should be banned in source code. But it's something and nothing. it
    does discourage you from making indention too deep.
    That doesn't matter in a kernel. It's disastrous for general C programming,
    of course.
    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'm also very conservative in coding practices.
     
    Malcolm McLean, Oct 27, 2013
    #26
  7. 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.
    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.)
    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.
    Microsoft's lack of support for C99 has close to exactly zero
    relevance for Linux kernel programming.

    [...]
     
    Keith Thompson, Oct 27, 2013
    #27
  8. 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.

    [...]
     
    Keith Thompson, Oct 28, 2013
    #28
  9. 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.
     
    Keith Thompson, Oct 29, 2013
    #29
  10. randy

    BartC Guest

    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, Oct 30, 2013
    #30
  11. 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).
     
    Kenny McCormack, Oct 30, 2013
    #31
  12. 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.
    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 Bacarisse, Oct 30, 2013
    #32
  13. 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.
    [...]

    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.
     
    Keith Thompson, Oct 30, 2013
    #33
  14. 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.
     
    Kenny McCormack, Oct 30, 2013
    #34
  15. 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.
     
    Malcolm McLean, Nov 1, 2013
    #35
  16. randy

    Seebs Guest

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

    -s
     
    Seebs, Nov 2, 2013
    #36
  17. randy

    Seebs Guest

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

    -s
     
    Seebs, Nov 2, 2013
    #37
  18. randy

    James Kuyper Guest

    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, Nov 2, 2013
    #38
  19. randy

    James Kuyper Guest

    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.
     
    James Kuyper, Nov 2, 2013
    #39
  20. randy

    Ian Collins Guest

    Any team that lets a project manager anywhere near their code is in
    serious trouble!
     
    Ian Collins, Nov 2, 2013
    #40
    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.