M
Mike Hofer
Michael said:
Sorry, but that's a sad excuse for being rude. This is an excellent
topic, and it can lead to great discussion without ANYONE having to be
rude to anyone else.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Sorry, but that's a sad excuse for being rude. This is an excellent
topic, and it can lead to great discussion without ANYONE having to be
rude to anyone else.
M
Mike Hofer
Chris said:In addition to what has already been said, the numbers (80 chars per
line, and 45 lines) probably has its roots in console type programs
where the screen size is 80 characters wide by 40 lines deep.
There's a lot of truth in that, though if I recall, it was 80 x 25 on
the screen. I think that you used to be able to get 55 lines out of the
printer tho; the 45 lines might have allowed for header and footer
space.
K
Kevin Spencer
As a general rule, long functions indicate something that should be broken
up into smaller functions, as there are usually a number of logical
divisions of functionality going on in a function that would be more suited
to separate function definitions for use in other capacities.
However, that is a general rule, and it is based upon a solid foundation of
mathematical logic. A general rule is useful only as a general rule. Once
one steps outside the parameters of the specific logic that creates that
rule, other logical rules apply.
A general rule is not the same as a constant or universal rule.
Understanding the logic behind it is important if one wants to step beyond
the boundaries of what is generally or popularly known and thought, and
enter into the realm of solid scientific principle, fact, and discovery,
wherein lies real power.
Or, as my Uncle Chutney lokes to keep reminding me "Neither a follower nor a
lender be."
A function call employs indirection. This has a corresponding cost, albeit
small. Of course, as Uncle Chutney would say "Big things are made up of lots
of little things." Indirection for no logical purpose is wasteful, any way
you slice it. So, the real question is, why do such "recommendations" and
"rules" exist in certain types of software and technologies?
The answer is, "for the same reason that there are little white speed
recommendation signs on sections of roads that curve steeply." These signs
are not law, they are recommendations. They are there for the inexperienced
driver, those with diminished capacity, and for those who do not care to
think, learn, or research; for the young, the infirm, and the lazy. For
those who can't put down their cell phones long enough to pay attention to
their driving. And for the young and the infirm, they are there for a good
reason. They save lives. For the lazy, on the other hand, there is no
excuse.
I guess where I'm going with this is, who cares what some well-know Java
project management platform, or "Software Developer" magazine has to say
about anything? Surely these statements must be studied, and understood. But
to simply follow one's supposed "peers," or even to care what opinions are
held by others, is to become a Lemming.
There was a day when most software developers were rugged individualists,
bent on "pushing the envelope" with regards to making software do what it
could. There were days when "Best Practices," "Recommendations," and "Design
Patterns" did not exist. Now, am I saying that these things are bad? Far
from it. I tend to follow most of Microsoft's Best Practices and
Recommendations. Not because they come from Microsoft, though. Because they
are logical, I understand them, and I agree with them.
For example, I use Microsoft naming conventions in my code. Why? It makes it
easier to read and maintain. Of course, a naming convention is arbitrary.
So, why not create my own? Because if I hire someone, I want them to be able
to jump right into my code without having to acquaint their self with a
whole new naming convention. And to come up with a new arbitrary one would
serve no logical purpose. And this is how I approach everything I do.
Oddly enough, however, I always seem to find myself being challenged with
something new, something "outside the lines." And I have learned the guiding
principles of logic that do not fail me when I have to step beyond the realm
of "typical" software development. In fact, I actually enjoy it. The only
thing I do NOT enjoy is boredom.
So, when it comes to breaking up functions, I would exhort anyone to not
simply "follow the leader." As well-intentioned as they may (or may not) be,
there are reasons for such conventions. I would be loathe to break up a long
function into smaller pieces simply because it was longer than, say, 42
lines in length. However, I might be inclined to take a second look at it,
an analyze it further to see what might be done to improve it, repurpose
some of it, etc.
The Code Analysis tools in Visual Studio.Net 2005 are another excellent
example. These can be quite helpful. They are not, however, a set of rules
to which one should always adhere. There have been times when I looked at
one of these analyses and said to myself, "Self, that is a good idea there.
You should implement it." There have been other times when I looked at one
of these analyses and said to myself "Self, that may be a good idea in many
circumstances, but if you implement it here, I will never speak to you
again." (Some might consider that a healthy thing, but that's another topic
altogether!)
So, am I disagreeing with anyone here? Nah. But I have seen a trend of late,
particularly among those in the "enemy" camp (the anti-Microsoft camp). I'm
starting to hear a lot of pop programming jargon. And it worries me.
Especially when I see so much lingo from that camp making it over here, as
if the less successful had something to teach to the master (that would be
Microsoft). And that puzzles and concerns me. The world can do with a few
less Dilberts, and a few more Albert Einsteins.
Anyway, that's my story, and I'm stickin' to it!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
up into smaller functions, as there are usually a number of logical
divisions of functionality going on in a function that would be more suited
to separate function definitions for use in other capacities.
However, that is a general rule, and it is based upon a solid foundation of
mathematical logic. A general rule is useful only as a general rule. Once
one steps outside the parameters of the specific logic that creates that
rule, other logical rules apply.
A general rule is not the same as a constant or universal rule.
Understanding the logic behind it is important if one wants to step beyond
the boundaries of what is generally or popularly known and thought, and
enter into the realm of solid scientific principle, fact, and discovery,
wherein lies real power.
Or, as my Uncle Chutney lokes to keep reminding me "Neither a follower nor a
lender be."
A function call employs indirection. This has a corresponding cost, albeit
small. Of course, as Uncle Chutney would say "Big things are made up of lots
of little things." Indirection for no logical purpose is wasteful, any way
you slice it. So, the real question is, why do such "recommendations" and
"rules" exist in certain types of software and technologies?
The answer is, "for the same reason that there are little white speed
recommendation signs on sections of roads that curve steeply." These signs
are not law, they are recommendations. They are there for the inexperienced
driver, those with diminished capacity, and for those who do not care to
think, learn, or research; for the young, the infirm, and the lazy. For
those who can't put down their cell phones long enough to pay attention to
their driving. And for the young and the infirm, they are there for a good
reason. They save lives. For the lazy, on the other hand, there is no
excuse.
I guess where I'm going with this is, who cares what some well-know Java
project management platform, or "Software Developer" magazine has to say
about anything? Surely these statements must be studied, and understood. But
to simply follow one's supposed "peers," or even to care what opinions are
held by others, is to become a Lemming.
There was a day when most software developers were rugged individualists,
bent on "pushing the envelope" with regards to making software do what it
could. There were days when "Best Practices," "Recommendations," and "Design
Patterns" did not exist. Now, am I saying that these things are bad? Far
from it. I tend to follow most of Microsoft's Best Practices and
Recommendations. Not because they come from Microsoft, though. Because they
are logical, I understand them, and I agree with them.
For example, I use Microsoft naming conventions in my code. Why? It makes it
easier to read and maintain. Of course, a naming convention is arbitrary.
So, why not create my own? Because if I hire someone, I want them to be able
to jump right into my code without having to acquaint their self with a
whole new naming convention. And to come up with a new arbitrary one would
serve no logical purpose. And this is how I approach everything I do.
Oddly enough, however, I always seem to find myself being challenged with
something new, something "outside the lines." And I have learned the guiding
principles of logic that do not fail me when I have to step beyond the realm
of "typical" software development. In fact, I actually enjoy it. The only
thing I do NOT enjoy is boredom.
So, when it comes to breaking up functions, I would exhort anyone to not
simply "follow the leader." As well-intentioned as they may (or may not) be,
there are reasons for such conventions. I would be loathe to break up a long
function into smaller pieces simply because it was longer than, say, 42
lines in length. However, I might be inclined to take a second look at it,
an analyze it further to see what might be done to improve it, repurpose
some of it, etc.
The Code Analysis tools in Visual Studio.Net 2005 are another excellent
example. These can be quite helpful. They are not, however, a set of rules
to which one should always adhere. There have been times when I looked at
one of these analyses and said to myself, "Self, that is a good idea there.
You should implement it." There have been other times when I looked at one
of these analyses and said to myself "Self, that may be a good idea in many
circumstances, but if you implement it here, I will never speak to you
again." (Some might consider that a healthy thing, but that's another topic
altogether!)
So, am I disagreeing with anyone here? Nah. But I have seen a trend of late,
particularly among those in the "enemy" camp (the anti-Microsoft camp). I'm
starting to hear a lot of pop programming jargon. And it worries me.
Especially when I see so much lingo from that camp making it over here, as
if the less successful had something to teach to the master (that would be
Microsoft). And that puzzles and concerns me. The world can do with a few
less Dilberts, and a few more Albert Einsteins.
Anyway, that's my story, and I'm stickin' to it!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
K
kevin cline
I have a different rule -- the need for a comment in the implementation
is a strong indication that the code is poor. The function may be too
complex, or something may be badly named, or some variable is doing too
many jobs. Why write a comment like
// calculate bogosity
... ten lines of code
instead of just writing
CalculateBogosity();
Then if I'm interested in calculating specific gravity I can go read
that function, but if I'm happy that the bogosity is correct then I
don't have to bother searching for the end of the bogosity calculation.
Besides, tomorrow some other bit of code is going to need to calculate
bogosity too. The older I get, the shorter my functions get. These
days my limit is about twenty lines of code or two levels of block
nesting, whichever comes first.
One of the really good things about the new version of C# is that it
makes functional programming much easier, so you can factor out loop
control easily:
delegate void CellFunc(int row, int col);
void ForEachCell
{
for ( int row = ...)
{
for ( int col = ...)
{
CellFunc(row, col);
}
}
}
void FillTable()
{
ForEachCell(delegate (int row, int col)
{
Cell(row, col).Text = (row * col).ToString();
}
}
void DrawTable(Graphics g)
{
ForEachThing(delegate (int row, int col)
{
Cell(row,col).Draw(g);
} );
}
is a strong indication that the code is poor. The function may be too
complex, or something may be badly named, or some variable is doing too
many jobs. Why write a comment like
// calculate bogosity
... ten lines of code
instead of just writing
CalculateBogosity();
Then if I'm interested in calculating specific gravity I can go read
that function, but if I'm happy that the bogosity is correct then I
don't have to bother searching for the end of the bogosity calculation.
Besides, tomorrow some other bit of code is going to need to calculate
bogosity too. The older I get, the shorter my functions get. These
days my limit is about twenty lines of code or two levels of block
nesting, whichever comes first.
One of the really good things about the new version of C# is that it
makes functional programming much easier, so you can factor out loop
control easily:
delegate void CellFunc(int row, int col);
void ForEachCell
{
for ( int row = ...)
{
for ( int col = ...)
{
CellFunc(row, col);
}
}
}
void FillTable()
{
ForEachCell(delegate (int row, int col)
{
Cell(row, col).Text = (row * col).ToString();
}
}
void DrawTable(Graphics g)
{
ForEachThing(delegate (int row, int col)
{
Cell(row,col).Draw(g);
} );
}
K
kevin cline
Michael said:Could that 'driver' amount to more than 45 lines of code?
I wouldn't.
If so, would you create a driver to several drivers?
At that point I would probably be splitting the class.
Note that I'm still talking about inside a class. Private methods.
I would be splitting out related private methods into new classes.
That is another topic.
I'm talking about splitting up a sequence into smaller methods just because
Maven says so.
I don't care what Maven says. I'm lazy, and I don't like spending
hours poring over incomprehensible code. So to avoid that, I've
learned to keep methods to a managable size, about twenty lines or
less.
But I should also tell you that I once felt just as you did. then I
changed my mind. Take a look at "Refactoring" by Martin Fowler.
M
Mike Hofer
kevin said:Take a look at "Refactoring" by Martin Fowler.
Definitely. Absolutely a must-have reference for a serious developer's
bookshelf. Along with "Code Complete" by Steve McConnel, and
"Test-Driven Development in Microsoft .NET" by James W. Newkirk and
Alexei A. Vorontsov. TDD relies heavily on refactoring.
VS.NET 2005 will thankfully provide lots of built-in refactoring tools.
One of them, I believe, is to extract the selected code, and create a
function out of it. That should make it easier to comply with the
guidelines imposed by tools like Maven.