Contents 
 Index 
 "TPT User's Guide" 
 < Previous 
 Next > 

Software Engineering

Software engineering organizations cannot afford to have uncommented code.

• Otherwise the company risks rewriting code every time a new engineer comes on board just because they didn’t understand what their predecessor did.

• Software developers know that they are expected to document what they do. Even if their code is never exposed to the outside world, they are expected to comment it.

In more recent years, high-tech has meant high turnover for employees with skills and a thirst for challenge and rewards. Uncommented code is a very big business risk, so it is often mandated in company coding standards and conventions for all software engineers to follow.

On a more personal level, every software engineer should realize that “if you cant be replaced, you cant be promoted” and its corollary to software, “if they dont understand your code, you cant be assigned the whiz-bang new projects and you will be stuck maintaining your old code.

Information Repository and Tools

Hence, software engineering organizations are already on the verge of allowing their source code to be the repository for associated reference information. With just a few minor changes to the format of existing code comments, third-party tools can extract that information and create accurate, reliable systems.

Any technical writer charged with maintaining API documentation for any quickly changing code base will one way or another tell you that the task shouldn’t be done with tools.

The extent of the tools depend on many factors. At the very least, the tools need to flag differences in API syntax from one build to the next so that finding which parameters change isn’t a manual job of digging through the code to visually match a code item with the external documentation.



 "TPT User's Guide" 
 < Previous 
 Next > 


Open-Source tools compliments of Voyant Technologies, Inc. and Glenn C. Maxey.
01/13/2003

TP Tools v2-00-0a

# tpt-hug-02