4 ms·

I've got a missing class, for a 5 line function called from one place? I suppose I can see your point of view, but I'm not sure I agree. On your second point,

I've got a missing class, for a 5 line function called from one place? I suppose I can see your point of view, but I'm not sure I agree. On your second point, I do disagree. I like to view all functions, even internals one, as having a documented API, covering things like bad inputs. This means that all functions (in debugging/assertion mode at least) promise to sanity-check their inputs for null pointers, etc. In C++ at least I find this a necessity, as a single wrong pointer can cause horrible memory corruption all over my code. The whole point of these assertions is to allow me to find the place in the stack where the null pointers are coming from without pulling all my hair out in the process!

lmm 14y ago
That's not the right way to think about internal APIs. To make changes effectively you need to be willing to redefine those boundaries with a minimum of friction. If you make each function check its inputs then you won't be able to decompose your problem into small enough functions (a good function is usually <10 lines), and you'll mostly be duplicating your own work. Null is probably the worst mistake in programming history; never use it internally, never call an internal function with it, and then you don't need to make your functions check for it. If you're really paranoid you can use a static analysis tool to enforce that you're doing it right.
- CJefferson 14y ago
  Just Null might be a bit limited, however there are many other similar issues (some examples I can think of include functions which take a positive integer, or a non-empty container, or a sorted container, or two containers of equal size, or an integer which is smaller than the size of another argument, which is a container). I used to be very slack on internal checks. As times goes by I have pushed more of these into the type system where appropriate, and as checks. While unit tests on your external API can be useful, it can be hard to ensure coverage of all the nasty corner cases of your internals, some of which are only hit one time a million, or hundred million. I find having all these checks makes me more confident about changing my internal APIs. If anyone is calling a function inappropriately for it's new interface, I will quickly get an assertion flagged up, as opposed to code carrying on calling a function incorrectly. Just so we aren't talking at cross purposes, I feel I should say most of my programming is algorithmic, particularly in AI. In this field it can be devilishly difficult to construct good unit tests and ways of hitting bits of algorithms -- I am currently working on an algorithm which has function which I believe is required but which I cannot construct test data for my external API which causes it be called. Always a little worrying!
  - lmm 14y ago
    >As times goes by I have pushed more of these into the type system where appropriate Yeah, the type system is the appropriate place for most of these (including null even). >I find having all these checks makes me more confident about changing my internal APIs. If anyone is calling a function inappropriately for it's new interface, I will quickly get an assertion flagged up, as opposed to code carrying on calling a function incorrectly. I think we may be talking at cross purposes wrt "public". I don't mean "only ever test your external API". I do mean "only ever test public methods of a class, in the technical sense of public". Of course a large project will end up with lower-level and higher-level layers, and eventually you do need to define more rigid boundaries between the two to avoid everything becoming an unmaintainable mess, and testing at these boundaries is entirely appropriate. But a single class should belong to one layer or another. >I am currently working on an algorithm which has function which I believe is required but which I cannot construct test data for my external API which causes it be called. Always a little worrying! More than a little. My advice (not that you need it) would be to try and encode the constraint that leads to it not being called in the type system, then push it up through the layers.
ShaunCodeweaver 14y ago
What lmm said is spot on. If your paranoid about null pointers in C/C++, use asserts or static analysis.

lmm 14y ago

That's not the right way to think about internal APIs. To make changes effectively you need to be willing to redefine those boundaries with a minimum of friction. If you make each function check its inputs then you won't be able to decompose your problem into small enough functions (a good function is usually <10 lines), and you'll mostly be duplicating your own work. Null is probably the worst mistake in programming history; never use it internally, never call an internal function with it, and then you don't need to make your functions check for it. If you're really paranoid you can use a static analysis tool to enforce that you're doing it right.

CJefferson 14y ago
Just Null might be a bit limited, however there are many other similar issues (some examples I can think of include functions which take a positive integer, or a non-empty container, or a sorted container, or two containers of equal size, or an integer which is smaller than the size of another argument, which is a container). I used to be very slack on internal checks. As times goes by I have pushed more of these into the type system where appropriate, and as checks. While unit tests on your external API can be useful, it can be hard to ensure coverage of all the nasty corner cases of your internals, some of which are only hit one time a million, or hundred million. I find having all these checks makes me more confident about changing my internal APIs. If anyone is calling a function inappropriately for it's new interface, I will quickly get an assertion flagged up, as opposed to code carrying on calling a function incorrectly. Just so we aren't talking at cross purposes, I feel I should say most of my programming is algorithmic, particularly in AI. In this field it can be devilishly difficult to construct good unit tests and ways of hitting bits of algorithms -- I am currently working on an algorithm which has function which I believe is required but which I cannot construct test data for my external API which causes it be called. Always a little worrying!
- lmm 14y ago
  >As times goes by I have pushed more of these into the type system where appropriate Yeah, the type system is the appropriate place for most of these (including null even). >I find having all these checks makes me more confident about changing my internal APIs. If anyone is calling a function inappropriately for it's new interface, I will quickly get an assertion flagged up, as opposed to code carrying on calling a function incorrectly. I think we may be talking at cross purposes wrt "public". I don't mean "only ever test your external API". I do mean "only ever test public methods of a class, in the technical sense of public". Of course a large project will end up with lower-level and higher-level layers, and eventually you do need to define more rigid boundaries between the two to avoid everything becoming an unmaintainable mess, and testing at these boundaries is entirely appropriate. But a single class should belong to one layer or another. >I am currently working on an algorithm which has function which I believe is required but which I cannot construct test data for my external API which causes it be called. Always a little worrying! More than a little. My advice (not that you need it) would be to try and encode the constraint that leads to it not being called in the type system, then push it up through the layers.

ShaunCodeweaver 14y ago

What lmm said is spot on. If your paranoid about null pointers in C/C++, use asserts or static analysis.