\subsection CommentComponents API vs Internal Component Commenting
\par
- First among these is a definition seperation between component API
+ First among these is a definition separation between component API
and Internal operations. API functions and objects should always be
- commented and in the *.h file for the component. Internal logics and
+ commented and in the *.h file for the component. Internal logic and
objects should be commented in the *.cc file where they are defined.
The group is to be defined in the components main files with the
overview paragraphs about the API usage or component structure.
\par
- With C++ classes it is easy to seperate API and Internals with the C++
+ With C++ classes it is easy to separate API and Internals with the C++
public: and private: distinctions on whichever class defines the
component API. An Internal group may not be required if there are no
additional items in the Internals (rare as globals are common in squid).
\verbatim
/**
\retval 0 when FUBAR does not start with 'F'
- \retval 1 when FUBAR startes with F
+ \retval 1 when FUBAR starts with F
*/
int
X::saidFubar()
\endverbatim
\par Alternatively
- when a state or other context-dependant object is returned the \b \\return
+ when a state or other context-dependent object is returned the \b \\return
tag is used. It is followed by a description of the object and ideally its
content.
\par Long or Complex Functions
do however need some commenting.
- A well-designed function does all its operatons in distinct blocks;
+ A well-designed function does all its operations in distinct blocks;
\arg Input validation
\arg Processing on some state
\arg Processing on the output of that earlier processing
the callback function is executed. The routines in cbdata.c
provide a uniform method for managing callback data memory,
canceling callbacks, and preventing erroneous memory accesses.
-\todo DOCS: get callback_data (object?) linking or repalcement named.
+\todo DOCS: get callback_data (object?) linking or replacement named.
\section RefCountDataAllocator Refcount Data Allocator
\since Squid 3.0
\par
A DelayPool is a Composite used to manage bandwidth for any request
assigned to the pool by an access expression. DelayId's are a used
- to manage the bandwith on a given request, whereas a DelayPool
+ to manage the bandwidth on a given request, whereas a DelayPool
manages the bandwidth availability and assigned DelayId's.
\section ExtendingDelayPools Extending Delay Pools
delay pool functions:
\li stats() - provide cachemanager statistics for itself.
\li dump() - generate squid.conf syntax for the current configuration of the item.
- \li update() - allocate more bandwith to all buckets in the item.
+ \li update() - allocate more bandwidth to all buckets in the item.
\li parse() - accept squid.conf syntax for the item, and configure for use appropriately.
\li id() - return a DelayId entry for the current item.
* Any good application has a set of tests to ensure it stays
* in a good condition. Squid tends to use cppunit tests.
\par
- * It is preferrable to automated tests for units of functionality. There
+ * It is preferable to automated tests for units of functionality. There
* is a boilerplate for tests in "src/tests/testBoilerplate.[cc|h]". New
* tests need to be added to src/Makefile.am to build and run them during
* "make check". To add a new test script, just copy the references to
*
\par
* Squid uses events to process asynchronous actions.
- * These mehods are registered as callbacks to receive notice whenever a
+ * These methods are registered as callbacks to receive notice whenever a
* specific event occurs.
*/
projects / thirdparty / squid.git / commitdiff
