Which C++ version?
01-Sep-93 07:48:13
Sb: #36566-Which C++ version?
Fm: Greg Comeau@Comeau Cmptg 72331,3421
To: Steve Bennett/SYSOP 76702,1071
>But he *HAS* to know that. Which is my whole point. Looking at just the few
>lines of code you wrote in your message, I have absolutely no idea what add
>does, nor for that matter what stuff or morestuff are. Even assuming I *did*
>know what stuff and morestuff are, I could very easily make an incorrect
>assumption about what add does based on it's name and what I know about the
>data associated with those objects. Even if there's some document somewhere
>which goes into excruciating detail on the stuff & morestuff objects, and what
>add does with them, a programmer who has had slight experience with those
>objects is likely to see "add" and assume one thing, while the object may do
>another thing.
Even assuming add is the right name, and chances are good it might not be,
I find this argument weak. A programmer who has less experience is likely
to assume many things whether that "less experience" means a neo programmer
or one not familiar with the app or etc. The object in and of itself is not
the issue to me. Even in non-OO code, I expect anybody writing or
maintaining it to be understanding programming, the app, the language, etc.
>One key to how clear and maintainable any piece of code is, is whether any
>generic programmer who knows your programming language can look at any given
>function or fragment and quickly figure out from the code & it's comments a
>rough idea as to what the code is intended to do.
I'm still not following: IMO a function *IS* one type of black box.
Perhaps you are speaking of stuff like uncommented code here, or large
functions or something, but I think speaking of these thing re black boxes
and OO is misguided.
>Black Boxes are nice at
>times for code development (and they can be done in any language…) but
>aren't always so nice when it comes time to pass the code onto someone else to
>take care of, since the other person needs to learn all the boxes before he
>can make sense of the rest of the code.
But as I mentioned to Robert, the tradeoff is to write straight mainline
sequential code. We don't do that. The intent is always to hide, black
box, etc. Yes, add too much code to that and you may indeed have a monster,
but that's a seperate issue IMO. That's part of good design, experience,
etc.
>And more often than not, I find that most Black Box type code doesn't move
>well into other projects. I'm *always* finding it necessary to make changes
>when I do things like that.
Although dependent upon the context, you have certainly just prescribed
inheritance. That way reuse doesn't always have to == COPY 😉
Seriously though, this gets back to abstracting properly and such.
A black box that does everything is typically a mistake. And don't get me
wrong about reuse either. It's nice, but I won't tout it anything like some
others do (though most of the folks I respect don't tout it wrongly either).
When I lecture, I'll often pull out the following:
"Reuse is a much a myth as a reality" — Greg Comeau