5 ms·

OS code has to do a lot of validating input and braceful style causes functions to be visually dominated by boring validation code. It's also surprisingly nice

by gosu 13y ago

OS code has to do a lot of validating input and braceful style causes functions to be visually dominated by boring validation code. It's also surprisingly nice to have a visual distinction between boring conditions like if(!found) return; and the more interesting branches that require the braces. Not sure I follow you on the one; two; example. Why would you have two statements per line in the first place? (You do realize that the "two;" isn't in the if block, right?)

shin_lao 13y ago
Because developer one wrote if (statement) one; And developper two added if (statement) one; two; too quickly
- jomar 13y ago
  The actual problem there is that developer two checked something in without thinking about it, reading it, or examining the diffs of the change. If you had a coding convention of always using braces in if statements, you might be insulated from this particular symptom or instance of the problem, but you still have the underlying problem that people are doing things without thinking.
  - qznc 13y ago
    "you still have the underlying problem that people are doing things without thinking" You can solve this problem?
  - zimpenfish 13y ago
    Why not take advantage of every safety net you can? People are fallible, mistakes get made.
    - loup-vaillant 13y ago
      Because if you do, the safety net will collapse your circus tent by their sheer weight. The actual argument has been made in sibling comments: braces are verbose, and the mistake we speak of is exceedingly rare in practice. For simple one-liners, the verbosity costs more than the lack of safety net.
- mercurial 13y ago
  Sure, but how often does this happen in practice? I have worked with 'no convention'/'multiple conventions'/'mostly no braces for single statements' and have never seen this particular mistake. I can see how it would be difficult to track down, on the other hand, braces for single comments add to line noise.
  - barrkel 13y ago
    I've worked on multi-million line projects and have also never seen this mistake made. So in my experience, it is so vanishingly rare that the costs in visual gunk and decreased code density are not worth it. A lint tool checking for suspicious indentation would be a better use of labour.
  - k3n 13y ago
    I've encountered it just enough times to avoid it 100%. I think in my scenario, the problems have been compounded by an overall lax (lazy) coding style on the part of my predecessors, in that many of them were junior devs who virtually made-up their own coding styles. These devs treated whitespace like it cost money, and avoided any unrequired use of spaces, tabs, and newlines. These types of conventions -- no curlies around simple blocks -- aren't too bad if a) your devs are adequately seasoned, and b) your devs believe in whitespace. For instance, this isn't really so bad: if (foo) foo(); else bar(); Hell, that's clean! But it's stuff like this that causes issues: if(foo)foo(); else bar(); Sometimes I'm lucky and find this: if (foo) foo(); else { bar(); baz(); } The best is abominations like this though; first, the sane formatting: if (foo) while (i++ < x) foo(i); else bar(); Or, as I have found it: if(foo)while(i++<x)foo(i); else bar(); Seriously, that's enough for me to revoke commit privs.
  - to3m 13y ago
    I've seen it once, in 13 years of working professionally in C. I think two people changed the same one-line if statement, but for two different reasons (probably adding two different new features to the same bit of code). And after an automatic merge it became something like this: if(flag) set_other_flag=1; call_function(); (both lines necessary) Anyway, it didn't take long to narrow it down to that bit of code but it took a few more minutes to figure out why the function was always getting called. I couldn't work out what was going on until I looked at the disassembly and was forced to reassess my opinion of what code was actually being compiled. Too much python in my diet, perhaps. I remember being surprised at the time that it had taken so long for this to happen, and I made a mental note to keep an eye out for more occurrences. That was summer 2006, and I haven't seen it happen since.
- mosburger 13y ago
  stuff like this can happen if you're not careful w/ preprocessor macros too. #define one a;b; if (statement) one;
- gosu 13y ago
  I think that such a developer would be equally as likely to forget to free() memory or overflow a buffer. I assume that the reasoning is that people who don't know C well enough or are too forgetful shouldn't be working on the Plan9 codebase anyway, so why optimize for such a bad case when there are definite costs to doing so (as I mentioned before)?

by gosu 13y ago

shin_lao 13y ago

Because developer one wrote if (statement) one; And developper two added if (statement) one; two; too quickly

jomar 13y ago
The actual problem there is that developer two checked something in without thinking about it, reading it, or examining the diffs of the change. If you had a coding convention of always using braces in if statements, you might be insulated from this particular symptom or instance of the problem, but you still have the underlying problem that people are doing things without thinking.
- qznc 13y ago
  "you still have the underlying problem that people are doing things without thinking" You can solve this problem?
- zimpenfish 13y ago
  Why not take advantage of every safety net you can? People are fallible, mistakes get made.
  - loup-vaillant 13y ago
    Because if you do, the safety net will collapse your circus tent by their sheer weight. The actual argument has been made in sibling comments: braces are verbose, and the mistake we speak of is exceedingly rare in practice. For simple one-liners, the verbosity costs more than the lack of safety net.
mercurial 13y ago
Sure, but how often does this happen in practice? I have worked with 'no convention'/'multiple conventions'/'mostly no braces for single statements' and have never seen this particular mistake. I can see how it would be difficult to track down, on the other hand, braces for single comments add to line noise.
- barrkel 13y ago
  I've worked on multi-million line projects and have also never seen this mistake made. So in my experience, it is so vanishingly rare that the costs in visual gunk and decreased code density are not worth it. A lint tool checking for suspicious indentation would be a better use of labour.
- k3n 13y ago
  I've encountered it just enough times to avoid it 100%. I think in my scenario, the problems have been compounded by an overall lax (lazy) coding style on the part of my predecessors, in that many of them were junior devs who virtually made-up their own coding styles. These devs treated whitespace like it cost money, and avoided any unrequired use of spaces, tabs, and newlines. These types of conventions -- no curlies around simple blocks -- aren't too bad if a) your devs are adequately seasoned, and b) your devs believe in whitespace. For instance, this isn't really so bad: if (foo) foo(); else bar(); Hell, that's clean! But it's stuff like this that causes issues: if(foo)foo(); else bar(); Sometimes I'm lucky and find this: if (foo) foo(); else { bar(); baz(); } The best is abominations like this though; first, the sane formatting: if (foo) while (i++ < x) foo(i); else bar(); Or, as I have found it: if(foo)while(i++<x)foo(i); else bar(); Seriously, that's enough for me to revoke commit privs.
- to3m 13y ago
  I've seen it once, in 13 years of working professionally in C. I think two people changed the same one-line if statement, but for two different reasons (probably adding two different new features to the same bit of code). And after an automatic merge it became something like this: if(flag) set_other_flag=1; call_function(); (both lines necessary) Anyway, it didn't take long to narrow it down to that bit of code but it took a few more minutes to figure out why the function was always getting called. I couldn't work out what was going on until I looked at the disassembly and was forced to reassess my opinion of what code was actually being compiled. Too much python in my diet, perhaps. I remember being surprised at the time that it had taken so long for this to happen, and I made a mental note to keep an eye out for more occurrences. That was summer 2006, and I haven't seen it happen since.
mosburger 13y ago
stuff like this can happen if you're not careful w/ preprocessor macros too. #define one a;b; if (statement) one;
gosu 13y ago
I think that such a developer would be equally as likely to forget to free() memory or overflow a buffer. I assume that the reasoning is that people who don't know C well enough or are too forgetful shouldn't be working on the Plan9 codebase anyway, so why optimize for such a bad case when there are definite costs to doing so (as I mentioned before)?