5 ms·

I think these guidelines are something every C programmer should atleast have read and reflected about. I've been coding according to these guidelines for quit

• nerdponx 9y ago
  80 char width helps encourage you to "do less stuff in each line", rather than "break lines at 80 chars". But I agree, after a few levels of indentation (which is sometimes unavoidable) you end up struggling.
  • dingo_bat 9y ago
    Also, when a function takes five arguments, and each_argument_looks_like_this, it's easy to hit 80 chars!
    • _asummers 9y ago
      Depending on the verbosity of the name, even a no arg function might exceed 80+ chars. We have a few instances of test convenience functions in our non-C code base, though they're exceedingly rare.
    • quickben 9y ago
      Maybe pass them in a struct?
      • CalChris 9y ago
        As long as you give up all hope that you'll be passing values in registers.
        • quotemstr 9y ago
          Most of the time, it doesn't matter. And if you have lots of arguments, you're going to spill anyway.
        • dllthomas 9y ago
          If the call doesn't cross compilation units, you still might. Or possibly with LTO, but I've less experience there. That said, it's certainly a concern worth being aware of where it's relevant.
      • disconnected 9y ago
        The linux kernel USB API has a few functions that take a bunch of arguments. For example: int usb_control_msg(struct usb_device * dev, unsigned int pipe, __u8 request, __u8 requesttype, __u16 value, __u16 index, void * data, __u16 size, int timeout); So it is kind of hard to avoid going over the limit. What we end up doing is break each argument into one line, like this (I hope the formatting comes out all right): int res = usb_control_msg( dev, usb_sndctrlpipe(dev, 0), 0x41, ... ); It's not so much of an eye-sore.
        • quickben 9y ago
          Ahhhh I see. Nortel had that coding guideline actually. Just in their case, the first argument followed the parenthesis. The second argument (and the rest) followed the first argument column.
        • dllthomas 9y ago
          That's a good approach, as can be the struct. An option not mentioned yet is to give things smaller local names.
  • dahart 9y ago
    Those are good reasons. The reason I accept an 80 char limit, even if I prefer longer lines, is because it affects everyone else. Short lines will always fit, in every editor, in every terminal, over ssh, etc.. Long lines, anything over 80, will compromise some workflow somewhere. Long lines will generally mess with someone's flow, and they become more inconvenient for more people the longer the lines get.
    • dllthomas 9y ago
      > over ssh Line length isn't going to have much impact on what fits over ssh...
      • dahart 9y ago
        True, thanks. Did you not know what I meant? "in every terminal, over ssh". Line length can affect my use of grep as much as it can affect remote vi sessions. I'm not talking about the protocol, I'm talking about the existence of multiple workflows that are all affected by line length conventions. The edit/compile cycle in your favorite IDE isn't the only consideration, and I'm not the only person to consider when I decide how long my lines should be.
        • dllthomas 9y ago
          SSH is only relevant in that it might provide an additional motivation for operating in the terminal, in some cases. That said, yes, I was picking a nit mostly because the nit itself amused me (and I hoped it would amuse others) - it wasn't meant as significant criticism of your post.
• dankohn1 9y ago
  You can say that enforcing an 80 character line is outdated, but I often find myself looking at code reviews in GitHub on my smartphone, and it dramatically improves readability in that environment.
  • dimman 9y ago
    I haven't said it's outdated though just that I don't always follow it. Desktop Github version seems to show 125 chars (including -+) and on my iphone I'm below 50 char width by default. I just prioritize to have "readable" code in my editor as first prio, second would be sites like Github on desktop and if it works good on a mobile phone that's a plus but not high prio for me. (To be honest though I do actually glance through some Github reviews on my phone, but since it's pretty limited I do find myself thinking that I should get to a computer and do a real review there instead.)
    • dankohn1 9y ago
      I turn my phone to landscape first. And, yes, if any meaningful comments are needed I wait until I'm back at my laptop.