Reuse Implies Coupling
From WikiContent
(Difference between revisions)
| Line 1: | Line 1: | ||
Do not make your code depend on some file that is intended to change as the project progresses. | Do not make your code depend on some file that is intended to change as the project progresses. | ||
| - | It is very convenient to have a global file that lists all error codes in the system. When starting the new component, you proudly add a handful: look, I am a part of this! Only to find | + | It is very convenient to have a global file that lists all error codes in the system. When starting the new component, you proudly add a handful: look, I am a part of this! Only to find your colleagues moan about the extra build time. How dare you change this file? |
Couldn't you just do what everybody does: | Couldn't you just do what everybody does: | ||
Revision as of 12:36, 15 October 2008
Do not make your code depend on some file that is intended to change as the project progresses.
It is very convenient to have a global file that lists all error codes in the system. When starting the new component, you proudly add a handful: look, I am a part of this! Only to find your colleagues moan about the extra build time. How dare you change this file?
Couldn't you just do what everybody does:
- reuse some error codes that are already in there.
- when existing codes don't match the intended meaning, document their specific meaning in your component documentation.
The error.h file was intended to provide a great place to look for the meaning of codes. At the same time, it is a central component that is intended to change as the project proceeds. So it is your base, but it is quicksand.
How to get out? Consider this:
- real generic error messages (in the style of STL exceptions)
- a distinct
error.hfile per component
