×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
There's no such thing as too few lines of code in a subprocedure...
I often have procedures that are one or two lined of executable code...
Granted, in those cases a single executable line takes multiple source
lines, but the point to to clean up the mainline code..hiding the
details unless I need to look at them under a well named procedure.
Steve McDonald in Code Complete (2nd Edition p167) says: "Constructing
a whole routine to contain two or three lines of code might seem like
overkill, but experience shows how helpful a good small routine can
be."
His example was the following, a line of code used in a dozen places:
points = deviceUnits * (POINTS_PER_INCH / DeviceUnitsPerInch())
replaced by
points=DeviceUnitsToPoints(deviceUnits)
Which provides two benefits:
1) you don't have to try to decipher what the equation is doing, the
function name tells you.
2) when you find out that DeviceUnitsPerInch() can return zero, and
need to add three more lines of code to prevent divide by zero, you
only have to do it in one place instead of 12!
Charles
Charles
On Wed, Jun 13, 2012 at 2:03 PM, Dave <dfx1@xxxxxxxxxxxxxx> wrote:
I would agree, but I've recently been pulled up a manager for having too
many sub procedures with few lines of code in them. I think it's because
the monolithers like to read everything, and as they prefer SEU to LPEX
they find it very difficult to read the whole program.
midrange.com
