5 ms·

My point is that when you are writing complicated production code, and you are a good programmer such that your rate of features successfully implemented is hig

by jblow 14y ago

My point is that when you are writing complicated production code, and you are a good programmer such that your rate of features successfully implemented is high, then you will often be going to old code and changing that code to behave somewhat differently than it was before. When you do this, you want that old code to be like putty. You want to bend it into a new shape without having to break it and start over. Sometimes it really is better to break it, if bending would be too messy or cause problems later or otherwise sets off a red flag in your head. But if you have to break and re-make everything all the time, you won't be a very fast programmer. So you learn how to bend things, elegantly. And after a while of this, you learn how to write code that is more amenable to elegant bending in the first place. When you type code, you are not just implementing a specific piece of functionality; you are implementing that functionality plus provision for unknown future times when you will need to come back and make the code different. (To link this more thoroughly to the previous comment: it happens all the time that you write code that is not really about doing stuff, but then you later need to make that code be about doing stuff. Sometimes this is for shipping functionality reasons, sometimes it is just to temporarily insert hooks for debugging. Declaring in advance that this code shall never be about doing stuff is usually a mistake.)

georgeorwell 14y ago
It strikes me that your argument taken to the extreme is that everybody should program in assembly language because you can do anything, anytime, anywhere. Well, at least as far as control flow structures are concerned. Certainly C is preferable to C++ if you want simple and malleable code. Do you also prefer if-else to switch statements? (I'm not sure.) Do you like to use goto? (I doubt it.) Do you eschew the use of classes and inheritance? (I doubt it.) Do you keep all your code in one file? (I'd be very surprised.) My point with these semi-facetious questions is that structure is important and regularity in a codebase does wonders for comprehensibility and maintainability. I agree with you for the case in which you do actually have something where the underlying structure is likely to change, in that then it does make sense to write it with malleability in mind. Consider something like command line options processing. You have 50 options. You might want a 51st option. It makes sense to use the most regular structures you can so that people don't start special-casing stuff in the middle of it all. That, or to use an options library that defines the allowable formats for you. Part of me thinks you're just having an allergic reaction to ?: simply because it is pretty unusual the first time you see it used seriously. But it can simplify so much: Compare: if (a) { return b; } return c; to: return a ? b : c;
- npsimons 14y ago
  Not to mention that it's essential for initializing some constant variables; I have yet to find a better way to do: const int count = argc > 1 ? atoi(argv[1]) : 1000000; For quick test programs where I might want to change some number of iterations without having to recompile, but I also don't want to have to provide an argument every time I run it.
  - johnbellone 14y ago
    You're assuming that the first argument here is an integer value. For a single, one off, testing haress application I wouldn't worry too much about applying a full-blown semantic code style. Is there anything wrong with keeping the default value as a separate constant? const int kDefaultValue = 1000000; int value = kDefaultValue; if (argc > 1) { value = std::atoi(argv[1]); } const int count = value; Personally I much prefer using [program options][1] from the boost project (since we are talking about C++ here). Most projects already have this as a dependency, and its quite easy to setup. It also properly handles your types. [1]: http://www.boost.org/doc/libs/1_52_0/doc/html/program_options.html http://www.boost.org/doc/libs/1_52_0/doc/html/program_option...
    - npsimons 14y ago
      Perhaps I should have clarified: when I said quick test program, I was referring to something I would write to convince myself of some minor detail (sometimes just checking compiler warts or algorithm performance) and that piece of code would never be seen or run by anyone but me. I know that the first argument will always be an integer, because I'm the only one who will pass it arguments! I'm also (kind of unreasonably) a const nazi. So given the option, where I can take a shortcut (I know, bad, bad programmer), but still do "proper" programming (consting everything by default is my SOP), I'll do it. And I'll never release that code (I'm starting to regret posting that snippet here . . .). I will agree, though, option parsing libraries are a definite must for released software. I like Boost, but using even small parts of it tends to pull everything in, and at least for my current project, we are trying to minimize dependencies (it's a library). I had to fight for Boost::regex, and only got it as a fallback for compiler versions that don't have regex.
Garoof 14y ago
Note that my response was mainly to the "hard to understand because questionmarks" part of your post. I think that's a pretty weak argument, and that being clear about which part of the code depends on the ifs easily makes up for weird syntax or whatever. The "that is goofy, this is mature" stuff is ridicilous. I get that there are other reasons for sometimes choosing if-statements instead of if-expressions in cases like this. But then it quickly comes down to a bunch of technicalities (language can't do this, debugger can't do that, ...), and really, even if we're talking C++ stuff only I would not agree with it as general advice.

by jblow 14y ago

georgeorwell 14y ago

It strikes me that your argument taken to the extreme is that everybody should program in assembly language because you can do anything, anytime, anywhere. Well, at least as far as control flow structures are concerned. Certainly C is preferable to C++ if you want simple and malleable code. Do you also prefer if-else to switch statements? (I'm not sure.) Do you like to use goto? (I doubt it.) Do you eschew the use of classes and inheritance? (I doubt it.) Do you keep all your code in one file? (I'd be very surprised.) My point with these semi-facetious questions is that structure is important and regularity in a codebase does wonders for comprehensibility and maintainability. I agree with you for the case in which you do actually have something where the underlying structure is likely to change, in that then it does make sense to write it with malleability in mind. Consider something like command line options processing. You have 50 options. You might want a 51st option. It makes sense to use the most regular structures you can so that people don't start special-casing stuff in the middle of it all. That, or to use an options library that defines the allowable formats for you. Part of me thinks you're just having an allergic reaction to ?: simply because it is pretty unusual the first time you see it used seriously. But it can simplify so much: Compare: if (a) { return b; } return c; to: return a ? b : c;

npsimons 14y ago
Not to mention that it's essential for initializing some constant variables; I have yet to find a better way to do: const int count = argc > 1 ? atoi(argv[1]) : 1000000; For quick test programs where I might want to change some number of iterations without having to recompile, but I also don't want to have to provide an argument every time I run it.
- johnbellone 14y ago
  You're assuming that the first argument here is an integer value. For a single, one off, testing haress application I wouldn't worry too much about applying a full-blown semantic code style. Is there anything wrong with keeping the default value as a separate constant? const int kDefaultValue = 1000000; int value = kDefaultValue; if (argc > 1) { value = std::atoi(argv[1]); } const int count = value; Personally I much prefer using [program options][1] from the boost project (since we are talking about C++ here). Most projects already have this as a dependency, and its quite easy to setup. It also properly handles your types. [1]: http://www.boost.org/doc/libs/1_52_0/doc/html/program_options.html http://www.boost.org/doc/libs/1_52_0/doc/html/program_option...
  - npsimons 14y ago
    Perhaps I should have clarified: when I said quick test program, I was referring to something I would write to convince myself of some minor detail (sometimes just checking compiler warts or algorithm performance) and that piece of code would never be seen or run by anyone but me. I know that the first argument will always be an integer, because I'm the only one who will pass it arguments! I'm also (kind of unreasonably) a const nazi. So given the option, where I can take a shortcut (I know, bad, bad programmer), but still do "proper" programming (consting everything by default is my SOP), I'll do it. And I'll never release that code (I'm starting to regret posting that snippet here . . .). I will agree, though, option parsing libraries are a definite must for released software. I like Boost, but using even small parts of it tends to pull everything in, and at least for my current project, we are trying to minimize dependencies (it's a library). I had to fight for Boost::regex, and only got it as a fallback for compiler versions that don't have regex.

Garoof 14y ago

Note that my response was mainly to the "hard to understand because questionmarks" part of your post. I think that's a pretty weak argument, and that being clear about which part of the code depends on the ifs easily makes up for weird syntax or whatever. The "that is goofy, this is mature" stuff is ridicilous. I get that there are other reasons for sometimes choosing if-statements instead of if-expressions in cases like this. But then it quickly comes down to a bunch of technicalities (language can't do this, debugger can't do that, ...), and really, even if we're talking C++ stuff only I would not agree with it as general advice.