A compiler will translate your source into executable code. Yet many more tools are needed to work effectively with the ‘Best-Language, Ever’ – and we are not talking about debuggers! The Castle workbench can do so much more to make your code outstanding.
Probably you have many questions about the software. About its metrics: like the Fan-Out of a given class or its Cyclomatic-Complexity. Or merely like to k Often this isn’t too complicated. But the amount of error-prone work is dramatic. Castle comes with tools that provide the answer.
Classic tools are not sufficient¶
Most languages come with a compiler and, optional a debugger. The compiler (and its companions: linker, loader)
translate files with source code into computer code; often called the “binaries”. Nowadays, an “optimiser” is usually
build-in to unburden the developer from details that make the code more efficient. So that (s)he can make code readable
and maintainable. For example, by defining extra, well-named variables that do not result in more memory use;
the use of convenient loops, which are unrolled automatically, etc.
Originally, the intent was to optimise binaries; but they help to improve the source for developers too.
The second well-known tool is the “source-level debugger”. It understands the binary and can correlate that with the
source code – which isn’t trivial, especially due to the optimiser. It is an awesome tool when there is a bug in
the code; as the developer can step “line by line” through the source code, examine in-between results, and even change
some parameters on the fly.
Once this was the only way to improve code. In the present day, we have other instruments too; like Test-Driven-Development to prevent the nastiest flows in the first place.
Verification & Validation (https://en.wikipedia.org/wiki/Software_verification_and_validation)
Trace, Debug, Log/Monitor
? Fan-In/Out https://en.wikipedia.org/wiki/Fan-out_(software), UncleBob